Adobe has announced that they’ll disable support for authoring with Type 1 fonts by January 2023 (see more here), which has triggered quite a lot of public discussion, especially when this is happening in parallel with their changes to licensing of Pantone spot colour databases.
But it made me go and check what the requirements are for a conforming PDF processor with respect to Type 1 fonts.
Those who know me will perhaps find it slightly surprising that I didn’t know the answer off the top of my head, given that I’m the UK principal expert to the ISO committee that maintains PDF, co-chair of the PDF Association's PDF Technical Working Group etc etc.
That’s partly because the requirements of PDF conformance for a processor, defined as “any software, hardware or any other active agent that writes, reads, updates or otherwise processes a PDF file” has evolved over time. It’s also partly because some of those requirements are deliberately nuanced, so I had to go back and confirm what I thought was the case
Those nuances are the result of many long debates, which boil down to an acknowledgement that the ISO PDF committee just cannot identify all possible uses of PDF for which a sensible business case can be built. We have often come back to the example of a tool with the sole purpose of reading a PDF file and returning the number of pages it contains. That’s pretty extreme, but it’s not that far away from a common component that’s used relatively early in the workflow within a digital front end (DFE) for a digital press: something that reads the number of pages and the size of each, because the rest of the processing within that DFE depends on knowing that information.
It did not seem appropriate to label such a tool as non-conforming just because, for example, it doesn’t understand ICC profiles or ... to come back to the subject here, Type 1 fonts.
As the 2020 edition of the ISO PDF 2.0 standard1 says:
"Each PDF processor chooses which subsets of PDF functionality to support. For each subset that the processor chooses to support, the processor shall comply with the applicable provisions in this [standard]."
To put that another way: if your tool is going to do something with information from a PDF file then it must do it correctly.
So that page count reader is conforming if it reads the PDF trailer, Catalog and Pages objects correctly.
And I can confirm that any tool that reads PDF files and does anything with fonts in them does need to continue to support Type 1 fonts in order to conform to the PDF standard. If somebody were to bring out a PDF viewer or RIP, or something else that should be dealing with fonts in a PDF file, and if that product doesn't do something sensible with Type 1 fonts2 then it would not be a conforming PDF processor.
That doesn’t extend to PDF creation tools of course; they are free to use whichever font types they want to, as long as the files that they create conform to the PDF standard. This contrast is typical of the difference between creation and consumption tools for many formats: the creator can be very selective about which bits of the standard it chooses to implement, while a consumer must usually implement all variants of all relevant aspects of the standard.
1 – I chose this latest published version of the standard, not because it’s the most widely used (it’s not) but because it has the clearest statements on this and many other issues.
2 - note the carefully chosen weasel words! It doesn't need to use the Type 1 font to display the text; it's free to do anything that reproduces the intended appearance sufficiently closely to meet the quality requirements of its intended user base. That might mean building an emulation font, substituting with a similar font, etc.
