Bug 688485 - Arabic characters missing in PDF
Summary: Arabic characters missing in PDF
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter (show other bugs)
Version: master
Hardware: All All
: P2 normal
Assignee: Ray Johnston
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-10 13:30 UTC by Ray Johnston
Modified: 2008-12-19 08:31 UTC (History)
0 users

See Also:
Customer: 850
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ray Johnston 2006-01-10 13:30:49 UTC
with GS 8.53 the characters are missing wheras in Acrobat Professional 6.0 they
are shown.

Interestingly enough I saw no hints because of missing fonts and text
marked in Acrobat and pasted in notepad with an adequate font was shown as
all unknown characters. Single characters from the character table (windows
utility) however were shown correctly.
Possibly the characters are defined within the PDF and are mapped to
"wrong" positions.
Comment 1 Ray Johnston 2006-01-10 13:38:27 UTC
Created attachment 1915 [details]
10027.pdf

Problem file.
Comment 2 Ray Johnston 2006-01-10 14:08:18 UTC
I have determined that the characters _ARE_ being drawn into the
character cache, so it does not seem to be a character mapping
issue (those usually issue .notdef warnings).
Comment 3 Ray Johnston 2006-01-12 23:40:41 UTC
The characters are being rendered into the cache, but the text position is
incorrect when the cached char is to be 'blitted' onto the page so that the
entire character is outside the clip box in effect when the text is being
rendered. Soemthing is wrong w.r.t. the CTM and the Tm matrix resulting in
the characters all being put near the lower left of the page, but there is
a clipping box up where the characters are supposed to be.

I can probably find this fairly quickly now that I've learned this much.
Comment 4 Ray Johnston 2006-01-15 21:53:54 UTC
The Arabic characters are missing because they were not positioned correctly,
in fact, they were outside the clipping box that was in effect as the text
was painted.

The problem was that there was a 'cm' (concatmatrix) PDF operation inside
the BT/ET sections that painted the text. The correction involves updating
the TextSaveMatrix when the 'cm' was inside a BT/ET block (which is when
the TextSaveMatrix is 'known'.

The patch can be viewed at:

http://svn.ghostscript.com:8080/cgi-bin/viewcvs.cgi/ghostscript/trunk/gs/lib/pdf_draw.ps?rev=6458&r1=6446&r2=6458
Comment 5 Ray Johnston 2006-01-17 09:09:59 UTC
Incomplete patch -- works for -r72, but doesn't for other scale factors.
Test environment had other patches present which allowed this to work at
all resolutions, but they were not committed as part of this fix.

I will do so once those other patches are tested (parts of other fixes).
Comment 6 Ray Johnston 2006-01-19 23:50:19 UTC
concatmatrix operand order was inverted causing incorrect transformation
when resolution was not 72 dpi.

This is now fixed in pdf_draw.ps rev. 6475