Created attachment 124671 [details] PDF to show the problem pdftops (no options required) generates bad postscript for the attached PDF. I tested pdftops 0.45.0 and some older versions and even xpdf 3.03 pdftops, and they all generate ps that gets /rangecheck in --xyshow-- xpdf 3.02pl2 pdftops is ok, but it uses TJm instead of Tj and messes up fonts with vertical positioning. gs pdf2ps generates a valid ps. Considering that the pdf is viewable by several applications and that gs pdf2ps and old xpdf pdftops can both produce a valid ps, I think that the problem is in poppler pdftops rather than in the pdf. I thought that xyshow could get a rangecheck only if the number of xy pairs was shorter than the string, but adding an extra 0 0 to the array of xy pairs did not help. The font is defined as /F7_0 /GBJUMM+PalatinoLinotype-Bold 0 pdfMakeFont16
pdftops -level3 works, so this might be related to https://bugs.freedesktop.org/show_bug.cgi?id=63963 pdffonts shows name type encoding emb sub uni object ID ------------------------------------ ----------------- ---------------- --- --- --- --------- GBJUMM+PalatinoLinotype-Bold CID TrueType Identity-H yes yes yes 7 0 TKVUMM+PalatinoLinotype-Roman CID TrueType Identity-H yes yes yes 11 0 XQTSQE+PalatinoLinotype-Italic TrueType WinAnsi yes yes yes 9 0 NWTKGY+PalatinoLinotype-Roman TrueType WinAnsi yes yes yes 10 0 ASHKGY+PalatinoLinotype-Bold TrueType WinAnsi yes yes yes 12 0 GOHPMM+ArialMT TrueType WinAnsi yes yes yes 13 0
When converted with pdftops / poppler 0.63, the file can be viewed with ghostscript without any issues. Can you check if the issue persists for you?
I think that this was fixed with https://bugs.freedesktop.org/show_bug.cgi?id=63963 by commit 2cf901c817fc99e1fa57745c11aa79cdfb4e8c99 in Poppler 0.50 of Dec 2016. When that bug was closed, probably this bug should also have been closed.
Ok going to close, William please reopen if you can reproduce again :)
The file works for me now, and I checked my notes, and this file along with some other files are in the section where I worked on the patch that I submitted in https://bugs.freedesktop.org/show_bug.cgi?id=63963 I don't remember exactly what happened, but I think that this file generated the spaces around the bullets by using a 0 size character high up in the font and showing it in a way that the show command added the space. Since the glyph was empty, something didn't include it when building the font, and the generated postscript got a range error trying to access it. In my patch at https://bugs.freedesktop.org/page.cgi?id=splinter.html&bug=63963&attachment=128294 the sequence below in PSOutputDev.cc is what stops the range check while preserving the spacing. For the glyph used for spacing, code > maxGlyph (which is no loss because the glyph is empty and 0 size) but dx > 0 and needs to be counted. William 5179 } else if (maxGlyph > 0 && code > maxGlyph) { 5180 // Ignore this code. 5181 // Using it will exceed the number of glyphs in the font and generate 5182 // /rangecheck in --xyshow-- 5183 if (nChars > 0) { 5184 dxdy[2 * (nChars-1) ] += dx; 5185 dxdy[2 * (nChars-1) + 1 ] += dy; 5186 }
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.