<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    <br>
    I can file a bug on this if I can't find one.<br>
    If you can email me the test it will help even if it is not checked
    in.<br>
    <br>
    -phil.<br>
    <br>
    On 10/26/16, 6:28 AM, Dmitry Batrak wrote:
    <blockquote
cite="mid:CAET5FPvdbaqj-gc+ymv5B1J1D2q1Thm2_dg=gBjLgmE4NjS27Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hello,<br>
        <br>
        I'd like to propose a patch to make automatic font substitution
        on macOS work for surrogate pairs.<br>
        I have a Contributor status via agreement signed by JetBrains,
        hope someone can sponsor the patch.<br>
        <br>
        Currently, if requested font cannot render a Unicode character
        represented by a surrogate pair,<br>
        no substitution is performed - Font.canDisplay will return
        false, and the character will be<br>
        rendered as a 'missing' glyph. This behaviour doesn't violate
        any specification, but it looks like<br>
        it can be easily improved, as underlying OS framework used under
        the hood does support surrogate pairs.<br>
        <br>
        The proposed change consists of two parts. First part is
        adjusting the code in CoreTextSupport.m <br>
        to handle surrogate pairs while performing char-to-glyph
        mapping, by encoding non-displayable <br>
        surrogate pairs using negative values of the codepoint, similar
        to how non-displayable BMP characters<br>
        are encoded. Second part is fixing the rendering code (in
        CGGlyphImages.m), where wrong type was used<br>
        to pass character values around, so that code for surrogate
        pairs handling, already present there, <br>
        could work.<br>
        <br>
        I didn't include a test for this change, as it would depend on
        OS-specific font fallback mechanism<br>
        and fonts installed, but I can create one that will work on a
        latest version of macOS with default<br>
        fonts, if needed.<br>
        <br>
        Webrev for the fix is available at<br>
        <a moz-do-not-send="true"
          href="http://cr.openjdk.java.net/%7Eavu/rfe_surrogates/webrev.00/">http://cr.openjdk.java.net/~avu/rfe_surrogates/webrev.00/</a><br>
        (kindly posted by my colleague, having access to <a
          moz-do-not-send="true" href="http://cr.openjdk.java.net">cr.openjdk.java.net</a>).<br>
        <br>
        To my knowledge, there's no ticket in OpenJDK issue tracker for
        the proposed enhancement. <br>
        I can submit it via <a moz-do-not-send="true"
          href="http://bugs.java.com/">http://bugs.java.com/</a>, if
        that's an obstacle.<br>
        <br>
        Best regards,<br>
        Dmitry Batrak</div>
    </blockquote>
  </body>
</html>