Hello, I use gs 8.15 and cidfmap: /Ryumin-Light /HiraMinPro-W3 ; whch is a Hiragino Mincho OTF font distributed with Mac OS X Japanese version. It is OK to use the font in a horizontal direction with alphabet characters, but quite curious shifts are occured when I use the font in a vertical direction. All characters are shifted upper right a bit. Japanese characters' vertical baselines go through the center of them, but it seems that gs 8.15 assumes the baseline lies at the leftside of the characters. Gs 7.07 works fine as to the use of vertical Japanese characters.
Without a test file we cannot do much. We did fix some vertical writing problems between 8.15 and 8.50. I suggest upgrading to 8.51 and seeing if the problem goes away. I'm closing the bug as invalid, but feel free to reopen it if you reproduce it on 8.51 or if you can provide a test file.
Created attachment 1353 [details] ps and pdf files
I compiled gs-8.51 and found rightside shift problem was fixed, but upperside shift still occured. >if you reproduce it on 8.51 or if you can provide a test file. OK, I attached tar-archived files. vert.dvipdfmx.pdf: this is what I want to produce by ghostscript. vert.gs8.51.ps: this is a ps file produced by dvips. vert.gs8.51.pdf: this file is produced by gs-8.15 from the above ps file.
> I compiled gs-8.51 and found rightside shift problem was fixed, but upperside shift still occured. I am sorry. This is not true. When I saw the pdf in a Preview application of Mac OS X, it showed no right-shifted Kanji characters. But, Adobe Reader displays them right-shifted. Kanji characters are upperside shifted by both of Preview and Adobe Reader.
some screen capture for illustration would be nice - unless there is only *one* japanese font on Mac OS X japanese, it is entirely possible that Preview, ghostscript, adobe reader all have different font substitution policies for pdf files without an embedded font, and there is also a 4th font involved (the one from which the kernings was used etc for generating the dvi files).
Applications' font substitution policies would differ each other, but this problem also occurs for embedded Kanji font as an attachement file I posted.
Dear Inoue-san, sorry for long silence since your bug report. This issue includes 2 regressions since 2003. One was caused by SVN changset revision 4058 (2003-Jul-10), another was caused by SVN changeset revision 5429 (2004-Oct-20). I attached PDFs generated by SVN revision 4057, 4058, 5428 and 5429. # please check by Acrobat Reader, because some 3rd party PDF renderers # like xpdf may have different bug for vertical text. Both changesets were by Igor Melichev. The requirement of these changesets are not clear for me (in fact, according to SVN comments on http://cvs.ghostscript.com/cgi-bin/viewcvs.cgi/ghostscript/trunk/gs/src/zfcid1.c?rev=8128&view=log both changesets are described as if they were introduced to fix the vertical text bug). Yet I don't know whether they should be just removed or reworked. Igor, what the mechanism of bug you found and how did you "fix" them by these changesets? BTW, the quickest workaround is downgrading ghostscript before summer of 2003.
I slipped to add Igor in Cc:.
Created attachment 3256 [details] PDF converted by SVN revision 4057
Created attachment 3257 [details] PDF converted by SVN revision 4058
Created attachment 3258 [details] PDF converted by SVN revision 5428
Created attachment 3259 [details] PDF converted by SVN revision 5429
Regarding to comment #7 : 1. Please account complete patch info from http://ghostscript.com/pipermail/gs-cvs/2003-July/003428.html http://ghostscript.com/pipermail/gs-cvs/2004-October/004934.html http://ghostscript.com/pipermail/gs-cvs/2004-October/004935.html One more patch may be related to it : http://ghostscript.com/pipermail/gs-cvs/2004-October/004937.html 2. Their log messages clearly explain the purpose of changes : bugs 689947, 687753. 3. I'm not sure what do you mean saying 'reworked'. Our need is to find out why the current code produces a wrong result, fix it, and ensure that the fix doesn't reopen other bugs. 4. Moving users back to 2003 isn't a right resolution. Removing an old patch is allowed only if the patch causes a significant regression, or when it is immediately repaced with a better patch.
>4. Moving users back to 2003 isn't a right resolution. >Removing an old patch is allowed only if the patch >causes a significant regression, or when it is immediately >repaced with a better patch. I think this issue is significant regression. Do you think this issue is so subtle that the users should keep the latest ghostscript with this bug? >3. I'm not sure what do you mean saying 'reworked'. Our >need is to find out why the current code produces a wrong >result, fix it, and ensure that the fix, doesn't reopen >other bugs. Although the changesets seem to be introduced to fix the bug 689947 & 687753, they opened this bug 688058 (and caused further regression on revision 5429) , so they should be removed according to your rule "ensure that the fix, doesn't reopen other bugs".
We need to isolate these problems in the current implementation.
Created attachment 3301 [details] patch to inhibit wrong metrics writing into PDF Fix: inhibit the embedding of synthesized metrics into PDF when the font is imported from external resource. DETAILS : Before SVN revision 4057, pdfwriter did not synthesize the metrics for each glyphs, and let PDF renderer to handle the metrics of the glyphs. By the changeset on SVN revision 4058 & 5429, the metrics are synthesized per glyph and explicitly embedded in PDF document. However, when the font is imported by ghostscript (e.g. input PostScript file has no embedded font, and output PDF is expected to include embedded font), the synthesized metrics is incorrect. It appears as a bug 688058. To restore the behaviour of ghostscript SVN revision 4057, the embedding of synthesized metrics into PDF should be inhibited, when the external font is imported by ghostscript. Current font object in C space is difficult to distinguish whether it comes from document itself (embedded font in PostScript/PDF document) or from external resource (filesystem which ghostscript font framework accesses). Additional boolean flag "is_font_on_fs" is introduced into gs_font_s structure. During the font object initialization, this flag is initialized as false by default. When ghostscript loads a font object from a file on file system, the loaded font object is marked as external by ".markfontonfs" operator, by setting the flag to true. The flag is also remarked as internal resource by ".markfontofffs" operator (which is not used in this patch, it is debug purpose). By restoring the behaviour of SVN revision 4057, bug #688058 is fixed. EXPECTED DIFFERENCES : None.
Created attachment 3302 [details] PDF converted by SVN revision 8200 + proposed patch PDF converted by ghostscript SVN revision 8200 + proposed patch, The glyph positioning is restored as it was by SVN revision 4057.
Regarding the patch 3302 : 1. The old flag is_resource does same job as the new one. Therefore the new one and the new PS operators are not necessary. 2. The ptach hides the wrong behavior rather than fixing it. If we write correct widths arrays, the document would view corrctly. So the problem is a wrong computation of widths arrays. It has to be fixed. 3. If one just pre-concatenates the document with same font file (as an emulation of its embedding) and runs the concatenation as a single job, how does the patch 3302 helps for proper glyph positions ? The patch must not be committed due to all above.
Created attachment 3318 [details] patch to inhibit wrong metrics writing into PDF, revision 2 I slipped to note this patch is not terminal fix, it is just temporal fix to coexist with the changeset revision 4058 and 5429 causing this bug. >1. The old flag is_resource does same job as the new one. > Therefore the new one and the new PS operators are not necessary. OK, I revised the patch to use existing flag is_resource. It seems that the flag is not carried when the resource is mapped (e.g. /HeiseiMin-W5 is used to replace /Ryumin-Light), I fixed to copy the flag from original to mapped one, by additional PS operator .isregisteredfont. Is there any reason to discontinue the is_resource flag to mapped resource? >2. The ptach hides the wrong behavior rather than fixing it. If we write >correct widths arrays, the document would view corrctly. So the problem is a >wrong computation of widths arrays. It has to be fixed. I agree, it will be long work. >3. If one just pre-concatenates the document with same font file >(as an emulation of its embedding) and runs the concatenation >as a single job, how does the patch 3302 helps for proper glyph positions ? Of course, this patch doesn't help such PS files. For further improvement, it's needed to investigate more exact condition which embedding of synthesized metrics is required. External font file may be no more than "sufficient" condition. "nessesarry-and-sufficient" condition should be checked.
I think we have not enough reasons to commit the partial fix patch 3318. Please continue working on the unfixed case 3. Please note that according to the PDF specification a viewer may substitute the embedded font with its own fotn of better rendering quality. In this case width arrays specify the character spacing neccesary for the document to display correctly, so we cannot omit them. A remark to patch 3318 : the new PS operator .isregisteredfont is not necessary because the font data structure passes the necessary information to the device.
Changing assignment due to no progress.
This bug is delayed since it depends on 689893.
The comments 16-20 are not useful because they change the behavior of PDF writer only. However the glyph shift is visible when rendering the PS file, so the primary goal must be patching the PS interpreter it its part related to fonts.
The glyph shift doesn't appear if substitute a CIDFontType 1. So the problem is specific for True Type.
Created attachment 4267 [details] patch.txt Patch to HEAD for the original bug. It passed the local testinmg, but its commitment is being postponed until the gs/src reorganization. We observe more 2 problems with the patched code with the test case. Will open separate bugs for them.
Problems mentioned in Comment #25 are moved to Bug 690006 and Bug 690007. Rather comments 16-20 of this bug suggest a fix for Bug 690007, they don't look correct.
Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2008-August/008552.html