Embedded Fonts on DOCX -- Calibre partially fails, any automated fix?

GranitStateColin · 03-30-2021, 05:52 PM

I'm not sure if it's Word's fault or Calibre's, but here's the problem: if you embed a font in Word (only TrueType and OpenType TrueType fonts are embeddable, not PostScript fonts), then save it as a DOCX, then do a DOCX -> EPUB conversion in Calibre, the font name WILL HAVE SPACES (100% of the time), which makes the EPUB unusable through many outlets.

Even if the font name and font file don't have any spaces, Calibre or Word adds spaces, a hyphen, and the word Regular (or Bold, Italic, or BoldItalic) to the end. For example if you have a font named MyFont, and a font file MyFont.ttf, embed and save that, then when you convert that DOCX to EPUB in Calibre, when you look at the resulting EPUB file, the font will end up as "MyFont - Regular.ttf". To be clear, I've even tried using FontLab to convert fonts into new font files specifically to confirm there is nothing in the font name that would cause this.

I had originally thought this was Word's fault (and it still might be), but if you export that same Word document to PDF file, and then in Adobe Reader -> File -> Properties -> Fonts, it will appears as "MyFont-Regular.ttf" (no spaces). So both PDF and EPUB have the word "Regular" added, but only Calibre's conversion seems to add or maintain those extra spaces. So at least in part, this appears to be a Calibre defect for adding (or keeping) the extra spaces.

As some of you know, spaces in a font name will cause EPUB files to be summarily rejected by several EPUB outlets. Apple will almost always reject them. Google and Kobo will frequently reject them (sometimes they slip through).

As a work-around, if you use Calibre's own Edit Book -> Run Check -> it shows the font errors as warnings. If you then use its auto-fix, it fully fixes the problem. HOWEVER, if I'm trying to help non-technical authors or provide them with a Word template to help them create EPUB files, I don't want to tell them they then need to go in and remove theses errors. That's a trivial step for those of us comfortable with the process, but it's a hassle and problem for others. And it's just annoying to get error messages every time.

Is there any other way to either:

1. Avoid ending up with spaces in the font file names in the first place

2. Automate the fix from the Book Editor

3. Any other suggestions?

Thanks,
Colin

DNSB · 03-30-2021, 09:00 PM

What I've done when I've had issues with fonts is to rename the font files replacing spaces with underlines and then used FontForge to change the internal font name to match. This has to be repeated for all four variants (Regular, Bold, BoldItalic and Italic).

Quoth · 03-31-2021, 08:18 AM

It's not Word, or at least not only Word.
The Check tool using the ladybird icon also seems involved. It's also not always happening. So my plan is related to what DNSB suggests. I'm going to manually rename the font files by removing spaces and manually edit the CSS URL entry. There doesn't seem to be a problem with the names of the actual fonts, but the files. I've not had to rename anything IN the font files or change the font name in the CSS.

GranitStateColin · 03-31-2021, 09:16 AM

@Quoth, my issue is 100% consistent and repeatable. Changing the font name doesn't help, because Calibre (or possibly Word -- I can't check inside the DOCX file, because the font names are not directly visible in the included XML files inside the DOCX) changes the file names by the time they are included in the EPUB file.

There is an easy manual work-around per book -- just go into Book Edit and rename the font or run the autofix. That doesn't actually help me, because I need to avoid the problem in the first place, but if you're just trying to fix a specific book, this might be an appropriate solution for you.

This could be easily solved by what I suspect to be a near trivial update to the EPUB conversion. The Autofix-issues in Calibre's book editor already fixes this. If Calibre would simply remove (or avoid adding) spaces during conversion from DOCX -> EPUB, this problem would go away. I had submitted a bug report on this and the added spcase, but Kovid said that this font problem is just a warning-level issues, and doesn't actually affect real world usage.

Quoth · 03-31-2021, 12:19 PM

I now have italic Georgia failing every time.
This works to fix it: https://www.mobileread.com/forums/sh...0&postcount=14

Indeed this is a recent issue. I never had a problem in the last 5 years. I don't actually use Word in the last 6 years or more. LibreOffice Writer with and EXTRA save As with fonts embedded as docx.
I changed to Linux from Windows 7 (which I only used for about a month after XP) about four and half years ago.

