Conversion Problem: Embedded OpenType TT fonts in DOCX files
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
calibre |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
PROBLEM (100% consistent and reproducible)
When embedding OpenType Layout fonts with TrueType outlines in a Word DOCX file and then converting to EPUB in Calibre, and performing the Edit Book -> Run Check test, it will report font problems due to the spaces in the filenames.
Here's an example of the message in the Calibre editor when embedding Bookman Old Style:
"The filename fonts/Bookman Old Style - Regular.ttf contains unsafe characters, that must be escaped, like this fonts/Bookman%
This does not happen with OpenType fonts with PostScript outlines, but only because they are not embeddable.
VERSIONS
Confirmed in Calibre 5.14 on Windows 10 H2 (Build 19042.867) on a DOCX generated by Word 16.0.13801.20288.
AVAILABLE WORKAROUND
The automated fix in the Book Editor works perfectly every time, so we know that Calibre already has the full capability to address these proactively at time of conversion: E.g., The link that says, "rename the file fonts/Avrile Sans - Regular.ttf to fonts/Avrile_
SUGGESTED FIX/SOLUTION
As part of the conversion process from DOCX to EPUB/AZW3, please convert the font names to exclude spaces in the final names. Convert the spaces to underscores. If there is a reason to avoid doing this, then please provide this as a new conversion option on the DOCX input tab of the Conversion window.
ADDITIONAL BACKGROUND AND DETAILS
This emerges from what is really more of a Word bug or odd design choice (generates font file names based on font family and style names and not using the font file name, which means users have no control over the embedded font file names), but not something MS is likely to fix anytime soon. Therefore, while the problem is with the DOCX file generation by Word, the only way to fix this lies with Calibre.
description: | updated |
The message in the editor is a warning, the file names with spaces work
just fine in every reader that actually supports embedded fonts, I know
of. As such I dont feel the need to add processing time to the
conversion to fix a not real problem.
status wontfix