On a related note, there is a number of fonts with Latin an Cyrillic and/or Greek alphabets which provide all features such as "kern", "smcp", "liga" etc. only in the "latn" script even if those features affect also the Cyrillic and/or Grrek fonts. This is mostly due to the tool used to produce them. Adobe FDK for OpenType v1.6 (also integrated in FontLab Studio 5.0) only registered the "latn" script in the font unless the font developer scecified other scripts explicitly (using the "languagesystem" keyword in the AFDKO feature definitions). Many font developrs were not aware of this, and earlier versions of Adobe apps only applied features from the "latn" script -- for all Unicode characters regardless of their actual script. So the fonts "worked fine" in Adobe apps and the problem went unnoticed.
Especially "simple" fonts which only have the "kern" feature, usually automatically produced from a font editor's internal kerning table or an older kerning definition such as the TrueType "kern" table or a Type 1 AFM file, exhibit this behavior. A really considerable number of fonts is affected, so I, too, recommend using "latn" as the fallback script if no other scripts are registered -- which is actually consistent with the Adobe implementation. Regards, Adam Sent from my mobile phone. On 21.01.2012, at 11:27, Jonathan Kew <jonat...@jfkew.plus.com> wrote: > It turns out that some legacy Thai fonts provide OpenType substitution > features to implement mark positioning, but (incorrectly) put those > features/lookups under the 'latn' script tag instead of using 'thai' (or > possibly 'DFLT'). See https://bugzilla.mozilla.org/show_bug.cgi?id=719366 for > an example and more detailed description. > > Although this is really a font bug, I suggest that we could improve the > rendering of such fonts by looking for the 'latn' as a fallback if neither > the requested script nor "default" is found in > hb_ot_layout_table_choose_script. Suggested patch against harfbuzz master is > attached. > > This does _not_ affect the other kind of legacy Thai font, where custom code > to support vendor-specific PUA codepoints would be needed. I'm not keen to go > down that path; IMO, such fonts should be ruthlessly stamped out in favour of > standards-based solutions. :) > > JK > > <latin-fallback> > > > _______________________________________________ > HarfBuzz mailing list > HarfBuzz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/harfbuzz _______________________________________________ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz
