ePUB Optimizer

[phillipgessert]

Originally Posted by KevinH

So it appears that your system PATH environment variable is set improperly.

Thank you again for this--you are absolutely right, my PATH was all wrong. I think that in an earlier attempt, upon the plugin not finding mono, I added a line to /etc/paths that pointed to that capital-M Mono. Got rid of that line and reinstalled mono, and now everything mono-related seems pretty normal ('which mono' returns the results you shared, as does 'find ./ -name "mono"' within that folder). Running 'mono' in Terminal also works to show usage info.

Plugin still doesn't find it, though--tried removing and reinstalling both mono and the plugin a couple times, no dice. I'll tinker a bit more--I've actually never used this plugin, just wanted to try it out as it seems pretty useful. You gave me a heck of a lot of help here and I'm grateful for it--if nothing else, I now have a repaired mono install.

[KevinH]

Have you tried logging out and relogging in as I thoght the /etc/paths were only read on login. To be safe, you could just do a restart.

[phillipgessert]

Yep, thought of that too--rebooted a couple times, each time double-checked with 'which mono' in Terminal before trying the plugin (also tried removing/reinstalling the plugin a few times), no luck. Quite a pickle.

[KevinH]

Do you have a mono.commands folder in /etc/paths.d/ ?

Not sure why a newly created plugin python process would not inherit the system PATH that you are seeing in any new Terminal.app now.

Very strange. Could the EPUBOptimizer have stashed the wrong path someplace. You might want to try manually removing that plugin and any preferences folder it created and try again.

[phillipgessert]

I have a mono-commands (with a dash) file there, but not a mono.commands (with a dot) folder. Wonders never cease!

I will try wiping out the plugin and perhaps I'll also poke around to see if there are other plugins that also use mono to see if they fail for me as well.

[KevinH]

I may have misremembered that name. I am not in front of my mac to check.

Look for a plugin preferences folder and delete it too.

[phillipgessert]

I didn't find anything for it in the plugins_prefs folder, but I deleted the plugin and reinstalled, same result. I don't know how helpful this is, but the plugin version is 0.73, which I believe is the latest. Also I realize at a certain point we're getting into lost cause territory here, I'm OK knowing I may not be able to join the ePUB Optimizer club just yet. Had to give it a shot!

[KevinH]

You seem to have everything done properly. The built in python3 interpreter that comes with Sigil on macOS should have no issues running mono if Terminal.app "which" finds it properly.

If you ever want to track this down further just pm me.

[phillipgessert]

Thanks, Kevin--I'll definitely come back to it at some point. Thanks again for all the help here, very much appreciated.

[Peter Ahlstrom]

phillipgessert, I fixed it on my mac. Open ePUBOptimizer/plugin.py in a text editor and find line 87:

args = ["mono", exe_path]

Change it to:

args = ["/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono", exe_path]

Then the plugin will run correctly. You may need to trash plugin.pyc.

Why calling mono from its explicit path works while just using the bare command does not, I have no idea.

Also it's the slowest Sigil plugin I have. Takes at least 3 minutes to finish.

[Peter Ahlstrom]

