Problem embedding font with "missing glyph"

[DIV]

I have downloaded the Zilla Slab font family, and spent time applying it to a moderately lengthy & complex document.
Now I am in the position where when I try to make a PDF, I cannot embed that font!

I generate the initial PDF from MS Word. Regardless of whether I ask for PDF/A or not, Word won't (can't) embed it.

When I try to save out from Editor as either PDF/A or PDF/X, Editor: tries to embed the font(s), finds some errors ("glyph is missing in embedded font"), reports errors having been fixed, ...and then fails to save any file.

Whether "Rasterize the unembedded fonts" is selected or not doesn't seem to make any difference.

The problem seems to be that the font explicitly defines a huge number of code positions without specifying any corresponding glyph, as seen in Character Map.

Please help!
The only options I seem to have at the moment are all bad.

• Accept the PDF without the font embedded, which means that recipients won't see what I intended.
• Let Word rasterise the unembedded Zilla Slab fonts, which then get output as rasterised images of entire paragraphs, which looks OK from a distance (but not close up), but is not searchable, text cannot be highlighted, and so on.
• Manually edit all fonts in the family to remove the troublesome codepoints. This seems like a nightmare to do manually, and I don't even know if it would solve the problem.
• Go back to 'square one' and find another font family to format my document with.

1. Is this a bug with the font?
2. Does the PDF specification prevent fonts with "missing" glyphs from being embedded?
3. Can Editor be tweaked to handle this (provide an automatic fix)? E.g. automatically remove codepoints with missing glyphs?

It's possible that the issue may be that I've inadvertently used one of the codepoints with a missing glyph, and Word has silently rendered it with a 'similar' font, which is OK for viewing in Word and printing, but — perhaps — not OK for making a PDF with the font embedded.
If so, then it would allow another possible workaround:

• Manually hunt through the text in my document, looking for 'exotic' characters specified as Zilla Slab but actually rendered with glyphs from another font (because the glyphs are missing in Zilla Slab).

Strangely, Character Map shows Zilla Slab to include a glyph for U+2714 (Heavy Check Mark), but when I tried to include it in my document, Word refused to let me set the font to Zilla Slab, but instead rendered it in Segoe UI Symbol. Therefore I didn't use that character, but instead just used the glyph from Wingdings. Nevertheless, I noticed that a subset of SegoeUISymbol is included in my PDF, so perhaps there was another character doing something similar that I didn't notice.

I can't be certain where I downloaded Zilla Slab from (it was last year, I think): more likely the github link, but it's readily available elsewhere too.
https://en.wikipedia.org/wiki/Zilla_Slab
^^Note forum syntax glitch.

—DIV

[Tracker Supp-Stefan]

Hello DIV,

Thanks for the post. I asked a colleague who works on fonts to take a look, and he says that we will need some extra details before we can start looking into this.

First - we will need:
- The actual font you have on your machine (you can extract it from C:\Windows\Fonts) or a link to the exact same copy of the font that you have installed. Downloading the font from a different location could give us a different result in our tests - that's why we need an exact copy of yours.
- The original Word file and a step-by-step description of how you are converting the file to PDF (e.g. is it an internal tool in Word, our add-in or a drag and drop of the .docx file over the Editor).
- The resulting PDF(s).

Once we have those - we can look further into this.

Kind regards,
Stefan

[DIV]

Hello, Stefan.

Attached is a (redacted) copy of the final page of the file.

V_E98rcA_Eng_12_redacted.pdf

(111.74 KiB) Downloaded 11 times

The original PDF file was produced by MS Word.
Microsoft Home & Office Student 2013 (version 15.0.5553.1000), running on Windows 8.1 64-bit.
From the menu I navigate through File > Export > Create PDF/XPS

AFAIK this is a built-in tool that shipped as an integral part of MS Word.
For this particular file I unticked the option for PDF/A output, but it doesn't really seem to matter in this part of the process, because Word doesn't embed the Zilla Slab fonts in either case.

This page was then extracted from the original (multipage) PDF file within PDF-XChange Editor.
PDF-XChange Editor Plus (version 9.4, build 364.0, with "Enhanced OCR"), installed & running on Windows 8.1 64-bit.

The most important point is that the aforementioned problem persists. The Zilla Slab fonts are not embedded, and cannot be embedded when I try within Editor to resave this as PDF/A. Please see the screenshots below.

