[Devel] Re: Problem with ligature patch

[Lars Knoll]

Hi,

> Apparently there are problem with the changes in:
>
> http://people.redhat.com/otaylor/opentype-patches/index.html#freetype-07-li
>gature-ids
>
> See:
>
> http://bugzilla.gnome.org/show_bug.cgi?id=118472
>
> And certainly, I can see where this patch wouldn't always work; you
> could have:
>
>  A ' C ^
>
> And ligatures:
>
>  A B  => AB  (ignore marks flag set)
>  ' ^  => '^ (ignore base flag set)
>
> Then I'd expect the output:
>
>  AB '^
>
> Though I do understand, I think, the problem that is trying to be
> solved here - the ArabicTypesetting font distributed with VOLT has
> ligatures:
>
>  uni064E uni0651=> uni0651064E  (FATHA + SHADDA)
>
> So, if you had two base glyphs that ligatured mixed with FATHA
> and SHADDA, there is potentially a problem.
>
> Perhaps the right solution here is simply ordering?
> if you look at ArabicTypesetting, the mark+mark ligatures are
> part of the 'ccmp' features which is should be the first feature
> applied for Arabic, while the base+base ligatures are part of the
> 'rlig' feature, which is applied later.
>
> When this ordering is maintained, the issue goes away.
>
> So, perhaps the problem is one of the FT_GSUB_Apply_String API?
> I think the Microsoft code uses first the order of features
> in the relevant spec, *then* the LookupList order, rather than
> applying all lookups strictly in LookupList order, which is what
> will happen with the current API (unless you make multiple passes)

This was one of the reasons we changed the API in Qt to FT_GSUB_Apply_Feature. 
For most fonts the lookuplist order and the order defined in the Microsoft 
specs are the same, but there are some fonts that don't encode this 
correctly. The safe bet is to use the order defined in the script specific 
specs and not the one in the font.

Regards,
Lars

> Do you happen to remember what font and what input you were using
> when you added this patch?
>
> Thanks,
>                                       Owen