It now affects most bold and italic face/styles every time. The steps in the other post fix it.

GranitStateColin · 03-31-2021, 01:57 PM

Hmm, reposting (as memory permits) because I've posted other comments since which have appeared, but this one from about 7-8 hours ago with the screen captures did not. Trying again in the hope it becomes visible this time with apologies if this ends up appearing twice:

Quote:

Originally Posted by DNSB

What I've done when I've had issues with fonts is to rename the font files replacing spaces with underlines and then used FontForge to change the internal font name to match. This has to be repeated for all four variants (Regular, Bold, BoldItalic and Italic).

@DNSB, I had tried that specifically, but with FontLab and TransType, before posting here, but it had no effect. Based on your post, installed and also tried FontForge, which did exactly the same thing: nothing. :-)

Here are screen shots showing the spaces removed from the font's name in FontForge, and yet added back in by Calibre (or Word) after embedding in the Word document and using Calibre to convert the DOCX -> EPUB.

Note in the FontForge page, the I've reduced the TTF name from "Avrile Serif - Regular" to "AvrileSerifRegular", but in Calibre, following the corversion, it shows as "AvrileSerif - Regular.ttf" So it keeps the space removal in the Family name, but adds spaces to separate the Style name.

DNSB · 03-31-2021, 04:47 PM

Quote:

Originally Posted by GranitStateColin

Hmm, reposting (as memory permits) because I've posted other comments since which have appeared, but this one from about 7-8 hours ago with the screen captures did not. Trying again in the hope it becomes visible this time with apologies if this ends up appearing twice:

@DNSB, I had tried that specifically, but with FontLab and TransType, before posting here, but it had no effect. Based on your post, installed and also tried FontForge, which did exactly the same thing: nothing. :-)

Here are screen shots showing the spaces removed from the font's name in FontForge, and yet added back in by Calibre (or Word) after embedding in the Word document and using Calibre to convert the DOCX -> EPUB.

Note in the FontForge page, the I've reduced the TTF name from "Avrile Serif - Regular" to "AvrileSerifRegular", but in Calibre, following the corversion, it shows as "AvrileSerif - Regular.ttf" So it keeps the space removal in the Family name, but adds spaces to separate the Style name.

I change the name under PS Names and TTF names and it seems to work for me. I think the family name under PS Names is the one that is displayed by most tools.

GranitStateColin · 03-31-2021, 05:25 PM

Quote:

Originally Posted by DNSB

I change the name under PS Names and TTF names and it seems to work for me. I think the family name under PS Names is the one that is displayed by most tools.

I think that's the same thing I did. Could you post a screen shot of what you think you're doing differently? Maybe I'm missing something obvious.

GranitStateColin · 03-31-2021, 05:46 PM

@DNSB, just continuing that prior comment, note 2 things with PS fonts that I think preclude that being a factor:

PS fonts already don't have any spaces in their names by default. Not sure why, maybe because they're older and spaces in names was a concern back when they were new, but in any case, PS font names don't have spaces in them by default. For example, Avril Serif - Regular.ttf in PS would already be AvrilSerif-Regular.otf.
You can't embed PS fonts in a Word document. You can only embed TT fonts (which includes OpenType fonts with TrueType Outlines).

For those reasons, I would be surprised if the PS section has any bearing on this. But I'll happily embrace my being completely wrong if it provides a solution to this problem. :-)

DNSB · 04-01-2021, 01:16 PM

Quote:

Originally Posted by GranitStateColin

@DNSB, just continuing that prior comment, note 2 things with PS fonts that I think preclude that being a factor:

PS fonts already don't have any spaces in their names by default. Not sure why, maybe because they're older and spaces in names was a concern back when they were new, but in any case, PS font names don't have spaces in them by default. For example, Avril Serif - Regular.ttf in PS would already be AvrilSerif-Regular.otf.
You can't embed PS fonts in a Word document. You can only embed TT fonts (which includes OpenType fonts with TrueType Outlines).

For those reasons, I would be surprised if the PS section has any bearing on this. But I'll happily embrace my being completely wrong if it provides a solution to this problem. :-)

When I look at a font, under PS names, the Fontname does not have spaces but the Family Name does as does the Name for Humans. The family name is what seems to be important under PS Names. For TTF Names, I remove the spaces from the Family and Fullname entries.

