New work on 3rd edition of the OFF (AHG kick-off) - name table

[bobh528]

(sorry -- previous post seems to have gone astray...)
On 2012-07-27 at 15:06 Levantovsky,       Vladimir wrote:
I would like to ask you         to review the first draft text
Thanks for getting this process going.

I have some questions about the spec for the name table.

1) In section 5.2.6.3 Name IDs, below the table of name IDs, is a    
Note in which the text:     All 'name' table strings for platform ID 3
(Windows platform) must be in Unicode, using the UTF-16 encoding      
form.  The character set encding for 'name' table strings with      
platform ID 0 (Macintosh) is determined by the encoding ID.     has been
replaced with:
Note that OS/2 and Windows both require that       all name strings be
defined in Unicode. Thus all 'name' table       strings for platform ID
= 3 (Windows) will require two bytes per       character. Macintosh
fonts require single byte strings.
This appears to be a regression to the text from MS spec 1.6 -- is    
that intended?  If so, the "two bytes per character" phrase needs to    
be updated to modern language.

But in either case, a key question is whether SMP characters (coded    
using surrogate pairs) are permitted or not. If they are, then the    
correct term to use is "UTF-16". If they are not, then "UTF-16" is not
the correct term -- I think the correct term would then be "UCS-2".

2) Section 5.2.6.2 5.2.6.2 Platform IDs, Platform-specific      
encoding IDs and Language IDs currently includes this table:

Windows platform-specific               encoding IDs (platform ID= 3)

Platform                   ID

Encoding                   ID

Description

3

0

Symbol

3

1

Unicode                   BMP (UCS-2)

3

2

ShiftJIS

3

3

PRC

3

4

Big5

3

5

Wansung

3

6

Johab

3

7

Reserved

3

8

Reserved

3

9

Reserved

3

10

Unicode                   UCS-4

What does the third column of this table mean? In the context, it    
seems to be saying that if I want a name string with SMP characters    
in it, then I can use 3/10 encoding and encode the string in UCS-4.     
Is that what it is really saying?  If this is true, then it goes    
counter to either of the quotes in my question 1 above (about     UTF-16
or 2-byte characters).

Bob Hallissy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20120807/a7750645/attachment.html>