Aw: Re: Re: Native TTF name sometimes contains crap

[virtual_worlds]

OK, so let's go through the font: when I decode it with ftdump, I get the 
following entires for name and family:

   font family (ID 1) [Microsoft] (language=0x0804):
      "\U+009E\U+004F"
   full name (ID 4) [Microsoft] (language=0x0804):
      "\U+009E\U+004F"

When I read the related data via the freetype-functions, I get back

string=žÑOSýýýýØ8hW
string_len=4

...means the žÑOS-part of the string is valid. But this in no case decodes to 
0x9E 0x00 0x4F 0x00!

> Gesendet: Donnerstag, 02. September 2021 um 15:21 Uhr
> Von: "Werner LEMBERG" <wl@gnu.org>
> An: virtual_worlds@gmx.de
> Cc: freetype@nongnu.org
> Betreff: Re: Aw: Re: Native TTF name sometimes contains crap
>
> > I _only_ make use of data where the encode-ID is set to > 
> > TT_MS_ID_UNICODE_CS. From this I would assume, all data in related > 
> > "string" member come with the same encoding and therefore have to be > 
> > used/decoded in the same way. Is this correct? In theory, this is correct. 
> > However, ... > But what I notice, is that this is true for all Russian 
> > fonts I have > and for about 50% of the Chinese fonts. But when decoding 
> > the > "string" data of the remaining 50% Chinese fonts (which also have > 
> > the encode-ID TT_MS_ID_UNICODE_CS), I get the mentioned crap. So > this 
> > seems like there is any other property one has to check when > decoding the 
> > names? ... some old fonts (and I guess you have only problems with old 
> > fonts) don't follow those rules. In other words, they are buggy. This might 
> > be due to bad font generators, or intentionally faking entries to be 
> > compatible with old, buggy software, etc., etc. I suggest that you analyze 
> > the 'name' tables of the problematic fonts with the `ttx` disassembler from 
> > the 'fonttools' bundle. If ttx produces correct results while you get 
> > incorrect results with FreeType, please give more details. Werner