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

[Divingduck]

I can ensure you, it is a standard font. Since Office 2007 it's the replacement for Times New Roman as default typeface. For Win 7, 8 and 10 it's part of the standard installation too.

https://support.microsoft.com/en-us/kb/2761217
https://www.microsoft.com/typography...y.aspx?FID=287

There will be two attachments one is the test case (caltestfonts.zip) and an encrypted file called calibri.rar. I will send you the password vial PM.

Fonts interna:

Spoiler:

Font, Font name, Family Name, Alternative names, Weight
CALIBRI.TTF, Calibri, Calibri, , 400
CALIBRIB.TTF, Calibri-Bold, Calibri,[Calibri Bold][CalibriBold], 700
CALIBRII.TTF, Calibri-Italic, Calibri,[Calibri Italic][CalibriItalic], 400
CALIBRIL.TTF, Calibri-Light, Calibri Light,[Calibri Light][CalibriLight], 300
CALIBRILI.TTF, Calibri-LightItalic, Calibri Light,[Calibri Light Italic][CalibriLightItalic], 300
CALIBRIZ.TTF, Calibri-BoldItalic, Calibri,[Calibri Bold Italic][CalibriBoldItalic], 700

[JSWolf]

As for font weight, don't use a number. It usually doesn't work.

[JSWolf]

Forget Calibri. It's a snas-serif font and not good to use as the body font of a book. It is NOT a Times New Roman replacement.

[hidden.platypus]

Thanks Kovid. I wasn't aware that you could embed fonts in a Word doc. Did a Google search, figured out how to do it.

Unfortunately, while Calibre now finds and properly embeds the Bookman style fonts it wouldn't find originally, it does not embed Cochin.

Just to be clear. I embedded the fonts in the Word docx. I converted that docx to epub. When I open the editor it has embedded all the fonts except 1.

Still the same issue. It has decided that Cochin should be embedded at font weight normal, and Cochin is apparently only available in font weight 500 (I don't know enough about fonts to know if the font weight is a range, meaning it is available from 0 to 500, or if it is only available at 500 weight). At any case, it will not embed Cochin, unless I change the CSS to reflect that it should be 500 weight in the epub.

Does this help any?

[hidden.platypus]

I also note that I am no longer getting the font-stretch normal error that I got before.

The only error I get now is that there are no underscores in the font names.

[nabsltd]

Originally Posted by kovidgoyal

And how is calibre supposed to give you more information about a font that has not been embedded, since the only information it has is the information already visible to you in the CSS rules?

In the editor, when you double-click on a font in the "Manage Fonts" dialog, you get something like the first attachment, which shows four font files and information about the fonts in those files. This information has been retrieved from the font files, not my CSS, which has only:

.text-monospace {
	font-family: "Consolas", "Courier New", "Courier Std", "Courier", "DejaVu Sans Mono", monospace;
	font-size: 0.80em;
}

On the other hand, if you go to Preferences->Conversion->Common Options->Choose Font Family, clicking on a font there gives you more information about it. Not for Consolas, which is a relatively simple font, but something that has a font-stretch that isn't "normal", is one thing extra that does show up.

So, what I was asking was for you to show that same info in the dialog that pops up from the editor.

As for the rest, stop caring about what is in the CSS and just let us embed a font by choosing a file. Put the font file in the right place in the ebook, add a perfectly-matching @font-face rule for that font file, and then let us worry about writing selectors that match the @font-face rule. That would end the issue about trying to "match" the CSS selector to the font files on disk, which is what causes all the questions here in the first place. It would also allow people to embed fonts that they know they need, but may not have a specific selector that matches yet.

For example, I might want to make sure I embed all 4 versions of a font, even though there isn't an exact match in the ebook CSS selectors for the "Bold Italic" version, because there might be a user stylesheet or renderer stylesheet that makes something render that way (e.g., by adding bold when a word is selected for defining).

Even without that, we also need to be able to just embed less than "All fonts". For example, my selector above is a somewhat generic one for monospace, and covers pretty much all the fonts in the order I would like that selector to display. Because of that, I don't want to embed any of those fonts in the book, but in order to get the really special font embedded, I have to put all those in the book, too, then remove them.

There is no such thing as font-weight: medium

Doh! I was looking at "font-weight" and clicked "font-size" at that same reference.

[kovidgoyal]

@Divingduck: As I suspected, that is not a regular font file. It's the light variant of calibri, the required css rule for embedding it is:

font-family: Calibri
font-weight: 300

change the css in your document to that and it will be embedded.

There is no way for calibre to get that information from the docx since as you can see from fontTable.xml the family name is given as "Calibri Light" and there is no information on the weight. As I said to hidden.platypus, the only way for calibre to get that information is to scan for the fonts on the system while running the docx input plugin, and I dont want to do that as it fragile, slow and gives different results depending on what system it is run on.

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]

@nabsltd: Umm if you just want to directly embed a font file, simply use the File->New file->Import font

The purpose of the *Embed fonts tool* is to try to *automate* embedding of existing referenced fonts.

And once again, information for a font can only be shown if calibre knows what font file is involved, which it does not if it could not find a matching font file in the first place. In the case of Choose Font Family you are choosing a font family from all existing files on the system, so calibre has all the information from the font files. In the case of Embed referenced font, calibre has to go from a CSS font spec to a font file. When that process fails, there is no font file to get information from. I dont know how to put it any clearer than that.

@hidden.platypus: In that case open a bug report and attach the docx file with the embedded fonts.

[nabsltd]

Originally Posted by JSWolf

