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

[Levantovsky, Vladimir]

FYI

-----Original Message-----
From: listmaster at indx.co.uk [mailto:listmaster at indx.co.uk] On Behalf Of John H. Jenkins
Sent: Monday, January 07, 2013 1:59 PM
To: "multiple recipients of OpenType"@mail.indx.co.uk
Subject: Re: [mpeg-OTspec] Re: [OpenType] MS Proposal for a new Name Table ID

Message from OpenType list:


The problem with a bitarray is that we would quickly run into the same problem we've already got with the 'OS/2' table: you run out of bits. Its advantage is that it's fixed-sized.  

Personally, I would prefer something like the original proposal of a string with comma-separated language identifiers. We've already got variable-length data in OT (although not yet in the 'OS/2' table), so I don't think that's insuperable.  

I would still recommend a new table, however. The 'OS/2' table is already pretty unwieldy. 

On 2013年1月7日, at 上午1:35, Juergen Willrodt <juergen at urwpp.de> wrote:

> Message from OpenType list:
> 
> 
>> ****** Attachments to this email message have been removed ******
> 
> 
> 
> 
> I would like to support Johns suggestion to add new entries to the 
> OS/2 table instead of adding entries to the name table.
> I would suggest to add two different entries, one should be for the 
> preferred or intended language, which could be a simple language tag. 
> This can be extremely useful for example in sorting fonts in the UI 
> font menue. In Adobe Apps the fonts are classified according to the 
> script and since we have generated some multiscript fonts its dificult 
> to predict the classification which InDesign will use.
> A font which supports Korean, Chinese simplified, Western and Eastern 
> Europe will be classified and sorted as Korean, whereas most customers 
> wants these fonts sorted under latin. This is sometimes difficult to 
> explain and could be solved with a "preferred language" tag.
> 
> A second entry could be a bitarray like the Unicode or Codepage Range 
> bits. This bit could indicate whether a specific language  is 
> supported by this font. But as pointed out by Bob Hallissey this is 
> rather complicated. I think this would require a kind of 
> standardization of the character set for all existing languages( this 
> is a huge amount of work, certainly partly already done). And of 
> course the OT features for complex scripts have to be included to 
> indicate that the font is working for a specific language. Also for 
> ideographic scripts the terminus "support this language" is not 
> clearly defined, what does it require for example for Japan, JisX0208, 
> JisX0213, Adobe Japan 1-3, 1-4, 1-5 ..?
> 
> I think there is a lot of work included and for the time being it 
> would be a good first step to introduce only the "preferred or 
> intended " language tag.
> 
> 
> 
> 
> 
> At 05:04 05.01.2013, you wrote:
>> Message from OpenType list:
>> 
>> 
>>> ****** Attachments to this email message have been removed ******
>> 
>> I agree that this kind of info could be extraordinarily helpful... 
>> but I'm wondering if a simple list of language IDs is sufficient?  I 
>> think the problem is more complicated than that, and we may need to 
>> step back a bit and figure out what info is really needed. The 
>> following is a bit more "thinking out loud"...
>> 
>> Broad-spectrum fonts like Times New Roman or Charis SIL highlight 
>> some unique issues:
>> 
>> - They support many hundreds of languages. Enumerating the list for 
>> such fonts will be the first challenge. Moreover, the design of a 
>> data structure to hold the resulting list needs to accommodate 
>> hundreds of entries with reasonable expectations on client searching.
>> 
>> - What if certain OT features have to be enabled for the font to 
>> render language-appropriate shapes?  (IMO the 'locl' feature is 
>> currently insufficient as it depends on OT language tags which are 
>> incomplete for the 6900 languages of the world.)
>> 
>> - The growth (and convergence) of web-font and mobile technologies 
>> has resulted in a growing interest dynamic font subsetting. This is 
>> related to the subject issue because both involve a prior problem: 
>> knowing what characters are needed to support a given language.  I 
>> wonder if we shouldn't be focusing on how to populate and utilize 
>> something like CLDR Exemplar data 
>> <http://cldr.unicode.org/translation/characters#TOC-Exemplar-Characte
>> rs>
>> -- then fonts might not have to explicitly list what languages they 
>> support (except for the problem of language-specific shaping).
>> 
>> Like I said, I think the problem is more complicated....
>> 
>> Bob Hallissy
>> 
>> 
>> On 2013-01-04 at 8:45 Ken Lunde wrote:
>>> Regardless of where this information goes, it is important and
>> useful, because implementations are currently forced to employ 
>> heuristics to arrive at this information, such as 'OS/2' table 
>> settings, Unicode ranges in the 'cmap' table, the language settings 
>> for existing 'name' table strings, and so on. Explicitly stating the 
>> intended language (or languages) of the font resource, or even the 
>> converse, is extraordinarily helpful.
>> 
>> 
>> 
>> 
>>> ****** Attachments to this email message have been removed ******
>> 
>> 
>> 
>> List archive: http://www.indx.co.uk/biglistarchive/
>> 
>> subscribe: opentype-migration-sub at indx.co.uk
>> unsubscribe: opentype-migration-unsub at indx.co.uk
>> messages: opentype-migration-list at indx.co.uk
> 
> 
> 
>> ****** Attachments to this email message have been removed ******
> 
> 
> 
> List archive: http://www.indx.co.uk/biglistarchive/
> 
> subscribe: opentype-migration-sub at indx.co.uk
> unsubscribe: opentype-migration-unsub at indx.co.uk
> messages: opentype-migration-list at indx.co.uk
> 
> 




List archive: http://www.indx.co.uk/biglistarchive/

subscribe: opentype-migration-sub at indx.co.uk
unsubscribe: opentype-migration-unsub at indx.co.uk
messages: opentype-migration-list at indx.co.uk