Patch for longstanding pdftex font subsetting bug
The enclosed patch fixes a longstanding bug in font subsetting for pdflatex that has existed since 1.20a-rc1 (March 2004). This bug has been causing problems for Mac users for some time because OS X does not like the subtly invalid fonts that pdflatex can output (but it may have affected others as well). The technical details and patch are below... The issue relates to CharString encryption for Type 1 fonts. In particular, the lenIV parameter of a font controls how much (encrypted) padding to put in front of the (encrypted) data. The default is four, so four bytes of encrypted padding are produced. In one part of the pdftex font-subsetting code (the part that writes out empty subroutines that have been dropped in the process of subsetting), pdftex incorrectly treats a padding of zero as meaning that it should abandon charstring encryption altogether. Not so. (FWIW, by undocumented convention, a padding of -1 does, in fact, mean no encryption.) By not encrypting data that is supposed to be encrypted, the subroutine ends up containing operator 0x1b, the hhcurveto operator, rather than 0x0b, return. This is an error in two ways, first, subroutines should return, and, second, the hhcurveto operator expects some arguments. Note that the subroutines that are affected by this bug are exactly those that are *never called*, so we might expect the bug to be harmless. It would appear, however, that Apple's font technology does process these "uncalled" subroutines and does not react well to their invalid content. Thus, to have been affected by this bug, you need to a) Use a font where lenIV = 0, and b) Use a Mac (or anything else that needs uncalled subroutines to nevertheless be valid), which explains why so many people have said, "I see no problem; it works for me" in response to the anguished cries of Mac users with PDFTeX-generated documents everywhere. FWIW, the buggy code was checked into the repository for version 1.20a- rc1. Prior to that point, this aspect of font subsetting worked correctly. The patch is, thankfully, trivial, changing (t1_lenIV > 0) to (t1_lenIV >= 0). Fonts known to be affected by this bug include cm-super, sanskrit, and fonts processed with cfftot1 (i.e., OpenType fonts used with LaTeX), as well as many Adobe Type 1 fonts. To assist Mac users, I have put a precompiled version of pdftex-1.40.9 on my website at http://www.cs.hmc.edu/~oneill/dist/pdftex-1.40.9-patched.zip If you have enjoyed this patch, share it with your friends. I'm told it goes well with a glass of fine Merlot. Melissa. P.S. Sadly, I don't know if this is the *only* bug in fonts and subsetting that causes fonts to be subtly invalid, but it is at least *a* bug that's been squished. Enc.
2009/3/21, Melissa O'Neill
The enclosed patch fixes a longstanding bug in font subsetting for pdflatex that has existed since 1.20a-rc1 (March 2004). This bug has been causing problems for Mac users for some time because OS X does not like the subtly invalid fonts that pdflatex can output (but it may have affected others as well).
Thanks for finding the bug and fixing it; it had (of course) been incorporated into LuaTeX, where I adopted your patch. Best Martin
participants (2)
-
Martin Schröder
-
Melissa O'Neill