[ft-devel] non-ascii in String INDEX of CFF opentype table

[Hin-Tak Leung]

(removed a few of the SVG related Cc's from previous)

Here is another comment for discussion and possible inclusion to addendum to 
the opentype spec about CFF, after testing the new CFF processing machinery 
inside the Microsoft Font Validator against about 1600 CFF opentype fonts in my 
hard disk - all of fedora linux + mac os 10.9 + win 7 plus misc stash.

I found 5 bunch of fonts using non-ascii in the String INDEX. Since the CFF 
specs predates unicode, assumption about non-ascii being interpreted in utf8 
encoding seems presumptuous; also seeing as this is part of the postscript 
technology, non-ascii string should be encoded the postscript way I.e. <hex> .

Anyway, the 5 are Adobe's Arno* fonts, mozilla's fira* fonts, and two groups 
from TexLive, and a 5th. The non-ascii are used only for 'copyright' and 
'notice' part of the Top DICT on closer look. Adobe uses Latin1 encoding, while 
the others use utf8. I think I 'll add a warning that other than those two 
(which obviously should and can contain anything including Klingon), most other 
use of non-ascii (most of the String index seems to be glyph names, a lot of 
unixxxxx) in the String INDEX should be postscript hexstring encoded.
Any comments?

--------------------------------------------
On Tue, 26/1/16, Hin-Tak Leung <address@hidden> wrote:

... what next - from the newest and latest SVG table, I have
 turned to having a look at the oldest unsupported one - CFF.
 Microsoft did not implement any CFF checking at all, mostly
 I guess due to their (past?) limitation of the MS renderer's
 capability. Since we gained a Freetype-based backend in
 autumn, just before it went MIT, that limitation is no
 longer the case. I have already added CFF table processing
 to extract the Postscript dictionaries and data structures,
 and there is also the beginning of a new tool called
 "CFFInfo" - a complete lack of imagination in naming - which
 allows a power user (currently that means just me...) to
 manually examines the Postscript dictionaries and data
 structures in the CFF table of an open type font, just like
 the DSIGInfo and SVGInfo tools. When CFFInfo matures, I'll
 push it out. Actually checking Postscript dictionaries
 within the font validator, in an automated manner, seems a
 rather large and daunting task. Obviously Adobe would be an
 interesting party to approach to see if they can commission
 the work, so please forward if appropriate.