<i18n dev> Problems drawing supplemental characters in Java.

[Mark Davis ☕️]

One further question.

On the Mac, some characters are given a default emoji presentation, and
appear with a colored image. This is done by substituting the glyph from
the Apple Color Emoji.

With drawString(), when I try to draw a character in (say) Symbola that by
default on the Mac is emoji, the font says .canDisplay(...) is true, but I
get no image, just blank. It's like drawing a space.

If I try to draw *any* character in Apple Color Emoji, I get a blank as
well.

Is there any way to work around this, and use the Apple Color Emoji?

Note: I tried using a JTextArea to work around this. When I changed the
existing TextAreaDemo.java to add the following 2 lines, it crashed!

        textArea.setFont(*new* Font("Apple Color Emoji", 0, 18));

        textArea.setText("abc��def");


Same happens if the setText line is omitted, and if you simply paste in an
emoji character into the running program.


Mark <https://google.com/+MarkDavis>

 *— Il meglio è l’inimico del bene —*


On 9 April 2014 21:28, Mark Davis ☕️ <mark at macchiato.com> wrote:

> Fixes it, thanks!!
>
>
> Mark <https://google.com/+MarkDavis>
>
>  *— Il meglio è l’inimico del bene —*
>
>
> On 9 April 2014 19:43, Phil Race <philip.race at oracle.com> wrote:
>
> > So can you please update to 7u51 (current security baseline) and see if
> > that cures it ?
> > http://www.oracle.com/technetwork/java/javase/7u51-relnotes-2085002.html
> >
> > -phil.
> >
> > On 4/9/2014 10:29 AM, Mark Davis ☕️ wrote:
> >
> >> jdk1.7.0_25.jdk
> >>
> >>
> >> Mark <https://google.com/+MarkDavis>
> >> /
> >> /
> >> /— Il meglio è l’inimico del bene —/
> >> //
> >>
> >>
> >>
> >> On 9 April 2014 18:31, Phil Race <philip.race at oracle.com <mailto:
> >> philip.race at oracle.com>> wrote:
> >>
> >>     Sounds like https://bugs.openjdk.java.net/browse/JDK-8015556
> >>     [macosx] surrogate pairs do not render properly (show up as boxes
> >>     or incorrect glyphs)
> >>
> >>     But that was fixed in 7u40. What JDK 7 update is in use here ?
> >>
> >>     -phil.
> >>
> >>
> >>     On 4/9/14 9:17 AM, Naoto Sato wrote:
> >>
> >>>     Hi Mark,
> >>>
> >>>     On 4/9/14, 3:11 AM, Mark Davis ☕️ wrote:
> >>>
> >>>>     I'm having some trouble with drawing supplemental characters in
> >>>>     Java. It
> >>>>     appears to be due to bugs in Java.
> >>>>
> >>>>     *First, how do I report this? And second, can anyone think of a
> >>>>     work-around?*
> >>>>
> >>>
> >>>     Here is the link to report an issue against JDK:
> >>>
> >>>     http://bugreport.java.com/bugreport/
> >>>
> >>>     Please choose "classes_2d" as the subcategory.
> >>>
> >>>
> >>>>     This is on a Mac OS 10.9.2, JDK 7, and I am rendering a number of
> >>>>     characters in a loop.
> >>>>
> >>>>     When I call
> >>>>
> >>>>                      graphics.drawString(s, xStart, ascent);
> >>>>
> >>>>     Each supplemental character that shares the same first char (high
> >>>>     surrogate) gets the same image (see attachments).
> >>>>
> >>>>     It appears that it is caching by char instead of by code point.
> >>>>
> >>>>
> >>>>     To work around the problem, I tried changing the code to draw
> glyph
> >>>>     vectors instead.
> >>>>
> >>>>                      FontRenderContext frc =
> >>>>     graphics.getFontRenderContext();
> >>>>
> >>>>                      GlyphVector gv = myFont.createGlyphVector(frc,
> s);
> >>>>
> >>>>                      ...
> >>>>
> >>>>                      Shape shape = gv.getOutline(xStart, ascent);
> >>>>
> >>>>                      graphics.draw(shape);
> >>>>
> >>>>     To my surprise, it got even worse: I get an unknown glyph after
> >>>>     each
> >>>>     image. See attachments.
> >>>>
> >>>>     It appears that when it is advancing through the string to get the
> >>>>     glyphs, it is picking up the glyph ID for the code point, but
> >>>>     then it is
> >>>>     only advancing by 1, so it is always picking up garbage after each
> >>>>     character.
> >>>>
> >>>
> >>>     Yeah, your explanation does sound like what's happening in the
> >>>     font rendering on MacOSX. Phil/Mike, do you have any idea what's
> >>>     going on?
> >>>
> >>>     Naoto
> >>>
> >>
> >>
> >>
> >
>