Limit the 1.0.0 "name" table records to a necessary minimum?

[Adam Twardoch (List)]

Dear list members,

a FontLab customer recently contacted us with an issue, and based on the 
interaction with them I realized something:

Currently, most font generation application put almost the same sets of 
records into the "name" table for both the 1.0.0 ("Mac Roman English") 
and the 3.1.1033 ("Windows U.S. English") sets. However, my overall 
impression is that modern Mac OS X systems (and most other systems) 
parse the 3.1.1033 records before even looking at the 1.0.0 records.

There certainly may be a good reason to keep SOME name records in the 
1.0.0 branch for backwards-compatibility reasons. But I think we should 
discuss a recommendation (which we at FontLab would be happy to 
implement) which limits the set of the 1.0.0 records which are necessary 
to be there.

a) I can easily think that these IDs should certainly be in the 1.0.0 
branch: 1, 2, 4, 6.

b) Optionally, these IDs could also be included in the 1.0.0 branch: 0, 
3, 5, 7, 8, 16, 17, 20 -- and perhaps 18.

c) But perhaps we could decide to recommend that these IDs are omitted 
from the 1.0.0 branch: 9, 11, 12, 14, 19, 21, 22.

d) And MOST CERTAINLY, I'd like to see an agreement that we recommend 
omitting these: 10, 13.

The IDs 10 ("Description") and 13 ("License description") tend to be the 
largest. Some font vendors put very large texts in there -- the customer 
who contacted us had their entire 19 KB EULA text in the ID 13.

Since the 1.0.0 strings are stored using 8-bit encoding (Mac Roman) and 
3.1.1033 strings are stored using 16-bit encoding (UTF-16), it's not 
possible to store the string once and point to the same offset from two 
different records. So the strings are de facto duplicated, which 
contributes to significant bloating of the file sizes.

Opinions?

Best,
Adam

-- 

May success attend your efforts,
-- Adam Twardoch
(Remove "list." from e-mail address to contact me directly.)