Note: I tried this for all of the individual extracted pages, and the same types of errors occurred for all of them; the only differences were in which specific members of the font family were mentioned (e.g. not all pages would have the bold & italic version of the font).

I am not going to be posting the original Word file here. If I can isolate the issue, I can post a cut-down file — or a sample file.

The fonts are version 1 of the Zilla Slab font family.
I actually downloaded them in 2019 (2019-05-23), as it happens.
The zip file is named version "1.0" (presumably I named it that based on the website, as that would be my usual practice).
Internally Windows Font Viewer reports that they are labelled as version "1.1" ...

... whereas FontCreator reports that they are labelled as version "1.001" ...

I suppose the latter is the most trustworthy; Wikipedia reports the latest release version to be "1.002".
I reckon you'd be capable enough of downloading the matching version yourself, but to avoid doubt (and given that this is stated to be a free-to-use and open-source font family) I attach the fonts hereto.

fnt_Zilla-Slab_Fonts_v1-0.zip

(3.81 MiB) Downloaded 5 times

By the way, here is a look at the number of glyphs (1056) in Zilla Slab Regular, along with some other statistics.

That's almost everything you asked for. Hopefully it's enough to start delving into.

I'll keep investigating at my end too.

—DIV

[Tracker Supp-Stefan]

Hello DIV,

Thanks for the above, however we will need both the .docx file and the resulting PDF - so please redact the Word file, and share with us a copy of that redacted document + the PDF file you get from exactly the sample Word file that you share with us.

Kind regards,
Stefan

[DIV]

Hi, Stefan.

After one failed attempt, I now have a simple sample/test document that seems to reproduce the issue. Notably I don't think there are any exotic characters included. The most exotic character is a 'bullet'.
Please refer to the attachments: DOCX file (zipped, as required by this forum), PDF file (created by Word, as described at length above), and screenshots. I hope at this point they're fairly self-explanatory.

Thanks for looking into this,
DIV

PDF_test_embedding_3.docx.zip

(144.88 KiB) Downloaded 4 times

PDF_test_embedding_3.pdf

(138.53 KiB) Downloaded 3 times

P.S. It's not clear to me why you "need" the Word document to work on this, because — from my point of view — a user could also be in the situation of having been sent the original PDF file (without embedded fonts) and wondering why they can't create a PDF/A version even after installing the requisite fonts onto their system. Or the user might indeed be the author of the source file, but, after making the PDF themself some time ago (without embedded fonts), the source file somehow got lost/corrupted/deleted, so they want to use the original PDF file as the basis for creating a new PDF/A version. Admittedly those are situations that may be less likely to occur ...but they could occur.

[Tracker Supp-Stefan]

Hello DIV,

Many thanks for the samples!
I've now looked at the files provided - and after installing the TTF variant of your font into windows - I do not really see any issues.

I managed to get this file using the word's built in export to PDF feature:

Export_from_wort_to_PDF_directly.pdf

(229.52 KiB) Downloaded 2 times

