font handler should prefer embedded language information if available #66
Description
There are two options for language detection that are not currently exploited by the font handler.
The first is the "design languages" and "supported languages" fields in the OpenType/TrueType meta table. The table entries are dlng and slng, respectively, and are references to private entries in the font's general name table.
A "design language" would take precedence over a "supported language" if the two language-lists aren't identical; the theory being that "design language" might indicate special care taken for a particular language.
Example: Vietnamese often has to stack multiple diacritics and tone marks, so a font designed for Vietnamese might use slightly smaller-x-height lowercase letters and have diacritics ensured to work ... whereas a font designed for English might "support" Vietnamese, but look bad because (without that requirement in mind) its stacks of diacritics get too tall and are often cut off at the top.
( The table is detailed here: https://docs.microsoft.com/en-gb/typography/opentype/spec/meta )
These entries aren't automatically generated, so if they're present in the binary they ought to be given considerable weight.
The other is more of a fallback, but the list of languages in the font's GSUB table ought to be a practical list of the supported languages.
( https://docs.microsoft.com/en-gb/typography/opentype/spec/chapter2#slTbl_sRec )