Ping... Any workaround for Java not being able to draw these characters?
Mark <https://google.com/+MarkDavis> *— Il meglio è l’inimico del bene —* On 10 April 2014 14:45, Mark Davis ☕️ <m...@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("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 ☕️ <m...@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.r...@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.r...@oracle.com <mailto: >> >> philip.r...@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 >> >>> >> >> >> >> >> >> >> > >> > >
