[OpenJDK 2D-Dev] Kerning and Ligatures using Layout Engine

Keith Stribley devel at thanlwinsoft.org
Wed Jun 25 20:20:35 UTC 2008


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



More information about the 2d-dev mailing list