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 Peter Constable 
Sent: Tuesday, January 08, 2013 5:01 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:


Two comments:

- I think the need extends beyond indicating that a CJK font is meant for a particular "locale" (I'll quote that term grudgingly) -- it is far more general than that.

-  I do _not_ think it would be useful to use reserved codepage bits. We've already exhausted the 128 Unicode range bits that, presumably, we're once assumed to be more than anyone will ever need. Since IMO the problem is a much more general one than "this CJK locale", the only way that 27 available bits could useful would be if there were also some dynamic mechanism to tailor what each indicates -- and that would entail some new data structure. If we want to stick with existing data structure mechanisms already in the OT format, then the proposal for a new name ID for this would do exactly that.



Peter


-----Original Message-----
From: listmaster at indx.co.uk [mailto:listmaster at indx.co.uk] On Behalf Of Jelle Bosma
Sent: Monday, January 07, 2013 1:30 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:



Op 5-jan-2013, om 1:11 heeft Sairus Patel het volgende geschreven:

> *If* we wanted to add this to the OS/2, it might look like this:
>
> OS/2 version = 5
> Add following fields:
> ULONG  languages supported string offset (from beginning of OS/2
> table)
> ULONG  languages supported string length
>
> The string could be spec'd as UTF-8 (or UTF-16 BE), comma- separated, 
> etc.


Hi,

I agree that the OS/2 table is the most logical place to add this information to. But why add a new, variable length table, if the existing format seems to be able to store all necessary information already.

It is possible that I am missing something, but after more than 20 years of Unicode the various code-pages must be obsolete for storing actual character set information.  But they hold information helpful to identify language support.

You can make a recommendation: "If you create a font that is specifically designed for one CJK locale only, but not the others, only set the codepage bit applicable for that locale, even if you have the characters for other CJK locales. If you set more than one of the CJK codepages, ensure that you have a localisation feature that makes the appropriate substitutions."

There are 27 codepage bits reserved for ANSI and OEM. Are these ever going to be used for new ANSI and OEM codepages? If we need store additional information about character collections, beyond CJK, that are needed for various locales and for which the Unicode code-pages are too generic: why not use these bits? It is all there already.

Best regards
   Jelle

    Monotype
    De Hovenlaan 205
    7325 VV Apeldoorn, Nederland
     Email jelleb at euronet.nl
    www.monotypefonts.com







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