SVG font issues in prepress production – and what that has to do with recent ISO meetings

Last week in Toronto, we discussed a dated revision for PDF 2.0 (dated revision means that it will not have a new version number) which has been a ‘work in progress’ since 2017 when PDF 2.0 first came out. We think it is in a really good shape resolving all issues that were reported since then (measured by the roughly 1000 pages not many, but still more than enough to do this update). We therefore decided to send it to, hopefully, a last (DIS) ballot which is always 5 months. That means that most likely the dated revision will become ISO 32000-2:2020.

One of the issues discussed there has to do with Emoji fonts – which reflect a recent change in our communication habits 😉

These fonts are usually using SVG code to specify colors, shapes, shades etc. SVG fonts, however, can’t be used in PDF files. But luckily there are fonts that can use any PDF content for their glyph descriptions and those can easily be created from SVG fonts. The SVG code can use additional resources such as images, transparency settings or even other fonts and so it is good that Type 3 fonts allow for such additional resources as well.

So far, so good – or not? We (callas) learned via support inquiries and from reselling partners and integrators that in many environments problems occurred with these PDF files. Unexpected output results were also reflected in PDF viewers, for instance Adobe Acrobat usually showed them as intended, but e.g. callas pdfToolbox or Apple Preview did not (in this order):

Investigation showed that in the PDFs having problems, these resources were not in the spot where they should be - as defined in the PDF Specification in the section describing Type 3 fonts. Our PDF analysis accordingly reported an error because of missing resources.

But then we received an inquiry from somebody complaining about these findings, pointing us to another section in the PDF specification where a different spot was defined for the resources. This section was related to resources in general – remember: the other one was specifically for Type 3 font resources.

The contradiction was actually sitting there for a very long time: I checked back until PDF 1.4 which came out in 2001. Most probably there just was not much use of these resources in Type 3 fonts, so that it never occurred as a contradiction. But what was actually nice (in this mess) was to find out that the problem was actually already detected and fixed – which brings us back to the dated revision. The first text (about resources in general) was adjusted already in the draft standard that was circulated in February this year, which gives me even more trust in this ISO work (appreciably managed by Peter Wyatt and Duff Johnson).

Now, how to deal with this problem in current PDF files? We at callas concluded:

• For analysis purposes and processing in general both spots should be taken into account: The – after the above clarifications – “right” one in the Type 3 font dictionary that contains substructures for all glyphs, as well as in the glyph substructures (“CharProcs”) themselves (the “wrong” one).
  Reason is that the reality has to be accepted which teaches us that these files are around and in many processes full PDF validation is just not what helps.
• Everybody in charge of PDF workflows should double check whether they can work with such PDF files. Here is an example PDF (a rendition of this article): callas "I love SVG fonts".pdf. In case of problems vendors should be contacted.
• In the meantime PDF file should be analyzed. This Check for callas‘ products or Adobe Acrobat Preflight that finds the issue: Type 3 font misses resources.kfp
• And this Correction fixed it (currently only in callas’ products) by merging all such fonts into regular page content: Convert colored Type 3 fonts to outlines.kfpx. Further backgrounds are explained in our online documentation:
  https://help.callassoftware.com/m/pdftoolbox/l/1083015-convert-type-3-fonts-to-outlines