Calibre will only embed certain fonts and not others. Why?

[Divingduck]

I am impressed. Just run the editor from source with my sample docx for generating a new epub. Works very well

Can you do the same behavior for an existing epub for updating? E.g if you are looking for the file I gave you (FonttestwithoutembededFont.epub). If you embed the font it find the regular one and for the light version it found 2 possible matches based on weight. But only one is correct because there is only one as light regular. The other one is light italic and that one isn't used for this epub. Guess, if you are able to get that in line too, most users are happy with the new solution.

Best regards,
DD

[kovidgoyal]

While in this case it is easy to deduce which is the correct font, in the general case it is not so easy. Remember that there are four axes on which font properties must be matched, so the search space is rather large and you can have many candidates. As such, I think showing the user the candidates and letting them pick manually is better than auto-picking one, which could very well be wrong. Not to mention that this problem only happens for special purpose fonts i.e. ones that do not have regular weight or stretch properties, which is relative rare.

[Divingduck]

Understand. Thanks.

[nabsltd]

Originally Posted by kovidgoyal

See my previous post. You really need to read what I actually say instead of jumping up and down and repeating yourself endlessly. Quoting myself, from one day and 14 posts before:

To me, that meant you might be thinking about it, but not really putting it on the "to do" list. So thanks for the change.

I jumped hard because it's one of those very much not intuitive UI things that the programmer thinks is really easy to use, but other users don't. And, it could be made much, much easier if the user could just click a font file in the "not quite matching" list and say "OK, that's the one I meant...embed that, and make sure the @font-face definition that gets created matches the selector you found, thanks". This would also make it do what users seem to expect it will do.

Font selection, operates on four keys, name (of which there are actually half a dozen varieties in font files), weight, style and stretch. Read the CSS spec on fonts sometimes.

But, most of that doesn't matter as far as real-world users who are trying to embed fonts. For example, if they have a selector like:

.something {
font-family: "Adobe Garamond Pro";
font-weight: bold;
}

A user that has this expects the font from the selector to be exactly the same one that shows up when they use a word processor, pick the "Adobe Garamond Pro" font, and choose "bold". The fact that the actual font is marked as "semibold" weight (600) shouldn't matter as far as matching for embedding. Maybe it won't embed automatically, but a user should be able to tell Calibre, "yes, that's really the right file, even though something doesn't match perfectly".

For weight, this makes perfect sense, because even the CSS spec says that font-weight can never fail to match, as long as there is a font with a name match that has the appropriate glyphs (and I never expect Calibre to check this) and otherwise matches (italic, etc.).

So, yeah, I read the spec...and Calibre's editor (which is acting as a UA at that point) doesn't follow it when embedding.

[kovidgoyal]

Originally Posted by nabsltd

To me, that meant you might be thinking about it, but not really putting it on the "to do" list. So thanks for the change.

You're welcome -- and miscommunication is one fo the "features" of the internet

I jumped hard because it's one of those very much not intuitive UI things that the programmer thinks is really easy to use, but other users don't. And, it could be made much, much easier if the user could just click a font file in the "not quite matching" list and say "OK, that's the one I meant...embed that, and make sure the @font-face definition that gets created matches the selector you found, thanks". This would also make it do what users seem to expect it will do.

It's also one of those things that is a lot of effort to implement for a relatively rare use case. Software development is all about tradeoffs. If you feel my judgement of this tradeoff is incorrect, you are welcome to submit a patch.

A user that has this expects the font from the selector to be exactly the same one that shows up when they use a word processor, pick the "Adobe Garamond Pro" font, and choose "bold".

So, yeah, I read the spec...and Calibre's editor (which is acting as a UA at that point) doesn't follow it when embedding.

You cannot have both of those properties, they are mutually exclusive, because word processors do not follow the CSS spec on font matching. And see my post from a couple of days before, quoting myself:

What I can do, is implement a basic fallback mechanism for when a font is not found, so that the matcher tries to find the "closest" available font, which will hopefully be the right one most of the time. However, this is a lot of work to implement.

[kovidgoyal]

Originally Posted by kovidgoyal

While in this case it is easy to deduce which is the correct font, in the general case it is not so easy. Remember that there are four axes on which font properties must be matched, so the search space is rather large and you can have many candidates. As such, I think showing the user the candidates and letting them pick manually is better than auto-picking one, which could very well be wrong. Not to mention that this problem only happens for special purpose fonts i.e. ones that do not have regular weight or stretch properties, which is relative rare.

After thinking some more about it, I decided to implement the fallback mechanism after all. The idea being that even if it gets it wrong, thanks tot he checkpoint mechanism, it is easy for the user to revert the changes and manually edit the styles for the fonts based on the generated report.

https://github.com/kovidgoyal/calibr...0ccadbac0a03bb

This is going to need some testing.

[Divingduck]

Good morning. I see, you are busy working on this again

[hidden.platypus]

Originally Posted by kovidgoyal

After thinking some more about it, I decided to implement the fallback mechanism after all. The idea being that even if it gets it wrong, thanks tot he checkpoint mechanism, it is easy for the user to revert the changes and manually edit the styles for the fonts based on the generated report.

https://github.com/kovidgoyal/calibr...0ccadbac0a03bb

This is going to need some testing.

I am going to be doing a fair amount of font embedding via Calibre for the foreseeable future.

Happy to be your guinea pig. Tell me how you think it's best stressed, and I'm happy to inform you when and if I break it.

Thanks for taking the time to do this.

[Divingduck]

It works much better now. If you run the editor from actual source you will see the improvements immediately.

[kovidgoyal]

Just use it and let me know if it does something unexpected

[Divingduck]

Hi Kovid,

I finish my tests and all went good so fare.

I recognize some system usage increase during the time the algorithm is analyzing the document.

An other observation was, that if a document have already a font included the algorithm seems not to check wether the font is in use ore not. In my case there was already a font (Arial Unicode) integrated but not used. The algorithm pick up the correct one's on top but don't delete the already included wrong one.
In my case this behavior is ok (I think) because the document uses parts of the huge Arial Unicode font (instead of the original font). The algorithm was maybe not able to find the better one. I guess this will be a unsolvable situation as the system can't know at that point what the right font is if there are intersections in glyphs between used fonts.

I recognize this behavior after I generate my mentioned "worse case book" with updated sources from scratch today. I was wondering why there was missing some fonts and surprised about to see that most of exotic glyphs matching better and with less missing ones as before.

Maybe you can put an additional remark into help file / tool tip that this can happen.

I found a little issue with one font. calibre wasn't able to find the font code2001 with font style italic. I never had seen a own italic version. After I check the font, I recognize the italic glyphs are included within the font. No problem at all, I delete the odd one manually.

Best regards,
DD

[kovidgoyal]

Embedding fonts will never delete any pre-existing embedded fonts. It should not re-embed an already embedded font, as long as the font family and font styles of the already embedded font match those of the newly embedded font, the old font will be used. But if the old font has a different family/style/weight/stretch in its @font-face rule then then it will not be re-used.

[Hitch]

Originally Posted by kovidgoyal

Embedding fonts will never delete any pre-existing embedded fonts. It should not re-embed an already embedded font, as long as the font family and font styles of the already embedded font match those of the newly embedded font, the old font will be used. But if the old font has a different family/style/weight/stretch in its @font-face rule then then it will not be re-used.

Kovid:

Stupid question, if I may? (I've been playing with your editor. Very nice.)

Does the import function (or any of these others--I freely admit I have not played with this yet) check the embedding permissions for the font, prior to embedding it or displaying it for use (in the new function)?

Thanks,
Hitch

[kovidgoyal]

No, calibre is not going to get into the game of trying to second guess the user about their intentions. If the user asks calibre to embed a font, calibre will embed the font. It is up to the user to ensure they have the proper permissions for the intended use of the fonts.

[Hitch]

Originally Posted by kovidgoyal

No, calibre is not going to get into the game of trying to second guess the user about their intentions. If the user asks calibre to embed a font, calibre will embed the font. It is up to the user to ensure they have the proper permissions for the intended use of the fonts.

Kovid:

Thanks. I wasn't looking to turn this into a philosophical discussion, about licensing fonts rather than not--I really just wanted to know if it did (look for the embedding bits). Obviously, it's something that we're very attuned to, at my shop. I was wondering if C did look for that, because we do get a fair number of "fixer-uppers." If C looked at that, I could have used it as a quick-n-dirty double-check of ePUBs that we've not made ourselves.

As it is, we unzip the ePUB and I check the bits with my font manager. I was simply hoping that you might have something faster/easier.

Thanks.
Hitch