Bug 690029

Went to check this issue with the latest version of GS, incorporating the FreeType font engine, as I believe it may improve matters. Unfortunately the original reporter did not attach the source files, and the URL now results in a 404 page not found error.

Closing as 'invalid', only because I have no test case. I'm willing to have this reopened if a test file is attached.

Created attachment 6262 [details]
http://www.belldandy.idv.hk/GS/source.pdf

I have saved the file on my hard disc. (personal interests - I can actually read the chinese in the bug title...).

Created attachment 6263 [details]
http://www.belldandy.idv.hk/GS/output_error.pdf

The other file.

Hmm, I see now that the source is a PDF file, I missed that originally, so its unlikely that FreeType will make any difference. Still, at least we have a copy of the file now, so we can at least work on it as time permits. Thanks Hin-Tak.

Created attachment 6264 [details]
PDF file created form the current HEAD revision of GS.

Aha! Actually it does make a difference. There are some glyphs which are not preserved as 'text' in the output PDF file, but instead are rendered to bitmaps. I'm not certain why, but Acrobat won't let me edit those glyphs in the original file either, complaining that the font is not available. (These glyphs display oddly in Acrobat as well, having jagged 'bitmap' edges)

In any event, the old result was *massively* over bold rendering, resulting in some glyphs turning into black rectangles.

The new FreeType code results in much more pleasing output, it is less bold than the Acrobat display of the original file, which may not be entirely desirable, but it does make the glyphs more legible. Hin-Tak, would you take a look at the attached PDF file please ?

There are two noticeable issues with the new result viewed with acroread 9 on linux : the glyph before ": 0808..." on the top right is rendered wrongly (just broken); and the two of the three big characters above it seems to have the stoke outlines shifted against the fills. 

The outline/fill shift is less noticesable with some of the other characters but still there (with the kaiu font, I think) elsewhere in the page.

(In reply to comment #6)
> There are two noticeable issues with the new result viewed with acroread 9 on
> linux : the glyph before ": 0808..." on the top right is rendered wrongly (just
> broken); 

That looks like it might be a TT hinting problem, I can check that.

> and the two of the three big characters above it seems to have the
> stoke outlines shifted against the fills. 

I'm not sure what you mean. This is the three big glyphs at the very top right ? 

The Acrobat document does show them (properties) as being stroked and filled, if we were only filling the glyphs when rendering that might explain the lack of boldness.

Could you post a marked-up screenshot of what you see ?

In the meantime I'll enable full bytecode hinting and see what happens with the broken glyph.

Created attachment 6265 [details]
Output with FreeType using the patented bytecode interpreter

The patented instruction bytecode interpreter seems to work correctly with the previously damaged glyph.

Created attachment 6266 [details]
screenshot of the unhinted pdf

screenshot, showing a slight shift between stroke and fill (there are small white gaps between).

Created attachment 6267 [details]
another screenshot

from the patentet hinted pdf. Notes the slight "ghost'ing" effect of the three glyphs on the top right. This seems to be more noticeable (or less) at some resolutions.

OK, the next release of GS will use the FreeType engine for rendering text, and will use the patented bytecode interpreter, as the relevant patents will have expired by then. This resolves the issues of the overly bold text, and the broken rendered glyph.

Because pdfwrite is falling back to rendering some of the text, rather than preserving it as text in a font, there are visual problems with the resulting PDF when viewed in Acrobat at certain resolutions. The bitmap is no longer guaranteed to scale in the same way as the stroke surrounding some of the glyphs, which can result in gaps emerging between the two. This is particularly noticeable at small zoom factors.

The same issue causes 'cracks' (thin white lines) to appear between the bitmap image and the stroke in some cases, when Acrobat is set to 'Smooth text'.

These are not part of the original report, and may well be unfixable in any event, and so I'm closing this as 'fixed'.

(In reply to comment #11)
> The same issue causes 'cracks' (thin white lines) to appear between the bitmap
> image and the stroke in some cases, when Acrobat is set to 'Smooth text'.

Yes, I tried turning Smooth Text to "None" (instead of "Monitor" or "Laptop/LCD") and the gaps are gone. It sounds like an Acrobat quirk, but it probably also indicate some rounding or loss-of-precision in ghostscript glyph to bitmap conversion as well.