wineps.drv: Add glyph names for PostScript Format 1 glyphs.

[Nikolay Sivov]

On 01.09.2015 22:05, Erich E. Hoover wrote:
> On Tue, Sep 1, 2015 at 11:57 AM, Nikolay Sivov <bunglehead at gmail.com> wrote:
>> ...
>> get_glyph_name() operates on glyph index, and ttf/otf formats are free to
>> map codepoints to any index, so mapping you implemented will only work in
>> case when currently selected font has 'post' table in Format 1.
>
> Some of the documentation I ran across said that indices 0 through 257
> are reserved for the standard glyphs even in later formats.  However,
> it's entirely possible that the information I found is incorrect.

Looks like freetype for example only provides names if 'post' table is 
present, and for index in [0,257] static strings are used no matter what 
'post' format is.

According to this https://www.microsoft.com/typography/otspec/recom.htm, 
it's required to have first 4 indices fixed to specific chars. 'cmap' 
requirements section talks about format 4 and 12 that should have same 
code to glyph mappings within a given font. Also they mention 'Macintosh 
cmap' (in other words platform == 1/encoding == 0) that strictly follows 
mapping scheme from Type 1 it seems (that you used). So if you don't 
provide this platform/encoding pair you presumably don't have to follow 
this scheme. After reading all this I don't see any explicit documented 
guide for that, my impression is that people are free to map it in any way.

Huw, what's your opinion on all that?

>
>> So if you
>> really need adobe glyph name you have to use unicode-value-to-name lookup
>> based on [1] probably (comes under Apache 2.0 license, no idea if it's
>> usable in Wine). But even that won't always work I think, because we have to
>> support ETO_GLYPH_INDEX case too where you have indices as input.
>> ...
>
> I agree that this is better, but I was unable to find a version of
> this data that's not Apache 2.0 licensed and it is not clear to me
> that we can include Apache 2.0 licensed data.  I'm not even sure why
> there's a license on such a lookup table, but the fact remains that it
> is there.
>
> Best,
> Erich
>