Summary: | Text positioning wrong | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Ray Johnston <ray.johnston> |
Component: | Font API | Assignee: | Chris Liddell (chrisl) <chris.liddell> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | CC: | ken.sharp |
Priority: | P1 | ||
Version: | master | ||
Hardware: | All | ||
OS: | All | ||
Customer: | 532 | Word Size: | --- |
Attachments: |
Much simplified PDF file which still exhibits the problem
Much simplified PDF file which appears OK |
Description
Ray Johnston
2011-09-30 01:44:44 UTC
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 |