I have submitted https://bugs.openjdk.java.net/browse/JDK-8169202
Can you restart this thread with the proper format for a review request
as the subject
"RFR: 8169202: macos] Font substitution does not work for supplementary
characters"
-phil.
On 11/03/2016 07:23 AM, Dmitry Batrak wrote:
Added an automated version of the test to the webrev -
http://cr.openjdk.java.net/~avu/rfe_surrogates/webrev.01/
<http://cr.openjdk.java.net/%7Eavu/rfe_surrogates/webrev.01/>
Best regards,
Dmitry Batrak
On Tue, Nov 1, 2016 at 5:40 PM, Sergey Bylokhov
<sergey.bylok...@oracle.com <mailto:sergey.bylok...@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.r...@oracle.com <mailto:philip.r...@oracle.com>
<mailto:philip.r...@oracle.com
<mailto:philip.r...@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/>
<http://cr.openjdk.java.net/%7Eavu/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>
<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
