wineps.drv: Add glyph names for PostScript Format 1 glyphs (try 2).

[Nikolay Sivov]

On 03.09.2015 19:36, Erich E. Hoover wrote:
> On Thu, Sep 3, 2015 at 1:37 AM, Huw Davies <huw at codeweavers.com> wrote:
>> On Thu, Sep 03, 2015 at 06:59:56AM +0300, Nikolay Sivov wrote:
>>> I think what we want is to map from WCHAR string to such glyph names
>>> directly, and that's why ETO_GLYPH_INDEX case is important - if you
>>> get index array initially you fallback to generic glyph names, if
>>> you got string then for codepoints that have defined glyphs in your
>>> names array you use those, for the rest of codepoints fallback again
>>> to generic name. This way we could also extend this lookup when it's
>>> decided how to deal with licensed glyph list data.
>>
>> Note that we already have many of the glyph names in
>> PSDRV_AGLbyUV[] and friends (see wineps.drv/data/agl.[ch]).
>>
>
> Ok, I've done some more research on this and it looks like what we
> should do is pull up the 'post' table and use the standard glyph names
> if the table is in format 1 or 2 (and index is < 258).  If the table
> is in format 2 there's also the possibility of custom names in
> addition to the standard names.  In later formats the layout of the
> table changes somewhat.

I think we don't have to always depend on particular 'post', because we 
generate new font essentially from selected font data, so it might be 
preferable to use predictable names from tables Huw mentioned.

Font 'post' data could still be useful in case of ETO_GLYPH_INDEX when 
we don't WCHAR string, in this case you can indeed do 'post' name lookup 
so we don't have to make assumptions about particular index layout.

>
> Based on this information I've attached a version of the patch that
> checks the format and returns the standard glyphs if the format is
> "correct".  I'm not sure if ETO_GLYPH_INDEX is relevant to this, as it
> appears that the glyph indices are always in terms of the "mac"
> ordering.  Do you have an application that generates an example of
> this?  I also found a draft version of ISO/IEC CD 14496-22 that says
> that Format 2 is required for fonts used on Windows, though I think
> it's in our best interest to support all the formats our users care
> about.
>

Regarding patch itself:

> +    if(post_header->format == MAKELONG(0, 1))
> +    {
> +        if(index < 258)
> +            get_standard_glyph_name(index, name);
> +        else
> +            WARN("Font uses PostScript Format 1, but non-standard glyph (%d) requested.\n", index);
> +    }

Format 1 case looks fine, though I think it's better to reuse existing 
tables if possible for get_standard_glyph_name().

> +    else if(post_header->format == MAKELONG(0, 2))
> +    {
> +        if(index < 258)
> +            get_standard_glyph_name(index, name);
> +        else
> +            FIXME("PostScript Format 2 custom glyph names are currently unsupported.\n");
> +    }

Format 2 case looks wrong, according to specs you need to use 
glyphNameIndex entry value, check it against [0,257] range and if it's 
in you can use standard name list.

> +    else
> +        FIXME("Only standard PostScript Format 1 glyph names are currently supported.\n");

I think it's better to make explicit message for Format 3, as it's 
specified and could be used by some. And after it generic fixme with 
unrecognized format value printed in a message.

> Best,
> Erich
>