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

22 May 2019 By Dietrich von Seggern

Support PDF 2.0 Prepress

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 ;-)

Smiling Smiley

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):

Missing emotions

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.

Investigating emji

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.

Bad emotions

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).

Applause

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

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:
https://www.agilestreams.io/en/opentype-svg-pdf-first-solutions/
Another nice article comes from Stephan Jaeggi:
//pdf-aktuell.ch/pa/language/en/warning-about-opentype-svg-fonts-in-adobe-indesign-cc2019/

Back to overview
 

Subscribe to our newsletter for access to regular updates

No strings attached. Unsubscribe anytime. For further details, review our Privacy Policy.