Jonathan, CHN is probably a leftover from some old Microsoft "TrueType Open" implementation, and I don't see a problem in including a few commonly misspelled langsys tags (TUR instead or TRK was also used in some shipping fonts by mistake).
I like your proposal for a "fallback default langsys for a script". It certainly fits the CJK case, where the Han glyphs in a particular font are always Japanese, Korean, Trad Chinese or Simp Chinese — i.e. conceptually, there really is no "default languagesystem". Conceptually treating langsys branches as "exceptions from default" may work for Latin or Cyrillic or other scripts that are used by many languages. But there is a number of scripts which are tied strongly to a particular language — such es Greek or Thai. I'd argue that it's a conceptual weakness of the OpenType model to expect fonts to always have a default langsys per script. A font maker may rightfully and sensibly not implement it and only implement a specific script+langsys combo — not just for CJK but for other scripts as well. If a Bulgarian type designer draws Bulgarian-flavored Cyrillic glyphs in a font but does not at all draw the "Russian-flavored" glyphs, he should be free to implement all features ONLY in the "cyrl/BGR" branch (and not include other scripts or langsyses), and such a font should work. A. > On 10.10.2014, at 10:46, Jonathan Kew <[email protected]> wrote: > > If the script we're using has no matching langSys for the buffer's language, > and if there's also no default langSys defined, then look for the "typical" > language system(s) for the script (e.g. ENG for 'latn') - allowing this to be > a list of tags, so that for 'hani', for instance, we could list ZHS, ZHT, JAN > ... and we could append the unofficial CHN here. > > So we'd need to have a mapping of script tag -> langSys tag(s), often just > one "prototypical" language that uses the script, but sometimes several > candidates. This would address the comparable issue of a font that (for > example) provides features only under arab/ARA (or deva/HIN), and is > presented with text tagged as Persian (or Nepali)... ISTM it'd be better to > use the Arabic- (or Hindi-) language features here than to fail altogether. > > (This is obviously related, though not identical, to the idea of Pango's > pango_script_get_sample_language function.) > > WDYT? > > _______________________________________________ > HarfBuzz mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/harfbuzz _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
