<i18n dev> Problems drawing supplemental characters in Java.
Mark Davis ☕️
mark at macchiato.com
Thu Apr 10 15:31:38 UTC 2014
FYI, here is how Firefox solved the problem:
https://bugzilla.mozilla.org/show_bug.cgi?id=715798#c44
Mark <https://google.com/+MarkDavis>
*— Il meglio è l’inimico del bene —*
On 10 April 2014 14:45, Mark Davis ☕️ <mark at macchiato.com> wrote:
> 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("abcdef");
>
>
> 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
>> >>>
>> >>
>> >>
>> >>
>> >
>>
>
>
More information about the i18n-dev
mailing list