Today, we propose you to come back on last week Tech Monday on OpenType SVG fonts and PDF.
We pursued our tests, including QuarkXpress, and we had the opportunity to present our work as part of the Ghent Workgroup meetings. We will summarize here our new findings as well as the results brought by the experts of the Ghent Workgroup of which we are part.
QuarkXPress 2018 is doing pretty well (but no more live text)
After testing the Adobe CC 2019 Suite, we pursued our tests by evaluating QuarkXPress 2018, which, by the way, was the first professional page editing application to support SVG OpenType fonts. You can also check out this video of Matthias Günther, Head of Desktop Publishing at Quark.
Quark makes a lot of communication about these new fonts, but what about using these fonts within QuarkXPress 2018 and converting files using them to PDF?
Well, both the export in PDF/X-1a and in PDF/X-4 work perfectly, the PDF files generated in these formats being compliant to the standards.
In fact, QuarkXPress does not convert the OpenType SVG font to Type 3 (as the Adobe CC attempts to do – except for PDF/X-1a), but extracts the contents of each glyph to make it a vector object in the PDF file. So there is no more living text, but the objects contained in the glyphs are now page contents.
For the PDF/X-4, either these objects are converted to CMYK or kept in RGB (depending on the settings of the export profile). For RGB objects, they are ICC-tagged (in this case the Quark Generic RGB profile), which is perfectly compliant to the PDF/X-4:2010 standard.
For PDF/X-1a, each block of text is converted to a high-resolution image in CMYK.
So, of course, the PDF file is managed correctly, but the fact that the PDF no longer contains live text remains annoying. Probably acceptable for an Emoji font, for a “readable” font, it would be necessary to be able to extract the text, even if only for accessibility.
Outcome of the discussions at the Ghent Workgroup
Following the discussions during the Process Control meeting, it appears that:
- OpenType SVG fonts are embedded in the PDF file as Type 3 (except the “space” glyphs, as Type 1)
- when converting to Type 3, Adobe applications have a bug, and Type 3 font resources are stored incorrectly in the PDF
- live text (Type 3) is in RGB, but is not ICC-tagged, which is not compliant to the PDF/X-4 standard
- for the two reasons above, the preflight in PDF/X-4 fails, with, among other things, the error “Missing XObjects” (because the resources are not stored in the right place)
Do we need a specific check for incorrect Type 3 fonts?
Because the preflight is currently failing, we have decided that there is no need for an additional check. This, especially as the correctly created Type 3 fonts are properly managed, and that excluding them could be problematic, considering that quite a number of companies have created a Type 3 font (e.g. for their logo).
Next versions of Adobe CC, Enfocus PitStop & callas pdfToolbox
Our work has shown that it is necessary to update the existing tools in order to solve the existing bugs on the one hand, but also to offer new functions to manage the problems encountered on the other hand.
Adobe has recognized a bug in writing fonts in Type 3 format in the PDF and is working to set it up in a future version of the Creative Cloud.
Callas will offer new functions to manage correct and incorrect Type 3 fonts (color conversion & extraction of glyph content – using a feature close to form fields flattening?).
Enfocus also works on improvements to PitStop.
Ghent Workgroup recommendation
With regard to the above-mentioned points, to date, the Ghent Workgroup recommends that you do not use OpenType SVG fonts for Print.
Additional Information
Thanks to Olaf Drümmer (Callas software) and Leonard Rosenthol (Adobe)!
Although the majority of the SVG OpenType fonts are RGB, this is not a mandatory requirement. In principle, an OpenType SVG font can be of any color (or color combination) – so it can perfectly be not colored. There are also fonts that use the colors around them (graphic state); As a result, it is quite conceivable to have an OpenType SVG font whose color space is CMYK, or even in spot(s) color(s)!
Note that Type 3 fonts (which actually contain PostScript code for drawing each glyph) are part of the PDF format (since version 1.0!!) and are supported by all PDF/X standards.
Conclusion
We have not finished talking about this topic, and we will come back regularly on the evolutions of this new typeface format.
Following our tests and the exchanges we had during our meetings at the Ghent Workgroup, it now appears that the most complicated part of the use of these fonts with PDF comes from their conversion from OpenType SVG to Type 3 (a conversion is necessary, as the OpenType SVG format is not part of the PDF specification). Although the Type 3 format is managed by the PDF specification, PDF Tools are still quite incomplete for managing these fonts, and we are waiting for new versions of these tools to see if they are bringing us the necessary functions.
For now, we can only advise you to stay away from the OpenType SVG for Print, but today’s truth may not be tomorrow’s!
2 Comments