As for font weight, don't use a number. It usually doesn't work.

Except for when you have to, like if the "Bold" font is actually "demi" (weight 600) instead of "bold" (weight 700). Or, if the "normal" version is actually "medium" (like all the DejaVu fonts) in the font file. Then, you must use weight of 500 instead of "normal" (which is 400).

This, in a nutshell, is exactly why requiring the CSS selector exactly match the font on disk before it can be embedded is the wrong way to do it. 99% of the time, we know exactly what font file we want to embed, and can then write CSS that matches it after it is embedded.

Or, you can just "lie" in the CSS and make sure things match. This is how every ebook produced by the big publishing companies does it, like this snippet from one:

@font-face {
font-family: "MinionPro-SemiboldCnIt";
font-style: normal;
font-weight: normal;
src:url("../fonts/00004.otf");
}

span.font2 {
font-family: "MinionPro-SemiboldCnIt";
}

Given the CSS selector, Calibre wouldn't find the font that was actually embedded in the ebook, instead requiring the following selector (I know, because I have that font, straight from Adobe, and that's what it took to match it, because that's what's in the font file):

span.font2 {
font-family: "Minion Pro";
font-weight: 600;
font-stretch: condensed;
}

And, yet, the CSS in the ebook worked perfectly, and the font showed up where it was supposed to.

[nabsltd]

Originally Posted by kovidgoyal

@nabsltd: Umm if you just want to directly embed a font file, simply use the File->New file->Import font

That doesn't embed the font...it merely imports the file. How about the CSS @font-face rule that matches it? Calibre should also add that.

And once again, information for a font can only be shown if calibre knows what font file is involved, which it does not if it could not find a matching font file in the first place.

Right, but all that has to match is the name. That's good enough to get to the file for most people, but Calibre still won't embed the font unless we make the CSS selector an exact match, which is what the pain is all about.

In the case of Embed referenced font, calibre has to go from a CSS font spec to a font file. When that process fails, there is no font file to get information from. I dont know how to put it any clearer than that.

No font file to get information from? Oh, really? Try the following selector:

.testing {
font-family: "Arial";
font-weight: 200;
}

It will fail miserably to embed any font. Yet, if you double-click on "Arial" in the "Manage Fonts" dialog, you get a list of every font named "Arial" installed on your system, and some information about each font. Where did Calibre get that information? From the font files, right? And, all it needed to make the match was the font name, which we always have.

All I'm asking for is that dialog show every piece of information required to make the CSS match the font file. Hell, you could show a copyable CSS selector, if you wanted.

[kovidgoyal]

And as promised, here is a commit implementing a more informative message when embed fonts fails to find a matching font.

https://github.com/kovidgoyal/calibr...9267c29b4982da

For example, in the case of Calibri Light that Divingduck attached, the message looks like:

Failed to find a font in the "Calibri Light" family matching the CSS font specification:

* font-weight: 400
* font-style: normal
* font-stretch: normal

Available fonts in the family are:

/usr/share/fonts/vista/CALIBRIL.TTF

* font-weight: 300
* font-style: normal
* font-stretch: normal


/usr/share/fonts/vista/CALIBRILI.TTF

* font-weight: 300
* font-style: italic
* font-stretch: normal

[kovidgoyal]

Originally Posted by nabsltd

That doesn't embed the font...it merely imports the file. How about the CSS @font-face rule that matches it? Calibre should also add that.

Add it where? And given the way that @font-face works in CSS, adding ti manually is trivial. By that I mean that regardless of what you put in the rule, as long as you get the file name correct, the rule will work.

Right, but all that has to match is the name. That's good enough to get to the file for most people, but Calibre still won't embed the font unless we make the CSS selector an exact match, which is what the pain is all about.

No it most definitely is not enough to get a file. 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.

All I'm asking for is that dialog show every piece of information required to make the CSS match the font file. Hell, you could show a copyable CSS selector, if you wanted.

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:

I suppose I could have the embed font button popup a report that shows why fonts with matching family names did not match fully.

[kovidgoyal]

Originally Posted by kovidgoyal

Add it where?

https://github.com/kovidgoyal/calibr...2455e10058a845

[Divingduck]

Hi Kovid,
thanks for explaining the algorithms. Now I understand (hopefully) a bit better why calibre can't find the font.

I need to read all the other stuff from @nabsltd once more to get his input sorted in my head too.

Your idea for having a fall back mechanism and better information about a font what cant be found is a much better as it is for now.

I have maybe a addition idea for some when in the future. The main problem is, if I understood you correct, to know what matching font is really available in an operating system and that it is not a good idea to scan a complete font repository for each embedding action. This I can fully understand.
I don't know how much work it is, but what is, if you create an internal cache file of all fonts with a possibility that a user can activate manually a new/updating query with maybe as well the opportunity to provide additional path information for a not standard location in addition. This has for you the benefit not to initialize a time and resource consuming system wide search every time for a font and you have all needed information available on one place. As user I can initialize an update if needed and have no problem with timing issues as I know that will take some time to do that job. I guess, most users do not often change fonts so the information in a cache file are normally valid for a longer time frame. Only an idea.

Best regards,
DivingDuck

[kovidgoyal]

@Divingduck: I changed my mind and decided to add some code to the docx input plugin to try to figure out the correct css properties for fonts in docx files, when they are present on the computer during comversion. calibre already maintains a font cache. My main concern was not the performance, but the non-reproducability (the results fo the conversion depend on the fonts isntalled on the system -- but on further reflection, I think it is worth it)

See https://github.com/kovidgoyal/calibr...9fe21c422fa642