Bug 687753 - Text not aligned when viewed with Acrobat Reader
Summary: Text not aligned when viewed with Acrobat Reader
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Writer (show other bugs)
Version: master
Hardware: All All
: P2 normal
Assignee: Igor Melichev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-12 12:19 UTC by Jack Moffitt
Modified: 2008-12-19 08:31 UTC (History)
0 users

See Also:
Customer: 310
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Moffitt 2004-10-12 12:19:59 UTC
The attached customer file distills without any warnings or errors with CVS
HEAD, and when viewed with CVS HEAD, looks fine.  But when viewed with Acrobat
Reader, the korean text is almost half a line higher than the latin text.
Comment 1 Jack Moffitt 2004-10-12 12:21:05 UTC
Created attachment 965 [details]
vertical.ps
Comment 2 Igor Melichev 2004-10-18 09:41:16 UTC
I've reproduced it.
Comment 3 Igor Melichev 2004-10-19 02:30:06 UTC
This problem is irrelevant to pdfwrite.
When rendering to display device with -r72, the text looks fine.
When rendering to display device with -r300, the text is biased.
In the latter case the caracter rasters can't fit into cache and render 
directly.
I guess that something is wrong with computing coordinates while a direct 
rendering. If I modify CDevProc with multiplying coordinates in twice, glyphs 
get right positions.
Comment 4 Igor Melichev 2004-10-19 02:33:37 UTC
Oops, the comment #3 is entirely wrong. Please ignore.
Comment 5 Igor Melichev 2004-10-19 03:29:56 UTC
With display device, the CDevProc adjustment applies by X, same as CPSI.
With pdfwrite device, the CDevProc adjustment applies by Y - incorrect.
Since FontMatrix of the descendent font is a 90 degrees rotation, likely 
pdfwrite applies it wrongly.
Comment 6 Igor Melichev 2004-10-19 04:02:43 UTC
Oops, the comment #5 is also entirely wrong. Please ignore.
Comment 7 Igor Melichev 2004-10-19 13:05:12 UTC
Well, here is bottom of the problem.
PDF spec says that the x component of v-vector is assumed equal to half glyph 
width. From some experimenting with AR5 we conclude that the width is taken 
from W of DW or the glyph itself. So if a font is used with both WMode 0 and 
WMode 1, v-vector for WMode 1 depends on what widths we write for WMode 0. So 
either always write zero widths, or compute WMode 0 width and write them even 
if WMode 0 isn't really used.