From: verdyp_at_gmail.com [mailto:verdyp_at_gmail.com] On Behalf Of Philippe Verdy
> What would be the behavior of a font that would use GSUB entries (or
> ligatures) in a feature to implement the reordering that NO renderer
> currently implements for Buginese ? What will happen later if the
> renderer does implement it ?
Your question is no coherent: OpenType features cannot be used to trigger re-ordering.
> Does the OpenType specification allow specifying a temporary override
> for the missing renderer reordering capabilities ?
No, and I don't see how that would make any sense: if a rendering system support Buginese script, then it supports it and does the reordering necessary. It either supports it or it doesn't.
> Note: The Microsoft Font Validator (found in Microsoft Typography
> website, section for Downloadable Tools) still does not recognize bit
> 96 of the ulUnicodeRange field, officially defined for the Buginese
> block range (U+1A00..U+1A1F), and reports an error if this bit is set.
I'll report that to the team that maintains that tool.
> And the Fonts folder in Windows 7 Explorer does not say that the font
> effectively supports Buginese (a Buginese font says that it supports no
> script at all, even if all code points assigned in the Buginese block are
> mapped, and bit 96 is set in Unicode Ranges of the header).
Two issues:
1) Windows 7 does not provide text-display support for Buginese script.
2) The scripts show in the "Designed for" column in the Fonts control panel in Windows 7 does not make use of the UnicodeRanges fields in the OS/2 table. There are a few reasons for this:
- that data is not all that reliable since there's no consistent practice in how it is set (there's no metric to decide when a bit should or shouldn't be set);
- the UnicodeRanges fields are not scalable into the future (they were exhausted with Unicode 5.1); and
- the UnicodeRanges fields are typically set based on some sense of "can display" whereas what we were thought was much more useful to users was to indicate "was designed for". For example, MS Gothic _can_ display English text, but we think it's not a particularly useful choice for English users since that's not the audience it was designed for. The intent is to give useful recommendations that help users differentiate relevant options from distracting noise.
Rather than using the OS/2 data, the Fonts cpl uses metadata outside the font. Unfortunately, it has it only for a certain set of fonts that were known when we shipped to be on most systems; so, if you add a Buginese font, the metadata will not include that font.
> This is the case for all ulUnicodeRange bits defined now after
> bit number 87, i.e. the Deseret block of the UCS, meaning that
> the validator and the Windows 7 text renderer and Fonts
> Explorer are still only based on the (now very old) Unicode 4.1
> of... 2003 (with the Deseret additions) or even before in 1996
> with Unicode 3.1 only. Who's late ?
Font Validator may be out of date; as mentioned, I'll pass that on to the relevant team. As for the Fonts control panel, as mentioned it doesn't use ulUnicodeRange fields at all; but you have spotted a bug in our metadata: Deseret should be listed for the Segoe UI Symbol font.
Peter
Received on Mon Jul 25 2011 - 13:32:31 CDT
This archive was generated by hypermail 2.2.0 : Mon Jul 25 2011 - 13:32:32 CDT