This file using our add-in in word (default settings, no forced font embedding - so the fonts are not embedded in the file:

Word_to_PDF_test.pdf

(22.21 KiB) Downloaded 3 times

And then I was able to convert your PDF file (from your above post) to PDF/A-2b one without any issues:

PDF_test_embedding_3_A2b.pdf

(178.83 KiB) Downloaded 3 times

So can you please check and confirm which version of the font did you install on your end - as there appear to be 4 different folders in that zip file you provided for the font? I used the TTF set.

Kind regards,
Stefan

[DIV]

Hi, Stefan.

Thanks for your update.

I'm pretty certain that there's a problem — we just need to get things set up for you to reproduce it.

I was using the [url=https://en.wikipedia.org/wiki/OpenType]OTF[/url] font files (a newer specification than [url=https://en.wikipedia.org/wiki/TrueType]TTF[/url], albeit related).
Sorry I didn't mention it. I have to admit I didn't even look inside the zip file: apparently what I'd done in 2019 was to only extract the OTF files from that archive.
There were a couple of subtle clues in the screenshot from Windows Font Viewer and the second screenshot (of font properties) from FontCreator in my previous forum posting. But I can see that those clues could easily be missed.

Just in case that's still not convincing, I had a look at the installed files, and they are indeed OTF format.

I would appreciate it if you can try again.

By the way, although you apparently were able to successfully produce the PDF/A file, I notice that there were still a couple of 'errors' displayed. I would be interested to know if you can provide further information about the meaning of the message "Font [...] was fixed: embed fontfile (nnn):". What was wrong, what was fixed, and what do the numbers mean?

—DIV

P.S. Where can I find more information about your add-in for Word? I recall previously there was only a "lite" printer driver that we could freely download and use (PDF-XChange Lite pdfSaver???).

P.P.S. Then again, perhaps you might have stumbled onto a workaround. Perhaps it will work for me if I use the TTF files instead? But I don't want to jump into that immediately. I'd like to be confident that it's going to help, so I'd prefer to see your results with the OTF files. And furthermore I need to consider whether there would be any disadvantage of using the TTF fonts: off the top of my head, OTF has better support for things like ligatures and alternative numerals (e.g. lining versus traditional), although I presume that there'd be no difference in outcome unless such features have actually been used in the document (I thought I might have turned on those features, but apparently I didn't, according to the screenshot below pertaining to the document of concern). Further digging into the font using FontCreator indicates that the ZIlla Slab OTF files use [url=https://en.wikipedia.org/wiki/OpenType#Description]CFF[/url]-based contours. Feel free to comment on use of the TTF files as a possible workaround too.

image(1).png (32.62 KiB) Viewed 88 times

[DIV]

FWIW, I notice that Editor does report that subsets of the relevant Zilla Slab fonts have indeed been embedded in the last PDF file that you created, albeit with Type = "TrueType" — in other words, TTF.

—DIV

[Tracker Supp-Stefan]

Hello DIV,

Yes - I agree with you that there is still likely an issue - however it's likely only related to the OT version of the font on your machine.
That's why we asked for exactly the font you used - but when you have me an archive with multiple versions - I chose the TTF.
My True Type variant is apparently working OK.

And while there is an "Errors" entry on my screenshot - it has a value of 0 next to it - so there are NO errors in the conversion I did.
Is there any difference (visually) between the TTF I used and the OT on your end? Can you try to substitute the version of the font installed on your machine with the TTF version from the archive you provided and see if it also fixes the conversion for you?

Kind regards,
Stefan

[DIV]

Hi, Stefan.

OK, if you think it is likely that the problem is associated with only the OTF format of the font, then I can try to check as a workaround whether the TTF format works for me.
I'll let you know what I find out.
However — regardless of what I find out — for the purposes of checking that your Editor application is functioning correctly, I still think it would be advisable for you to also check what happens at your end when the OTF font files are used. Given that we still don't know for sure precisely what is causing the problem, it could possibly affect other font families too. And be a concern for more users.

On the other hand, logically it's also worth checking version 1.002 of the font, in the OTF format, which is apparently the latest version, in case the mysterious problem is resolved.
However, my impression of the [url=https://github.com/mozilla/zilla-slab/tree/master/sources]Zilla Slab files on GitHub[/url] is that nothing substantial has changed; just some typographic errors in a build file ("build.sh") were amended. Maybe I'm overlooking something, but that's all I noticed. So I wouldn't be too optimistic.
UPDATE 1: OK, I now see a [url=https://github.com/mozilla/zilla-slab/releases/tag/v1.002]brief description[/url] of what's changed in the ZIP download: "V1.002: Fix Name table and Highlight font".
UPDATE 2: And "ZillaSlab-RegularItalic.otf" has been renamed to "ZillaSlab-Italic.otf" (likewise for *.TTF).

Sorry for not checking within the ZIP file before uploading it, as I have already acknowledged. I looked at what I had unzipped back in 2019, and presumed that the ZIP contents were identical. Personally I would always opt for the OTF files, because it's a newer format, with more features. But I have already apologised for the fact that I omitted to mention this in my original description.

I am still a little puzzled about the "reports" coming back from Editor.
In my post of Fri May 26, 2023 1:03 pm, there were 195 Errors and 195 Fixes.

Regarding your post of Sat May 27, 2023 12:18 am I wrote:

[...], although you apparently were able to successfully produce the PDF/A file, I notice that there were still a couple of 'errors' displayed. I would be interested to know if you can provide further information about the meaning of the message "Font [...] was fixed: embed fontfile (nnn):". What was wrong, what was fixed, and what do the numbers mean?

Perhaps I wasn't sufficiently careful in my expression, as looking again I see that Editor gave you a report of 0 Errors and 196 Fixes.
So although officially there were no "Errors" reported, surely there must have been something wrong for 196 "Fixes" to have been required. (And if there anything was indeed wrong, why wasn't it officially reported as an "Error"?)

—DIV

P.S. Where can I find more information about your add-in for Word? I recall previously there was only a "lite" printer driver that we could freely download and use (PDF-XChange Lite pdfSaver???).

[Willy Van Nuffel]

INFO:

MS-Office Toolbar Add-in - incl. Add-in for Word - is Part of the PDF-XChange Standard Printer:
https://www.tracker-software.com/produc ... 9/features

PDF-XChange Printer Lite Free:
https://www.tracker-software.com/produc ... hange-lite

[Tracker Supp-Stefan]

Hello Willy Van Nuffel, DIV,

I have not had the chance to test with the OTF version of the font - will try to do it in the next few days if things calm down enough to be able to spare the time!

There are "Fixes" - as the initial file while a perfectly fine PDF document is not conforming to the stricter PDF/A-x.x specification chosen - so these fixes are making it compliant. As you can see - the majority of those are adding the font information as it has to be embedded in the document so that the file is compliant.

"Warnings" and "Errors" will be populated if there is anything that would fall in that category. Usually if there are Errors you will not be able to save the file as PDF/A-

Kind regards,
Stefan

[DIV]

MS-Office Toolbar Add-in - incl. Add-in for Word - is Part of the PDF-XChange Standard Printer:
https://www.tracker-software.com/produc ... 9/features

Thanks, Willy.
If it's an important feature, perhaps Tracker should consider adding it to their product comparison chart.
—DIV

[DIV]

Is there any difference (visually) between the TTF I used and the OT on your end?

I've been trying to figure out how I can compare the appearances of the font family in the two formats. Obviously the OTF and TTF variants are going to look similar, unless something has become horribly corrupted. But to find subtle differences may need either side-by-side comparison or overlay comparison. And when I install a new variant or version, I cannot keep the old one — unless, AFAIK, I can embed it into a PDF file (which, of course, in this case I cannot!). Or unless I go in and manually change the name within the files, which I am not keen to do.

Anyway, I eventually realised that it might be feasible to take screenshots. Please see below.

• "TrueType Outlines" means it is the TTF variant.
• "PostScript Outlines" means it is the OTF variant (with [url=https://en.wikipedia.org/wiki/OpenType#Description]CFF[/url]-based contours).

Two variants from version 1.001.
The two formats appear to be pretty similar in version 1.001, but

• line spacing may be slightly different, and
• (at small sizes) the OTF variant looks heavier — at least on screen.

Two variants from version 1.002.
The two formats likewise appear to be pretty similar in version 1.002, but

• line spacing may be slightly different,
• (at small sizes) the OTF variant looks heavier — at least on screen, and
• the kerning may be slightly different ("N" & "O" and "6" & "7" appear further apart for the TTF variant).

Given the apparent kerning difference between TTF and OTF only arises in version 1.002, there is hence also an apparent difference in kerning between version 1.001 and version 1.002. Specifically the "N" & "O" and "6" & "7" appear further apart in the TTF variant in version 1.002 (all other three screenshots appear to have identical kerning).

—DIV

P.S. Differences in appearance, especially for small sizes, might be due to differences in [url=https://en.wikipedia.org/wiki/Font_hinting]hinting[/url], rather than the actual glyph contours.

[Willy Van Nuffel]

If it's an important feature, perhaps Tracker should consider adding it to their product comparison chart.

Maybe a little bit lost in that large number of features, but it is already there.

Kind regards.
>

[Tracker Supp-Stefan]

Hello Willy Van Nuffel, DIV,

Yes - the text hinting at the smaller font sizes is most likely the 'villain' that causes the differences - and each application will have it's own rendering engine (us included) that will handle that hinting and the overall letter appearance in it's own way.

So if the larger sizes look identical for you - I propose that you do install the TTF version of the font and see if you can then convert your files to PDF/A on your machine as I expect you would be able to!

Kind regards,
Stefan