Created attachment 17473 [details] [review] Patch to -gsub.c and -gpos.c to enable correct lookup ordering According to the Microsoft spec[1][2], the lookup lists in an OT font are arranged in the order in which they are supposed to be applied. HarfBuzz instead applies them in the order in which HB_GPOS_Add_Feature (or GSUB equivalent) is called. This means an application must know the order in which these operations must be applied, which is sometimes impossible. As an example, turn on small cap rendering in Pango: edit pango-VERSION/modules/basic/basic-fc.c and add: {"smcp", PANGO_OT_ALL_GLYPHS} as the last line in the static gsub_features[]. You'll note that in words like "office", the 'o', 'c', and 'e' are correctly rendered as small caps, but the "ffi" is rendered as the 'ffi' ligature, because the "liga" GSUB feature is applied first. Move the line enabling "smcp" to the top of gsub_features, and this problem goes away. The attached patch (against HEAD) includes trivial changes to -gsub.c and -gpos.c to bring HarfBuzz into line with the OpenType spec. The patch was tested to compile cleanly; a nearly-identical patch against the version of HarfBuzz in Pango 1.20.3 did show correct behavior. See "Table Organization" at both links for more info. [1] http://www.microsoft.com/typography/otspec/gpos.htm [2] http://www.microsoft.com/typography/otspec/gsub.htm
This is how HarfBuzz used to be, but changed... We should back it out and make Pango/Qt make separate calls to enforce a feature order. Details here: http://bugzilla.gnome.org/show_bug.cgi?id=439298 The attached patch is suboptimal, but I know how to fix it correctly when time comes. No new patch needed. Thanks,
(In reply to comment #0) > This means an application must know the order in which > these operations must be applied, which is sometimes impossible. As an application, I wan’t to have control over the order in which features are applied. If an application does not know how to order features, fix it, not the lib IMHO. > As an example, turn on small cap rendering in Pango: edit > pango-VERSION/modules/basic/basic-fc.c and add: > ... As said, it’s a problem in the user application, which here happens to be Pango. But the fact that Behdad maintains both pieces of software should not lead to mixup things. Ok, I’m heating for nothing :) But i find it important to keep OpenType features processing neutral, as much as possible. If an app. does not want to bother with that and there’s time here to handle it, i would prefer to see a new HB helper function such as HB_Reorder_Features() which could be called after a run of HB_GXXX_Add_Feature().
Pierre, cool down :). Read the Pango bug referenced... HarfBuzz will be fixed to follow the letter of the OpenType spec. If app wants to have control on feature order then, it can call harfbuzz with a feature at a time.
I just made a Bugzilla account to report this very bug, I think. :) The problem comes from thinking that features are ordered. They are not; there is no such thing as feature order (which is something I discovered the hard way when writing my own OT code). It is lookups that are ordered, and features are just unordered sets of lookup indexes. The wording seems important because it is easy to get confused; it would help a lot if the spec were better written. I think comments in the code should refer only to lookup order and not "feature order". Applying features in a particular order (though that's not what the font designer designs for) shouldn't be a problem; just call harfbuzz multiple times.
New harfbuzz code merges lookups by lookup order, so feature order is irrelevant. That fixes this bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.