These choices date back to when the version of RMSDK used by Kobo sucked at introspecting fonts.

GranitStateColin · 04-01-2021, 05:30 PM

Quote:

Originally Posted by DNSB

When I look at a font, under PS names, the Fontname does not have spaces but the Family Name does as does the Name for Humans. The family name is what seems to be important under PS Names. For TTF Names, I remove the spaces from the Family and Fullname entries.

These choices date back to when the version of RMSDK used by Kobo sucked at introspecting fonts.

DNSB, you're right - you do need to make that change on the PS Names tab, even for the TT version of the font. But as you can see in the screen shots I attached above, that doesn't matter: even when it's all set correctly there with no spaces for for Fontname, Family Name, or Name For Humans, Calibre still adds in the spaces.

Specifically, what Calibre is doing is putting the Family Name, then a space, then a hyphen, then another space, then the Style (SubFamily). If Calibre were to use the Fullname instead (that's what you can set as "Name For Humans" on the PS Names tab), we could control it via the font editors (exactly as you've described), but Calibre doesn't do this.

Please, if you think I am mistaken on any of this, let me know. I'd much rather be wrong and have a solution than be right and stuck.

Thanks,
Colin

Quoth · 04-02-2021, 08:16 AM

The basic issue I have is that if you use Embed fonts on the GUI the font file names have spaces, which Check in Editor objects to. The GUI option adds the font file URL in the page.css, but if you use Check in the Editor (or manually) to remove the spaces then some fonts don't work on the Kobo.

If you use Embed fonts in the Editor, then they are embedded with font file names without spaces. They are all added to a new fonts.css file. The HTML files are updated automatically to include this. In this case Check finds no issues. It seems to work 100% if you embed at the GUI and then delete all the font files and then after fonts.css is created you delete all the font entries in page.css, it then only has the viewport margins (5 by default. Using zero is abysmal in some apps. Negative is only for personal use on a kindle)
The CSS names may still have spaces, but those are "quoted" so not a problem.

GranitStateColin · 04-02-2021, 12:51 PM

Quote:

Originally Posted by Quoth

The basic issue I have is that if you use Embed fonts on the GUI the font file names have spaces, which Check in Editor objects to. The GUI option adds the font file URL in the page.css, but if you use Check in the Editor (or manually) to remove the spaces then some fonts don't work on the Kobo.

If you use Embed fonts in the Editor, then they are embedded with font file names without spaces. They are all added to a new fonts.css file. The HTML files are updated automatically to include this. In this case Check finds no issues. It seems to work 100% if you embed at the GUI and then delete all the font files and then after fonts.css is created you delete all the font entries in page.css, it then only has the viewport margins (5 by default. Using zero is abysmal in some apps. Negative is only for personal use on a kindle)
The CSS names may still have spaces, but those are "quoted" so not a problem.

Quoth, interesting and thanks. Which Kobo has the problem? I may order one to test that. I need to make sure that these conversions work on all major e-readers. It had not occurred to me that the Auto-Fix in Calibre's e-reader might cause new problems for the fonts.

davidfor · 04-02-2021, 08:26 PM

Quote:

Originally Posted by GranitStateColin

Quoth, interesting and thanks. Which Kobo has the problem? I may order one to test that. I need to make sure that these conversions work on all major e-readers. It had not occurred to me that the Auto-Fix in Calibre's e-reader might cause new problems for the fonts.

If one Kobo device has a problem, they all will. Kobo uses the same firmware on all their current devices, and everything starting with the Touch. There are differences due to hardware, but, for the reading experience, this is mainly things like the default font size.

Quoth · 04-03-2021, 10:21 AM

And it's not a kobo issue.
Conversion GUI embed fonts does one thing. It may mostly be OK on most readers despite Check in Editor complaining. It puts spaces in the filenames. Using Fix/Auto fix or manual editing doesn't work, makes it worse!

Embed fonts in the Editor Tools does a rather different thing to the Conversion GUI and adds a fonts.css, updates an include in the HTMLs and uses filenames with no spaces. Check then finds no problems. Epub Check finds no problems. It works on everything.

Likely if something is broken on my Kobo Libra in epub2 mode, then it's broken everywhere except the laptop. The Calibre viewer is great to see gross mistakes on paragraph styles, broken links or faulty TOC/NCX. But it has no problem with lots of other broken things. Fonts will work.

03-30-2021, 05:52 PM	#1
GranitStateColin Member Posts: 13 Karma: 10 Join Date: Jul 2017 Device: none	Embedded Fonts on DOCX -- Calibre partially fails, any automated fix? I'm not sure if it's Word's fault or Calibre's, but here's the problem: if you embed a font in Word (only TrueType and OpenType TrueType fonts are embeddable, not PostScript fonts), then save it as a DOCX, then do a DOCX -> EPUB conversion in Calibre, the font name WILL HAVE SPACES (100% of the time), which makes the EPUB unusable through many outlets. Even if the font name and font file don't have any spaces, Calibre or Word adds spaces, a hyphen, and the word Regular (or Bold, Italic, or BoldItalic) to the end. For example if you have a font named MyFont, and a font file MyFont.ttf, embed and save that, then when you convert that DOCX to EPUB in Calibre, when you look at the resulting EPUB file, the font will end up as "MyFont - Regular.ttf". To be clear, I've even tried using FontLab to convert fonts into new font files specifically to confirm there is nothing in the font name that would cause this. I had originally thought this was Word's fault (and it still might be), but if you export that same Word document to PDF file, and then in Adobe Reader -> File -> Properties -> Fonts, it will appears as "MyFont-Regular.ttf" (no spaces). So both PDF and EPUB have the word "Regular" added, but only Calibre's conversion seems to add or maintain those extra spaces. So at least in part, this appears to be a Calibre defect for adding (or keeping) the extra spaces. As some of you know, spaces in a font name will cause EPUB files to be summarily rejected by several EPUB outlets. Apple will almost always reject them. Google and Kobo will frequently reject them (sometimes they slip through). As a work-around, if you use Calibre's own Edit Book -> Run Check -> it shows the font errors as warnings. If you then use its auto-fix, it fully fixes the problem. HOWEVER, if I'm trying to help non-technical authors or provide them with a Word template to help them create EPUB files, I don't want to tell them they then need to go in and remove theses errors. That's a trivial step for those of us comfortable with the process, but it's a hassle and problem for others. And it's just annoying to get error messages every time. Is there any other way to either: 1. Avoid ending up with spaces in the font file names in the first place 2. Automate the fix from the Book Editor 3. Any other suggestions? Thanks, Colin

03-31-2021, 12:19 PM	#5
Quoth the rook, bossing Never. Posts: 11,158 Karma: 85874891 Join Date: Jun 2017 Location: Ireland Device: All 4 Kinds: epub eink, Kindle, android eink, NxtPaper11	I now have italic Georgia failing every time. This works to fix it: https://www.mobileread.com/forums/sh...0&postcount=14 Indeed this is a recent issue. I never had a problem in the last 5 years. I don't actually use Word in the last 6 years or more. LibreOffice Writer with and EXTRA save As with fonts embedded as docx. I changed to Linux from Windows 7 (which I only used for about a month after XP) about four and half years ago. It now affects most bold and italic face/styles every time. The steps in the other post fix it. Last edited by Quoth; 03-31-2021 at 12:24 PM.

03-31-2021, 05:46 PM	#9
GranitStateColin Member Posts: 13 Karma: 10 Join Date: Jul 2017 Device: none	@DNSB, just continuing that prior comment, note 2 things with PS fonts that I think preclude that being a factor: PS fonts already don't have any spaces in their names by default. Not sure why, maybe because they're older and spaces in names was a concern back when they were new, but in any case, PS font names don't have spaces in them by default. For example, Avril Serif - Regular.ttf in PS would already be AvrilSerif-Regular.otf. You can't embed PS fonts in a Word document. You can only embed TT fonts (which includes OpenType fonts with TrueType Outlines). For those reasons, I would be surprised if the PS section has any bearing on this. But I'll happily embrace my being completely wrong if it provides a solution to this problem. :-)

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Question - Calibre seems not to always pick up cover from DOCX? Fix?	Aodhfin Kavanaug	Conversion	1	06-28-2015 11:59 PM
PRS-350 PRS-350 only partially displays embedded font	baliantas	Sony Reader	6	11-07-2011 07:49 AM
Embedded fonts, Calibre, and choice of fonts	AlexBell	ePub	8	05-30-2010 06:00 AM
embeding fonts to epubs in Calibre - automated process	gulo	Calibre	3	01-27-2010 01:23 PM

