End of life for Type 1 fonts in authoring applications

Blog notdef Image

Some time ago Adobe announced that it "will disable support for authoring with Type 1 fonts by January 2023". What does that mean from a prepress and PDF point of view? First of all, we should look back to see how Type 1 font came into the world and how they fit into today's font formats. They were introduced together with PostScript in the stone age of open digital prepress production back in 1984. PostScript and Type 1 fonts were an essential part of what was at that time called "Desktop Publishing" (DTP). The success of PostScript in enabling DTP made it necessary for operating systems to integrate font management. Microsoft and Apple had to decide whether they wanted to use (and license) Type 1 technology, but decided to go their own ways introducing TrueType, a completely different font format. These two formats, Type 1 and TrueType are still the only really different formats, all newer font formats are variants from either one of them or hybrid, which means from both.

Type 1 fonts have lots of limitations (which is understandable given their age), which have been resolved in newer variants, namely in OpenType. OpenType was developed by Adobe and Microsoft, it is a hybrid format that can internally use Type 1 or TrueType like structures. So, from a technical point of view we can already say that Type 1 fonts are a relict and there is some reason to not using them anymore.

The other thing that we should understand is what Type 1 fonts are in PDF - which is easy: They are part of it. The PDF specification describes how text in a PDF file has to be specified to reference fonts or more specifically glyphs (characters) in fonts. The glyph lookup is one of the most complex parts of the PDF specification and had to be defined separately for all supported font formats. Supported font formats in PDF are essentially Type 1 and TrueType (with variants). The title image for this blog shows what might happen if glyph lookup fails: The fallback character ".notdef" is displayed.

You do from a PDF specification point of view not necessarily have to, but will in prepress context almost always embed the font file into the PDF, to avoid issues with missing or incompatible variants of fonts. The embedded font file is usually not completely embedded by the PDF producer, so that it only contains what is necessary in the context of a PDF file. That can also apply to the glyphs so that only those glyphs are embedded, that are actually used in the PDF (subsetting). However, in essence their internal font structure is still the same after embedding, i.e. they still are Type 1 or TrueType (or a flavor thereof).

The above is important in this context to understand, that there is no way to not support Type 1 fonts when processing a PDF file. That means that every application that claims to support PDF has to be able to deal with Type 1 fonts when used in a PDF file (embedded or not). Every authoring application including the ones from Adobe that allows for placing PDF files, has to support Type 1 fonts embedded into a PDF and every output (RIP) that can output PDF files will support them as well.

callas as a vendor for automated PDF technology understands that reliability is essential for automation. That means in the context of text that we need to prepare our technology for every possible (valid or invalid) use of fonts in PDF files. I can confirm that we often wished that PDF would have reduced the various possibilities and fallbacks in glyph lookup to one way only or at least to only a few. PDF went the other way and made it as easy as possible for PDF creators to use whatever glyph lookup algorithms they are using in their applications also when using them in PDF. That is one of the reasons why today there is almost no application that can't save a PDF file, but it is also the reason that glyph lookup in PDF is a very complex thing and once in a while creates problems. Such problems occcur when a PDF processor is not prepared for a certain (valid or invalid) way the glyph lookup is intended to take place by the creator. In other words: Limiting the number of supported font formats does not seem to be a completely bad idea.

But anyway, we all know that Type 1 fonts are still around here and there, sometimes e.g. for company fonts that had been designed long time ago.

So, what can be done to be prepared for January 2023?

First you may want to find out whether you have any files that are actually using Type 1 fonts:
When it comes to Creative Suite you would have seen a warning for quite some time now when opening such a file. You could as well use the Preflight tool that is built into InDesign and search for Type 1 fonts.
You may also use a PDF Preflight tool and analyze PDF files - it is hopefully clear by now that the PDF file itself will NOT create any issues in 2023 or thereafter. Only if you would have to create a new (modified) variant of it with a new version of your Creative Suite application you will have a problem with Type 1 fonts. There is one important issue with this approach though: Even if you are using an OpenType font the PDF creating application may decide to embed it as Type 1 font so that you would see it falsely flagged.
Ofcourse both tests, the one with the original file format or the one with the PDF file, could be done interactively or automated if you have proper tools.

If you now know you are using Type 1 fonts you could license a more recent variant or - if that is covered by the license that you already have - convert the Type 1 font to TrueType or OpenType which is also possible.

Back to overview

Subscribe to our blog newsletter for access to regular updates

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