Request for review: 7124223: [macosx] Regression test failure with new exception, when glyph is positioned explicitly
philip.race at oracle.com
Tue Feb 14 14:01:02 PST 2012
I am not sure that this negative value should ever have been
propagated outside of the OS X specific code that knows what it
means and how to handle it.
What the shared code is trying to do is reconstitute a unicode string
from a GlyphVector
for postscript text printing. Skipping, as you propose, is OK here, as
if we ever need that skipped mapping we'll do what we do for any
unmapped char here, which is return from this method and try a
different approach which should not rely on the same behaviour
and likely should print properly.
But any time the shared code has to deal with the OS X specific
font code there's a possibility of a mismatch of expectations.
So approved with that caveat.
On 2/14/2012 11:48 AM, Andrew Brygin wrote:
> there is a small fix for a regression test failure.
> Note that PathGrapics uses a glyph codes as a indexes in an array
> in order to provide a mapping from glyph codes back to unicode
> characters. So, it assumes that glyph code is not negative.
> However it is not true in case of macosx: if there is no glyph
> in a font for some character, then macosx font support machinery
> returns negative unicode char in order to indicate that this char
> requires a substitution (CoreTextSupport.m, lines 92 - 126).
> Suggested fix just ignores negative glyph codes in PathGrapics.
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124223
> Webrev: http://cr.openjdk.java.net/~bae/7124223/webrev/
More information about the macosx-port-dev