03-30-2021, 09:00 PM	#2
DNSB Bibliophagist Posts: 35,405 Karma: 145435140 Join Date: Jul 2010 Location: Vancouver Device: Kobo Sage, Forma, Clara HD, Lenovo M8 FHD, Paperwhite 4, Tolino epos	What I've done when I've had issues with fonts is to rename the font files replacing spaces with underlines and then used FontForge to change the internal font name to match. This has to be repeated for all four variants (Regular, Bold, BoldItalic and Italic).

03-31-2021, 08:18 AM	#3
Quoth the rook, bossing Never. Posts: 11,158 Karma: 85874891 Join Date: Jun 2017 Location: Ireland Device: All 4 Kinds: epub eink, Kindle, android eink, NxtPaper11	It's not Word, or at least not only Word. The Check tool using the ladybird icon also seems involved. It's also not always happening. So my plan is related to what DNSB suggests. I'm going to manually rename the font files by removing spaces and manually edit the CSS URL entry. There doesn't seem to be a problem with the names of the actual fonts, but the files. I've not had to rename anything IN the font files or change the font name in the CSS.

03-31-2021, 09:16 AM	#4
GranitStateColin Member Posts: 13 Karma: 10 Join Date: Jul 2017 Device: none	@Quoth, my issue is 100% consistent and repeatable. Changing the font name doesn't help, because Calibre (or possibly Word -- I can't check inside the DOCX file, because the font names are not directly visible in the included XML files inside the DOCX) changes the file names by the time they are included in the EPUB file. There is an easy manual work-around per book -- just go into Book Edit and rename the font or run the autofix. That doesn't actually help me, because I need to avoid the problem in the first place, but if you're just trying to fix a specific book, this might be an appropriate solution for you. This could be easily solved by what I suspect to be a near trivial update to the EPUB conversion. The Autofix-issues in Calibre's book editor already fixes this. If Calibre would simply remove (or avoid adding) spaces during conversion from DOCX -> EPUB, this problem would go away. I had submitted a bug report on this and the added spcase, but Kovid said that this font problem is just a warning-level issues, and doesn't actually affect real world usage.

04-02-2021, 08:16 AM	#12
Quoth the rook, bossing Never. Posts: 11,158 Karma: 85874891 Join Date: Jun 2017 Location: Ireland Device: All 4 Kinds: epub eink, Kindle, android eink, NxtPaper11	The basic issue I have is that if you use Embed fonts on the GUI the font file names have spaces, which Check in Editor objects to. The GUI option adds the font file URL in the page.css, but if you use Check in the Editor (or manually) to remove the spaces then some fonts don't work on the Kobo. If you use Embed fonts in the Editor, then they are embedded with font file names without spaces. They are all added to a new fonts.css file. The HTML files are updated automatically to include this. In this case Check finds no issues. It seems to work 100% if you embed at the GUI and then delete all the font files and then after fonts.css is created you delete all the font entries in page.css, it then only has the viewport margins (5 by default. Using zero is abysmal in some apps. Negative is only for personal use on a kindle) The CSS names may still have spaces, but those are "quoted" so not a problem.

04-03-2021, 10:21 AM	#15
Quoth the rook, bossing Never. Posts: 11,158 Karma: 85874891 Join Date: Jun 2017 Location: Ireland Device: All 4 Kinds: epub eink, Kindle, android eink, NxtPaper11	And it's not a kobo issue. Conversion GUI embed fonts does one thing. It may mostly be OK on most readers despite Check in Editor complaining. It puts spaces in the filenames. Using Fix/Auto fix or manual editing doesn't work, makes it worse! Embed fonts in the Editor Tools does a rather different thing to the Conversion GUI and adds a fonts.css, updates an include in the HTMLs and uses filenames with no spaces. Check then finds no problems. Epub Check finds no problems. It works on everything. Likely if something is broken on my Kobo Libra in epub2 mode, then it's broken everywhere except the laptop. The Calibre viewer is great to see gross mistakes on paragraph styles, broken links or faulty TOC/NCX. But it has no problem with lots of other broken things. Fonts will work.

Advert

Advert