...Except wow, the font embedding screws up the font's character encoding. The font wasn't showing correctly, so I opened the subsetted font up in FontForge and the characters are all wacky. Characters are assigned these names:
! : carriage return
# : space
& : exclam
( : quotedbl

etc. I'm going to change the encoding of the original font and then subset it again and see what happens.

OK, I did that, and it did not help. When I opened the subsetted font in FontForge, it said the encoding was UnicodeBmp. So I took the original font and changed its encoding from Glyph Order to UnicodeBmp, then put that in my ePub and ran the plugin again. The result was exactly the same: character names still screwed up.

I don't know how to fix this, but at least now I know which characters I need for the subset, so I'm just going to do it manually in FontForge...

Note: the other Sigil plugin that subsets fonts did not have this problem, but it goes by all the characters in the whole ePub, not the spots where that particular font is actually used.

EDIT: Well, never mind that, this plugin also does not base the subsetting on where that particular font is actually used. Guess I'll just go back to my wholly manual method.

[roger64]

Originally Posted by Peter Ahlstrom

...Except wow, the font embedding screws up the font's character encoding. The font wasn't showing correctly, so I opened the subsetted font up in FontForge and the characters are all wacky. Characters are assigned these names:
! : carriage return
# : space
& : exclam
( : quotedbl

etc. I'm going to change the encoding of the original font and then subset it again and see what happens.

.../...

Note: the other Sigil plugin that subsets fonts did not have this problem, but it goes by all the characters in the whole ePub, not the spots where that particular font is actually used.

EDIT: Well, never mind that, this plugin also does not base the subsetting on where that particular font is actually used. Guess I'll just go back to my wholly manual method.

Hi

Maybe, "the other Sigil plugin that subsets fonts" is SubsetFonts?

If this is so, some comment about it. Say, your ePub is written mostly with font-family A. It also uses some few characters from a Chinese font B (this one is sparsely used with some spans here and there), or for that matter any other font-family.

After using the plugin, A and B will both be subsetted. So, the Fonts folder in the ePub will include both of them. It then maybe easier, if need be, to just replace font-family A in this folder by a full version of it rather than fiddling with FontForge...

My two-cents.

[Peter Ahlstrom]

Yes, SubsetFonts is the other plugin I was thinking of, but I didn't have the exact name off the top of my head.

Sure, any automatic process (or not subsetting at all) is easier than using FontForge. But as I see it, the entire point of subsetting fonts is to only include in the font those characters that are actually used from that font by the ebook.

For example, I don't use an embedded font for the body text—only for headings and (usually) the first 3 words of each chapter. The body of my book includes the word "café" but the headings and first 3 words do not. When I ran either SubsetFonts or ePUBOptimizer, the resulting subsetted version of the heading font included the character é. Which will never get used, among a few other extraneous characters. (I do appreciate that the ligatures were subsetted by ePUBOptimizer.)

ePUBOptimizer also subsetted & and #, which don't even appear in the body text—only in html entities.

The version of the manual process I used this time was:
1. Use Calibre to convert the ePub to HTMLZ
2. Unzip the file
3. Open the html in Word
4. Use Find Format to delete any text in the default body text font
5. Copy everything that's left into BBEdit
6. Add a line break after each character
7. Process duplicate lines, case sensitive, leaving one
8. Sort lines
9. Remove line breaks
10. Use the resulting list: (space),-.0123456789ABCDEFGHIJLMNOPRSTUVWYabcdefghiklmnoprs tuvwxyz®’“”
to determine which characters to keep in FontForge, plus (CR)fifl (which do get used in this book by readers that do ligatures automatically).

It would be possible to do all of that in a plugin—take each @font-face from the CSS, see which tags use that font-face, process only the text included in those tags in the ePub to find the unique characters. It would also be possible to do the ligature selection algorithmically, before the unique characters are found.

I've kludged some things together in python in the past, so maybe I could take a stab at adjusting SubsetFonts before the "# get rid of the tags" section, but someone who actually knows what they're doing could do it better and in a fraction of the time. I like a challenge, so maybe I'll take some Saturdays and try it anyway. I've never touched C#, so trying to alter ePUBOptimizer is beyond me.

[Doitsu]

Originally Posted by Peter Ahlstrom

The version of the manual process I used this time was: [...]

My Sigil SubsetFonts plugin is certainly less sophisticated than the Calibre Polish book tools, however, since the Python library used for subsetting also recompresses fonts, the resulting subset fonts are often smaller than the subset fonts generated by the Calibre Polish tools.
BTW, you could also use the command line version of Polish books to subset fonts.

[phillipgessert]

Originally Posted by Peter Ahlstrom

phillipgessert, I fixed it on my mac. Open ePUBOptimizer/plugin.py in a text editor and find line 87:

args = ["mono", exe_path]

Change it to:

args = ["/Library/Frameworks/Mono.framework/Versions/Current/Commands/mono", exe_path]

Then the plugin will run correctly. You may need to trash plugin.pyc.

Why calling mono from its explicit path works while just using the bare command does not, I have no idea.

Also it's the slowest Sigil plugin I have. Takes at least 3 minutes to finish.

Thank you very much for the suggestion, I'll give it a shot when I get a chance, and I'll come back either way.