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

[Levantovsky, Vladimir]

Forwarding the email response from OT list.

-----Original Message-----
From: listmaster at indx.co.uk [mailto:listmaster at indx.co.uk] On Behalf Of Juergen Willrodt 
Sent: Monday, January 07, 2013 3:35 AM
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:


>****** 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-Characters
>>
>-- 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