[OpenJDK 2D-Dev] RFR: 8169202: [macos] Font substitution does not work for supplementary characters

[Dmitry Batrak]

Updated webrev (removed wild card import):
http://cr.openjdk.java.net/~avu/JDK-8169202/webrev.03/

As for UnicodeScalarValue, I couldn't find its description (or the
description of an equivalent type UTF32Char) on developer.apple.com either.
It's defined at MacTypes.h, at the same place where UniChar is defined,
like this:

    /* ...
        UnicodeScalarValue,     A complete Unicode character in UTF-32
format, with
        UTF32Char                   values from 0 through 0x10FFFF
(excluding the surrogate
                                           range 0xD800-0xDFFF and certain
disallowed values)
    ... */
    typedef UInt32                          UnicodeScalarValue;

For what it's worth, the proposed change is part of OpenJDK-based build
bundled with JetBrains IDEs (in production since July this year), and there
are no known issues related to it, either reported by users, found in IDEs
testing or in JDK testing (AWT/Swing OpenJDK 8 jtreg tests).

Best regards,
Dmitry Batrak


On Wed, Nov 9, 2016 at 11:55 PM, Phil Race <philip.race at oracle.com> wrote:

>   29 import java.awt.*;
>
> We avoid wild card imports - even in tests.
>
> Can you provide a pointer to any Apple docs on UnicodeScalarValue.
> I can't find it .. I presume its a typedef of int so it can hold a composed
> unicode code point outside the BMP ..
>
> By already existing support I guess you refer to this :-
>
>  592 CGGI_CreateImageForUnicode
>  593     (CGGI_GlyphCanvas *canvas, const AWTStrike *strike,
>  594      const CGGI_RenderingMode *mode, const UnicodeScalarValue uniChar)
> ...
>  602     if (uniChar > 0xFFFF) {
>  603         UTF16Char charRef[2];
>  604         CTS_BreakupUnicodeIntoSurrogatePairs(uniChar, charRef);
> ...
>
>
> This code was a bit more work to review than I was expecting because
> of having to follow things around to see if numGlyphs != num16bitChars
> was a problem or if the "non-negative" cases where we already have
> a glyph were handled properly. And I'm still not entirely sure.
> What reg. tests and other general testing has been done with this fix ?
>
> -phil.
>
>
> On 11/07/2016 06:52 AM, Dmitry Batrak wrote:
>
> Hello,
>
> I'd like to propose a patch for https://bugs.openjdk.java.net/
> browse/JDK-8169202.
> I have a Contributor status via agreement signed by JetBrains, hope
> someone can sponsor the patch.
> This repeats the proposal I've sent earlier to this mailing list,
> adding now a reference to the created OpenJDK issue.
>
> Currently, if requested font cannot render a Unicode character represented
> by a surrogate pair,
> no substitution is performed - Font.canDisplay will return false, and the
> character will be
> rendered as a 'missing' glyph. This behaviour doesn't violate any
> specification, but it looks like
> it can be easily improved, as underlying OS framework used under the hood
> does support surrogate pairs.
>
> The proposed change consists of two parts. First part is adjusting the
> code in CoreTextSupport.m
> to handle surrogate pairs while performing char-to-glyph mapping, by
> encoding non-displayable
> surrogate pairs using negative values of the codepoint, similar to how
> non-displayable BMP characters
> are encoded. Second part is fixing the rendering code (in
> CGGlyphImages.m), where wrong type was used
> to pass character values around, so that code for surrogate pairs
> handling, already present there,
> could work.
>
> Webrev for the fix is available at
> http://cr.openjdk.java.net/~avu/JDK-8169202/webrev.02/
> (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/20161110/e94a19c4/attachment.html>