Created attachment 78523 [details] test.pdf - original pdf file Hi team, This sample PDF file, when converted to PS level2 by pdftops 0.22.3, cannot be processed by a printer or by GhostScript interpreter because it chokes on embedded fonts and quits with rangecheck error in xyshow function. The offending part of PS code is this: /F9_0 13.3333 Tf (\012\355) [13.3333 0] Tj Nice folks at GhostScript explained to me that after defining the type42 font /DejaVuSans_00, the ps code then does this: 16 dict begin /FontName /DejaVuSans def /FontType 0 def /FontMatrix [1 0 0 1 0 0] def /FMapType 2 def /Encoding [ 0 ] def /FDepVector [ /DejaVuSans_00 findfont ] def FontName currentdict end definefont pop As you can see, the font has a single dependent font, and it has map type 2. Map type 2 means the () string passed to show has a font number and a character number. So the string (\012\355) means sub-font 10 character 247, hence the rangecheck error. In the PDF, all of the falls to F0 (Arial) are of the form: /F0 13.3333 Tf 1 0 0 -1 10 18 Tm <0035> Tj but the calls to F1 (DejaVu Sans) look like: /F1 13.3333 Tf 1 0 0 -1 139 18 Tm <0AED> Tj So pdftops is copying the <0AED> literally to (\012\355), but not embedding enough subfonts. The other fonts coincidentally all use glyphs in <0000>--<00FF> and miss the bug. I'm attaching both PDF and PS files for your consideration.
Created attachment 78524 [details] test-ps - result of pdftops level2 conversion
Comment on attachment 78523 [details] test.pdf - original pdf file mistakenly attached as plain text, removing.
Created attachment 78525 [details] test.pdf - original pdf file
I provided that diagnosis which Alexei quoted, but I’ve not had any time to work through the src to figure out why it fails as it does. pdfinfo says the font is not subset, but having extracted it I see that it sort-of is. The contents of the unused glyf routines have been elided, but only their contents. The entries themselves remain. ttx shows me that the 0x0AEDth glyph is uni200B (ZERO WIDTH SPACE). Odd glyph to emit into a pdf, but pdftops should get it right anyway. Using -level3 pdftops emits a CID font into the ps, which works properly. I used git master to replicate the bug; it is not limited to 0.22.3.
James do you think you will ahve time to look at what we do wrong or should someone else try to?
I’ll at least look at the call graph. The »if (font->isCIDFont())« block of PSOutputDev::drawString() is involved. Maybe the if (uMap) block? I need to recompile w/o optimization to know more, but there must be a disconnect between the subsetting code and the codeToGID() function.
I had a similar problem in https://bugs.freedesktop.org/show_bug.cgi?id=96644 , and I am close to a patch to fix it. I think that FoFiTrueType.cc should remember how many glyphs it writes. When PSOutputDev builds the resources, it can build a hash with the font name and the number of glyphs. Then when PSOutputDev drawString builds the output string, if it can find the number of glyphs in the hash and if a code exceeds the last valid glyph, it can increment the last pair of values in the dxdy array by dx and dy but otherwise ignore the code. The problem is that in PS Level 1 or 2, FoFiTrueType makes a composite font, but some fonts have a lot of empty positions, so it writes only to the last used glyph. For example, a font in test.pdf has nGlyphs 1674 but maxUsedGlyph 88. Writing all of the empty glyphs in FoFiTrueType would fix the problem, but the resulting ps file would be much larger. Then when the ps uses code 2797 (hex AED), it considers 0xA as the index of the composite font, and there will be enough fonts in the FDepVector. I suppose that unused glyphs have a 0 size and leave no marks, so the alternative is to remember that the font has only 88 glyphs (actually FoFiTrueType rounds it up to 255) and then ignoring the attempt to show code 2797 (except for adding in the dx dy). It looks like these codes are used for alignment. Maybe some applications have poor subsetting logic that doesn't compact empty glyphs. The PDF in my bug report was made by 'Adobe InDesign CC 2015 (Windows)'. William
Created attachment 124925 [details] [review] patch to fix the problem This patch should fix the problem without affecting the generated postscript for other files.
Created attachment 124926 [details] [review] patch to fix the problem
Created attachment 124927 [details] [review] patch to fix the problem
Created attachment 126196 [details] [review] patch to fix the problem This fixes a problem where the previous patch could fail on fonts where font->getName() returned NULL.
Created attachment 126197 [details] [review] patch to fix the problem Add checks that font->getName() is not NULL.
I don't like how you use GfxFont and FoFiTrueType as vessels for that maxValidGlyph, isn't that you can transport somehow else? For example in FoFiTrueType::convertToType it could be an "output parameter"?
I pulled the current poppler git source, and when I build it unpatched and run pdftops on the test pdf for this bug, I get a lot of errors like the one below. Syntax Error (927): Arg #0 to 'Tj' operator is wrong type (hexstring) I suspect that is related to the recent patches by Jakub. Is anyone looking into that?
Created attachment 128294 [details] [review] Revised patch that does not store maxValidGlyph in GfxFont or FoFiTrueType I made a new version of the patch that passes maxValidGlyph as a parameter to FoFiTrueType::convertToType0() instead of storing it in GfxFont and FoFiTrueType. This simplifies the patch but might be more expensive in PDFs with a lot of short strings because PSOutputDev::drawString() has to look up the value in a hash instead of caching it in GfxFont. This patch is based on poppler-0.49.0 because the current git source does not build a working pdftops.
I have a patch for the "Arg #0 to 'Tj' operator is wrong type (hexstring)" error at https://bugs.freedesktop.org/show_bug.cgi?id=98921
Pushed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.