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

[Philip Race]

Uint .. but it looks like UniChar is also unsigned.
That  header file looks like it *is* the documentation.
Fine if you already know where to look but ..

Anyway based on the report that you've used this for months in 
production I can give this a "+1"
Sergey already reviewed too.
Who is going to push this ?

-phil.

On 11/10/16, 7:58 AM, Dmitry Batrak wrote:
> Updated webrev (removed wild card import): 
> http://cr.openjdk.java.net/~avu/JDK-8169202/webrev.03/ 
> <http://cr.openjdk.java.net/%7Eavu/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 
> <http://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 
> <mailto: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
>>     <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/
>>     <http://cr.openjdk.java.net/%7Eavu/JDK-8169202/webrev.02/>
>>     (kindly posted by my colleague, having access to
>>     cr.openjdk.java.net <http://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/82f847a2/attachment.html>