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.
Created attachment 965 [details] vertical.ps
I've reproduced it.
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.
Oops, the comment #3 is entirely wrong. Please ignore.
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.
Oops, the comment #5 is also entirely wrong. Please ignore.
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.
Patches to HEAD : http://www.ghostscript.com/pipermail/gs-cvs/2004-October/004934.html http://www.ghostscript.com/pipermail/gs-cvs/2004-October/004935.html Note we reopened the bug 687603.
A cumulative patch to GS_8_1X for bug 687603 and bug 687753 : http://www.ghostscript.com/pipermail/gs-cvs/2004-October/004938.html http://www.ghostscript.com/pipermail/gs-cvs/2004-October/004939.html