You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the Feature File Syntax specification, the current wording of section 9.e is a bit unclear about which escape mechanism (single-byte or double-byte) is applicable to what encoding. The current spec ties double-byte to “Windows” encodings. But in OpenType, the Windows platform can have encodings other than UTF16-BE. For example, platformID=3 + platformEncodingID=5 is EUC-KR/Wansung, which is a variable-width encoding so double-byte sequences won’t actually work.
As of 2017, this doesn’t matter much anymore, but perhaps the spec should say “UTF-16” instead of “Windows”.
The text was updated successfully, but these errors were encountered:
Those legacy Windows encodings are still byte-based, like the Macintosh ones, and many of them are actually the same across platforms. As such, they would still use the \hh escaping mechanism, not the \hhhh one, which is for Unicode 'name' table strings. I agree that the wording can be better and more tightened.
In the Feature File Syntax specification, the current wording of section 9.e is a bit unclear about which escape mechanism (single-byte or double-byte) is applicable to what encoding. The current spec ties double-byte to “Windows” encodings. But in OpenType, the Windows platform can have encodings other than UTF16-BE. For example, platformID=3 + platformEncodingID=5 is EUC-KR/Wansung, which is a variable-width encoding so double-byte sequences won’t actually work.
As of 2017, this doesn’t matter much anymore, but perhaps the spec should say “UTF-16” instead of “Windows”.
The text was updated successfully, but these errors were encountered: