[mpeg-OTspec] Re: [OpenType] MS Proposal for a new Name Table ID

[John Hudson]

On 11/01/13 5:47 AM, Jelle Bosma wrote:

> I understand that. But I think you can identify the language of a CJK
> font by looking at the code pages.

> But apart from Devanagari, and possibly Cyrillic, I cannot think of
> other cases where you cannot check the language support by looking at
> the cmap. Maybe that is my ignorance. But nobody has given other
> examples where Unicode has assigned code points to characters where
> different languages expect completely different shapes (excluding
> ancient scripts and dead languages).

But that isn't what the proposal is intended to address. The question is 
not 'What languages does this font support?'. The question is 'For what 
languages is this font intended to be used?'. And the proposal exists 
because character set and codepage standards frequently include 
characters that are outside the intended use of the font. I'm sure you 
have made plenty of fonts that contain, for merely technical and 
software compatibility reasons, 8-bit codepage support that is 
extraneous to the intended function of the font. And every font 
supporting even a non-Latin 8-bit codepage also supports a 7-bit Latin 
subset, regardless of whether the intention is ever for that font to be 
used to set English text. The proposal is to provide a mechanism to 
indicate whether these fonts should be considered as options for setting 
text in those scripts or not.

Earlier you wrote, in response to my illustration of a possible 
additional kind of metadata re. font use: "You can mark these fonts, 
without having to add language tags in all the fonts that are not UI 
fonts." But the proposal doesn't require adding language tags to any 
fonts at all. If no script/language tag is provided to indicate the 
intended purpose of the font, then software can assume that any 
script/language supported by the cmap is viable. The purpose of the 
proposal is to make it possible to tag exceptions, i.e. fonts in which 
only some of the characters in the cmap fulfil the intent of the font's use.

> - If there aren't many more of these cases, one could use the
> reserved code page bits.

Codepage bits should accurately indicate what codepages a font supports; 
otherwise they might as well be ignored altogether. You can't extend the 
use of codepage bits to capture a different kind of information without 
introducing potential conflicts.

> - It has has been suggested to use the GSUB to mark script language
> support.

OTL language system support indicates exceptions from default shaping. 
It doesn't tell you anything about the primary intended use of the font.

> - Or expand the OpenType specifiction

That's what the current proposal involves, or are you thinking of some 
other kind of expansion.


Jelle, please note that I am not actively supporting this proposal from 
Microsoft. I'm not sure that the problem it solves is significant enough 
to merit this kind of solution. But I do think it is important to 
accurately understand the proposal, and it seems to me from your 
comments that you think it is trying to do something other than what it is.

JH


-- 

Tiro Typeworks        www.tiro.com
Gulf Islands, BC      tiro at tiro.com

The criminologist's definition of 'public order
crimes' comes perilously close to the historian's
description of 'working-class leisure-time activity.'
  - Sidney Harring, _Policing a Class Society_