Created attachment 7952 [details] Bug692378.PDF This file, while somewhat broken, has text in the wrong position. With 'HEAD' one of the first examples seen with -dPDFSTEP is the steps after 5725: BT step # 5725 ? /F2 7 Tf step # 5726 ? %Resolving: [134 0] %Resolving: [2 0] 1 0 0 1 34.8 0.0 Tm step # 5727 ? () Tj step # 5728 ? -100 Tz step # 5729 ? 3 Tr step # 5730 ? (1) Tj step # 5731 ? 0 Tr step # 5732 ? 100 Tz step # 5733 ? (1) Tj step # 5734 ? ET step # 5735 ? It is possible that the "-100 Tz" is confusing Ghostscript (this is the first instance of the negative Tz value and the combination of "3 Tr" and "0 Tr" in the -dPDFDEBUG output. All other occurrences of this type of text painting seem misplaced. Not sure why someone wants to overprint "invisible" text with normal text, all with the same font. Go figure. The customer sees this with 8.71, but it is still present in 9.04 and HEAD as of today.
When running the file GS issues a number of warnings, including one about 'Font Widths array is smaller than character range' I wonder if some of the widths are being treated as 0 because of this. This really is a terrible file, I notice the PDF Producer is too ashamed to admit who they are.... In addition objects 143 to 149 are missing from the file,
Created attachment 7953 [details] Much simplified PDF file which still exhibits the problem This is a much reduced file which still exhibits the problem
Created attachment 7954 [details] Much simplified PDF file which appears OK This is the same file with : () Tj -100 Tz 3 Tr (14) Tj and 100 Tz removed. This appears to be the same as Adobe Acrobat.
It appears to be the presence/absence of the '3 Tr' which is causing the problem, when this is not present the result is as per Acrobat, when it is present the result is incorrect. It seems likely that this is a PDF interpreter problem. FWIW I am currently working on text rendering modes with pdfwrite and I am seeing similar problems there with text rendering mode 3. Possibly there is a long standing error, but because rendering mode 3 does not make any marks, and it is unusual for marking text to rely on the current position being modified by non-marking text, we have never noticed.
The problem is caused by the handling Tr 3 in setshowstate in pdf_ops.ps. Testing a fix now.....
Fixed in commit: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=54ee17