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. Apple Preview or callas pdfToolbox 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 in general we take both spots 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).
Our 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.
- We already have a dedicated Check that allows for finding these issues. You can download it from here. Our suggestion to everybody in charge of prepress workflows is to double check their procersses with an example PDF (here is a rendition of this article that you could use: callas Blog "I love SVG fonts".pdf).
- We implemented a Fixup (actually we extended an existing one), that merges the text into the other page content. This is described in our user manual here:
One of the sources was btw our French integrator AgileStreams who also wrote a nice article about the topic that also includes some pdfToolbox Profiles:
Another nice article comes from Stephan Jaeggi: