[OpenJDK 2D-Dev] [PATCH] Make automatic font substitution on macOS work for surrogate pairs

[Dmitry Batrak]

Added an automated version of the test to the webrev -
http://cr.openjdk.java.net/~avu/rfe_surrogates/webrev.01/

Best regards,
Dmitry Batrak

On Tue, Nov 1, 2016 at 5:40 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
wrote:

> Looks fine to me, but the jtreg test will be helpful.
>
> On 27.10.16 11:56, Dmitry Batrak wrote:
>
>> Sure, here's the simplest test, that can be used for visual inspection:
>>
>> import javax.swing.*;
>> import java.awt.*;
>>
>> public class SurrogatesFallbackTest {
>>     public static void main(String[] args) {
>>         SwingUtilities.invokeLater(() -> {
>>             JFrame frame = new JFrame();
>>             JLabel label = new JLabel(new
>> String(Character.toChars(0x1d400))); // MATHEMATICAL BOLD CAPITAL A
>>             label.setFont(new Font("Menlo", Font.PLAIN, 36)); //
>> expected to fallback to STIXGeneral
>>             frame.add(label);
>>             frame.pack();
>>             frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE
>> );
>>             frame.setLocationRelativeTo(null);
>>             frame.setVisible(true);
>>         });
>>     }
>> }
>>
>> I can convert it to an automatic test (rendering to a bitmap and
>> comparing the result to rendering of 'missing' glyph), and add it to the
>> webrev, if that makes sense.
>>
>> Best regards,
>> Dmitry Batrak
>>
>> On Thu, Oct 27, 2016 at 2:17 AM, Philip Race <philip.race at oracle.com
>> <mailto:philip.race at oracle.com>> wrote:
>>
>>     Hi,
>>
>>     I can file a bug on this if I can't find one.
>>     If you can email me the test it will help even if it is not checked
>> in.
>>
>>     -phil.
>>
>>     On 10/26/16, 6:28 AM, Dmitry Batrak wrote:
>>
>>>     Hello,
>>>
>>>     I'd like to propose a patch to make automatic font substitution on
>>>     macOS work for surrogate pairs.
>>>     I have a Contributor status via agreement signed by JetBrains,
>>>     hope someone can sponsor the patch.
>>>
>>>     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.
>>>
>>>     I didn't include a test for this change, as it would depend on
>>>     OS-specific font fallback mechanism
>>>     and fonts installed, but I can create one that will work on a
>>>     latest version of macOS with default
>>>     fonts, if needed.
>>>
>>>     Webrev for the fix is available at
>>>     http://cr.openjdk.java.net/~avu/rfe_surrogates/webrev.00/
>>>     <http://cr.openjdk.java.net/%7Eavu/rfe_surrogates/webrev.00/>
>>>     (kindly posted by my colleague, having access to
>>>     cr.openjdk.java.net <http://cr.openjdk.java.net>).
>>>
>>>     To my knowledge, there's no ticket in OpenJDK issue tracker for
>>>     the proposed enhancement.
>>>     I can submit it via http://bugs.java.com/, if that's an obstacle.
>>>
>>>     Best regards,
>>>     Dmitry Batrak
>>>
>>
>>
>>
>>
>> --
>> Dmitry Batrak
>> Senior Software Developer
>> JetBrains
>> http://www.jetbrains.com
>> The Drive to Develop
>>
>
>
> --
> Best regards, Sergey.
>



-- 
Dmitry Batrak
Senior Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20161103/168ca28f/attachment.html>