Created attachment 7694 [details] file exhibiting problem The attached file renders the text correctly, but some of it is mispositioned, apparently because the text advance moves the current point in the wrong direction (vertically instead of horizontally). This appears to be related to the CMap and its use of WMode 1, for some reason other interpreters seem to be ignoring this.
P1 for customer bug. NB this was originally reported against pdfwrite, though the problem appears on rendering as well. Please check against pdfwrite when fixed.
We erroneously fabricated vertical metrics for a CIDFontType 2 font. Fixed in: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=2fab16
*** Bug 692576 has been marked as a duplicate of this bug. ***
Created attachment 8683 [details] PS file still exhibiting problem. This bug was marked as fixed but the customer reports it is still broken and provided a Postscript file which is indeed wrong. The original attachment to the bug is a PDF file. Not sure what happened here so I'm just reopening for investigation.
Rendering was fixed with the above patch, but it seems that pdfwrite still has an issue. Sorry Ken......
Created attachment 8684 [details] Cut down example Test cut down to one word.
Taking this back, as I have an idea of how to resolve it.
pdfwrite case fixed in this commit: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=fae7be45 Sorry for the confusion on this one......
Some further analysis: For each glyph, we have to both consult the font WMode *and* check for vertical metrics in the font dictionary - iff both WMode is "1" *and* vertical metrics are available should we treat the glyph as writing vertically, otherwise, treat it as a horizontal writing glyph. I *think* the problem we have is that, in pdfwrite's scan_cmap_text(), we don't check for vertical metrics as we process each glyph, so we're going solely on WMode. We can use "subfont->procs.glyph_info()" to check for vertical metrics, set a transient WMode value based on that, which can solve the problem with this file, but causes a few regressions in our test suite. I'm guessing that pdfwrite is using the font WMode elsewhere in the glyph processing, but I'm already way beyond my knowledge of pdfwrite......
Commit 2ff29d1f499451c63ddb8b3cc152cb2eda4b5e33 I believe properly resolves htis issue with pdfwrite. I have checked the result visually against the Acrobat result, and I do so some differences in the way the 'fake bold' is handled. This is done (badly) by drawing the text three times in slightly different positions. It appears that Acrobat has a heuristic for detecting this and turning it into a stroke+fill text rendering mode instead. Because of rounding errors we appear to have text which is slightly bolder than the Acrobat output, but it is not mis-positioned.