Bug 688058

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