Clarify and extend behavior around names in the FontMetadata object

[rcombs]

I noticed a few shortcomings here; they can all be addressed by applications by parsing the SFNT directly, but it'd certainly be helpful to have some improvements made:

• What happens if a font has no name of a given type in the current language? Do you get en? What happens in cases involving multi-label IETF language tags?
• As mentioned in the "Issue 9" mentioned in the spec draft, it may be useful to retrieve a specific language; however, it may also be useful to retrieve a full list of names of a given type for the font, particularly for matching purposes.
• What happens if a font has multiple names with the same type and language, but different vendors? This is remarkably common, the names can differ, and some applications may need the names from a specific vendor. This should be clarified for both query({select}) and the metadata objects (even if it just ends up being implementation-defined).

[annevk]

I don't think all of these are enhancement requests. E.g., the first and last bullet point need to be defined, no?

[rcombs]

Yeah, there's a reasonable argument to be made that those are spec defects that should be corrected.

[inexorabletash]

Updated the label, and suggestions for all of these concerns would be welcome.

• For the first bullet, the text was updated to read "...if multiple localizations are available, the user language version must be used if provided, or the first localization otherwise"
• For the last bullet, it sounds like you know more about fonts in the wild than I do. Can you lend your expertise here, in terms of what would be most practical for implementers given how OSes expose fonts, and for developers consuming the data?

[rcombs]

For the last bullet, platform behavior seems to vary a lot. On Windows, the PostScript name isn't even always used for matching (it seems to depend on the font type; if the font isn't either Type 1, Type 42, CID Type 1, or CFF, it instead matches based on the full name). FreeType prefers Windows-formatted PostScript names over Mac-formatted ones; macOS supports both but appears to ignore a Windows name if a corresponding Mac name is available. I think Windows only supports Windows names but I'm not 100% certain.

As a developer, the best thing the API could do for me would be to let me query fonts by passing a font-request object (name + possibly weight/slant + possibly string being rendered) to the OS that is searched for via whatever fast mechanism the system provides. Currently you mention linear searches, but OSs generally provide a faster lookup mechanism that doesn't require retrieving and iterating the full list (e.g. WinGDI uses a hash-table lookup). Note that on some platforms, the relevant API only returns a single font rather than a list (Android, WinGDI), thus the potential need to specify a weight/slant. Specifying a sample string being rendered can be critical if I'm performing fallback due to a missing glyph; the OS generally knows a suitable fallback font for every supported Unicode character range, and usually doesn't expose that mapping directly. If I want to do a slow-but-consistent linear search, I can implement that myself.