I have continued debugging the problem. It appears it is really linked to loading the LCL1Medium type1 font which is embedded into the file (it is object 32 in the file I transformed with qpdf).
The analysis of the font starts correctly (parsing header %!PS-AdobeFont-1.0: LCL1Medium, ignoring a few parameters like /Notice, /FullName, /FamilyName, ... extracting /FontName, recognizing /Encoding 256 array , ignoring a suite of PostScript commands anf recognizing a series of dup commands like dup 32 /space put, dup 33 /exclam put ... The problem occurs just after the current dict is closed by the currentdict end instruction. The next instruction is currentfile eexec which is followed by a large binary blob, which itself is followed by 8 lines composed of 64 characters '0' and an end of line marker (\r), followed by a cleartomark line. The binary blob is parsed as if it were composed of ASCII lines, and of course most of the lines exceed the 255 characters length. In fact, as soon as the PostScript instruction eexec is encountered on currentfile (i.e. when currentfile eexec is detected on a line), the parser should not look for end of lines directly anymore, but look if the following blob is an encrypted binary. In this case, it should probably decrypt it. The encryption/decryption is described in the Adobe Type 1 Font format book, at chapter 7 (I have found this book online using a simple web search). So as a summary, the problem in the file I provided is due to a font loading which parses encrypted characters as if they were not encrypted, which then confuses the line breaks algorithm. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
