That's actually easier then you think due to the way the images get processed with the profiles.

What you do is copy all of the images. Run with the RGB profile and any image that come out with 0 bytes is greyscale. Then take just those images (the original versions) and run them through the greyscale profile. Then put everything back where they came from and done. You can also do it in reverse as well. RGB processed with the greyscale profile also come out 0 bytes.

An ePub (the one I sent you) I just optimized (using the profiles) came out with the images totaling 334KB. The same images using ePUBOptimizer came out to be 340KB. I know 6KB isn't a lot, but it does add up.

I'd be happy to test if you decide to do it this way.

Hi

About ttf and otf

FontShrinker dealt only with ttf fonts.

EPUB Optimizer has been issued quite recently. Can it subset now otf fonts or there is no hope about it?

It uses the same core and for now it remains ttf only. In theory it should also support otf, but it is a hit and miss. If I find the cause, I might be able to also support otf.

Thanks and good luck.

It seems that they are multiple types of otf fonts. Some of them resemble ttf and those work fine. Others resemble Type 1 and those give issues apparently. If I find the solution, I will of course implement this.

I know that ePUBOptimizer won't subset OTF fonts, but could you make it so if an OTF font is not used that it gets removed? Thanks.

New version of the plugin is out. With big thanks to KevinH I can now garantuee it will also work on OSX. I will adapt the first post to reflect the changes.

I could. Perhaps in the new version. I am still working on supporting OTF fonts.

Even if you don't end up supporting OTF, removing unused OTF would help.

New version of the plugin is out. There was a serious bug in the ePUBOptimizer program which is solved now (don't worry, if you haven't noticed, the bug was not for you...). New is a change in the way of working. If from one font family multiple fonts are delivered, the actual usage per font is checked. However, if only one font for that font family is delivered, the usage of the complete font family is checked, not taking bold/italic into account. This is less strict perhaps, but resembles more the actual usage of fonts in ePUB I guess.

Man...I disappear for a little bit and you guys go and do all kinds of really cool things... ;)

Toxaris,
I got this unhandled exception message when I ran the plugin on my shell/default epub saying that ':first-letter' has an invalid token:


Does this not support pseudo-classes? or am I making a heretofore undiscovered mistake in my css?

CSS:

No, it does support pseudo-classes, although most readers don't... However, the following pseudo-classes are currently not supported:
- :first-line
- :first-letter
- :before
- :after

Now, :before and :after would not be an issue I guess, but the other ones might. Still, it should not cause an error. The issue with these pseudo-classes is that they address portions of text within a tag, which cannot be translated to an XPath statement which I use to inline the CSS (necessary to properly determine the styling of tags). I think I can work around the :first-letter, but the :first-line might be much more difficult. I need to read into the :first-line a bit more, but IIRC the first line will differ on things like font-size and screen-size. If that is the case, it will become quite difficult to incorporate that.
I will look into this more and will report back.

I have updated the plugin to reflect the changes in Sigil. It now supports version 3.4 of Python (with a very big thank you to Doitsu!).

There were some small errors in the conversion. Now it will work on both 2.7 and 3.4.

I also forgot to incorporate the error as mentioned by Turtle91. That one is fixed as well...

I've got an error while downloading the plugin
Sorry, this file is infected with a virus