[OpenJDK 2D-Dev] [PATCH] JDK-8152680: Regression in GlyphVector.getGlyphCharIndex behaviour

Dmitry Batrak dmitry.batrak at jetbrains.com
Wed Apr 20 13:14:11 UTC 2016


I'd like to propose a patch for JDK-8152680 - an issue I've raised
via bugreport.java.com earlier, hope someone can sponsor it.
I have a Contributor status via agreement signed by Jetbrains.

The issue is related to the extraction of glyph-to-character mapping
from results of text layout, performed by Harfbuzz,
when layout is requested for a specified substring of text string.

For LTR case, existing code assumes that cluster values (which are
later interpreted as character indices) are assigned by Harfbuzz
starting from the beginning of substring, but actually it's done
starting from the beginning of whole string (as mentioned by existing
comment in HBShaper.c). For reference, this logic can be found
at hb-buffer.cc:1470 (function hb_buffer_add_utf). The proposed fix
is to take into account this numbering scheme by shifting cluster value
correspondingly. GlyphCharIndicesTest test case is included to cover this

RTL case is not affected by the problem mentioned above, but there's
another issue with it - cluster value generated by Harfbuzz is ignored
completely, instead character index is taken to be equal to glyph index
(in visual order). This will not work, e.g. in case when there are more
than characters - some glyphs will reference non-existing characters.
The proposed fix is just to use the same shifted cluster value,
as for LTR case - I believe it works just as well in RTL case.
GlyphCharIndicesRtlTest test case is included to cover RTL case, but
I'm not sure it should be definitely committed, as it depends on a specific
Windows font, which doesn't seem to be available by default in Windows 10
(even though it must be present in Windows Vista, 7 and 8). I couldn't find
a better font on Windows, demonstrating the issue.

Webrev for the fix is available at
(kindly posted by my colleague, having access to cr.openjdk.java.net).

Best regards,
Dmitry Batrak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20160420/5c35e00d/attachment.html>

More information about the 2d-dev mailing list