In the Zilla Slab fonts in OTF format there seem to be many thousands of characters (code-points) defined for which no glyphs are specified within the font itself. In OTF format there are thousands of code-points/characters defined, but in both OTF and TTF format there are only ~512 characters for which glyphs are actually defined (there are a total of ~1056 glyphs per font file, as some of the ~512 characters may have multiple associated glyphs).
This produces weird results in Windows’ Character Map. Some characters show only the ‘undefined’ symbol, while others seem to display glyphs borrowed from somewhere else (presumably some sort of emulation feature). Looking within the font in FontCreator, so far I cannot figure out why this is happening.
Worse that the above odd behaviour, this flawed font structure is apparently also preventing embedding of the fonts (or subsets thereof) into PDF files — even if none of those questionable characters are used in the font.
I have described this at length from the PDF-creation perspective on the Tracker Software forum for PDF-XChange Editor; the staff there are pretty good when it comes to general PDF issues, but it doesn’t look as though I’m going to get a lot of insight there on the fundamental font issues.
I’d be interested to know the following.
Do others also experience the same strange/defective behaviour with the OTF files for this font family?
Where is the setting (or settings) that have caused all of these code-points to be defined?
How can I remove the code-points that don’t have any associated glyphs? (I tried loading the fonts into FontCreator and exporting them to new file names, still as OTF with cubic CFF (PostScript) outlines, but the glyphless code-points remained. The problems of glyphless characters and PDF-unembedability went away when I exported the fonts to new files as OTF with quadratic TTF outlines, but the resulting fonts didn’t look/behave quite the same as the original fonts.)
I have access to FontCreator version 11.5, Professional Edition.
Screenshots from Character Map showing Zilla Slab Medium characters with no glyph associated within the font variously represented as: blank glyphs; ‘undefined’ glyph; glyphs borrowed from some other font (emulation?).
Screenshot from FontCreator showing Zilla Slab Medium font information
Screenshots from FontCreator showing Zilla Slab Medium Unicode and Code Page character ranges as initially displayed
Screenshots from FontCreator showing Zilla Slab Medium Unicode character range details as initially displayed
Screenshots from FontCreator showing Zilla Slab Medium Code Page character range details as initially displayed
Screenshots from FontCreator showing Zilla Slab Medium Unicode and Code Page character ranges after recalculating
Specifically I have version 11.5.02430 (64-bit), which was released on the 5th of December 2018, and retained the most-recent-version status until the 7th of May 2019. Which is roughly four years ago. Certainly I realise I don’t have the latest version, but given that I am not a professional type designer or graphic designer, but merely an interested amateur, I should be getting kudos for having purchased any licence at all — if I may say so.
I also would highlight the fact that the Zilla Slab fonts were released in mid-2017. (Also my MS Windows operating system and my MS Office application suite pre-date 2019.)
So using a version of FontCreator that was current in mid-2019 to resolve issues with a font that was released in mid-2017 doesn’t seem unreasonable.
So why in particular is this font creating defective behaviour?
Following your comment I have noticed that some other OTF fonts likewise have unmapped glyphs displayed in Character Map (e.g Courier Std). But not all: for example, I got part-way through creating a handwriting-based font in FontCreator, exported it as an OTF file, and only ~252 characters are listed for it in Character Map (albeit that several don’t have glyphs mapped to them). See attachments.
That implies that there is some parameter or setting that can be altered to change which characters are claimed to be somehow-representable by the font.
Or, in other words, (how) can I turn off the specific OpenType layout feature that allow access to (most of) the unmapped glyphs?
Well, sure, if I were a professional doing this every day, or every week, or even every month, I’d be open to that. If I need to do this once every few years, it’s not worth it.
Rather than trying to upsell me (with no justification specific to the matter at hand), are you able to provide any concrete advice on my actual concern, which is the inability to embed this font into PDF files (which I presume is related to some mismatch between characters and glyphs)?
By the way, it is actually not an inherent problem with OTF particularly, nor with glyphs being unmapped per se, nor the use of cubic CFF (“PostScript”) outlines, because I can successfully embed Courier Std into a PDF file using either Editor (but not Word), which is an OTF font containing CFF outlines and characters without mapped glyphs.
I don’t understand why, exactly, that Windows Character Map displays a lot of character sets that each contain very few glyphs or none. The CJK character sets are presumably displayed only because the font contains the double square brackets []. Since the other glyphs in that character set do not exist, a substitute font is used.
MainType 11.0 is available as a free, unlimited trial version, which supports a maximum of 2,500 fonts, and may not be used commercially. It displays only the 513 mapped characters in the character panel, which is much less confusing.
The font contains a lot of OpenType features, which use the unmapped glyphs. By enabling the small capitals feature, you can see them in used in the preview panel.
If you open the OpenType Editor in FontCreator 11.5 you should be able to see the extra languages that are defined.
OK, let’s not worry about that too much. I initially had the misapprehension that it was specifically related to the problem I had embedding this font.
Yes, that would be logical: FontCreator shows those two characters, 〚 and 〛, under Unicode > CJK Punctuation and Punctuation.
But on the other hand Character Map also shows what looks like the complete Armenian alphabet, and I can’t see a similar underlying reason for that.
Thank-you for your time to test that. Could you please confirm the details of the testing: which version (1.001 or 1.002), which format (TTF or OTF), which specific font(s) within the family, which PDF engine (e.g. the built-in Word function)?
I was also able to export PDF files from Word that “use” the font. The major difficulty I had/have is in embedding the font using the OTF format (any font within the family, any version). Could you please confirm whether you were able to do that?
By the way, I have been poking around inside the source code, and am not entirely sure that the fonts were perfectly fine.
I have lodged an issue with the Zilla Slab fonts on GitHub.
It’s looking even more like there was a peculiar glitch in the fonts: accidental omission of the VendorID SOMEHOW led to a prohibition on embedding some fonts within the family.
Further details posted at https://forum.tracker-software.com/viewtopic.php?p=169823#p169823
I totally forgot about the last sentence I wrote in this tutorial, but it might be important to you:
If you work with Word, it is wise to use OpenType fonts with TrueType based outlines, as those can be embedded in exported PDF documents. Zilla.pdf (9.97 KB)
Many thanks for testing that, Erwin.
For the benefit of others reading this forum, the output has the correct appearance visually at a glance, but this has been achieved by rasterising the characters (to form high-resolution bitmap images), rather than embedding the font.
And thanks a lot also for this tip.
After all the testing I’d done recently, I had a suspicion that Word might not be able to embed the CFF (PostScript) outlines, but I hadn’t conclusively established it. Indeed I was also thinking it might be because I’m not using the latest version of Word. It’s helpful to get your confirmation that this is a known issue in Word.
