Hi Phil, thanks for your response, it has helped clarify my understanding and I think I've found the real bug - see below.
Phil Race wrote: > Keith Stribley wrote: >> I am interested in getting clig,liga,mark,mkmk,kern OpenType tables to > > Those are not tables. Those are features in the OpenType GSUB and GPOS > tables. Yes, sorry for the confusion. > > FYI: it was "current" at the point in JDK 6 development when it was > integrated. > JDK 7 will get an updated version in due course. Great, though I'm not sure it will affect the Myanmar rendering in this case. ICU 4 in general has support for Unicode 5.1, which is needed for Myanmar. >> I'm not quite sure why 0x4 is used as the value when there are marks, I >> believe it corresponds to "no canonical processing", though I don't know >> why that is needed. > > I think you have this backwards. Sorry, I read the comment in LayoutEngine::characterProcessing(...) too quickly and was perhaps confused by the actual behaviour. Is the "canonical processing" flag an OpenJDK specific optimisation? I couldn't see it in ICU svn history, but perhaps I was looking at the wrong revisions. > So optional ligatures and kerning need to be requested by those > who know they want them. This is fine for Latin text, but not for Burmese, which is heavily dependent on ligatures to make it readable. Most Burmese Unicode fonts also use kerning. > > I would have to dig to be sure what actually happens > in ICU, but one scenario is mixed script text. Eg some latin followed > by some complex script. If the optional ligatures were performed by > layout and you are in say a text editor and delete the complex > text leaving only the latin text it would look odd if the optional > ligatures no longer formed and if kerning stopped being applied. Currently the opposite happens. As soon as the complex script is present, the kerning and ligatures stop if they were requested in the TextAttributes. Consider the latin case with say DoulosSIL http://scripts.sil.org/DoulosSIL_download : fi ffi fi ffi â̬ Both lines should show the ffi ligatures when set in the TextAttributes, but only the first one does, because the marks on the second line trigger eflags. > > However if you are pointing out that even when specifying > TextAttribute.KERNING and TextAttribute.LIGATURES that they do not > get applied, then that would seem like a bug. Yes. > But my reading of > the code is that that the request for kerning and ligatures is > not held in "eflags" but in "_typo_flags" and the value > passed down to layout is "_typo_flags | eflags" I've looked some more into this, and I believe there is a bug in the OpenTypeLayoutEngine constructor (jdk/src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp). This currently does not expect a value greater than 3 for typoFlags, so if 4 is applied then kerning and ligatures are disabled, which is fine if only bit 4 is set, but not if you have 7 from the or that you describe. This wouldn't trigger in the normal ICU as I don't think they use the 0x4 flag. I've now added & 0x3, so that 0x4 bit will be ignored when setting the feature mask: switch (typoFlags & 0x3) { case 0: break; // default case 1: fFeatureMask = kernFeatures; break; case 2: fFeatureMask = ligaFeatures; break; case 3: fFeatureMask = kernAndLigaFeatures; break; default: break; } > > As far as I can see your patch is equivalent to always > adding the TextAttribute.KERNING and TextAttribute.LIGATURES > as attributes on these two fonts (no JDK source code changes > needed). Is that what you see? Now I've found the bug in OpenTypeLayoutEngine and if that was fixed, that might be the case. But I don't think it should be regarded as just applying for 2 specific fonts. Burmese relies on ligatures in many words (as do most if not all of the other languages using the Myanmar code block). If ligatures and kerning aren't enabled Burmese Unicode text is unreadable. I think they should be enabled by default for the Myanmar code block, at least when marks are present. Most people will not realise that these attributes need to be set to get correct Burmese (and with the current bug, they won't take affect anyway because they involve marks). > > Before we can accept any patch you will need to sign and submit > the Sun Contributor Agreement. See http://openjdk.java.net/contribute/ I've just signed and emailed it. Regards, Keith
