+void get_glyph_name(HDC hdc, UINT flags, WORD index, char *name) {
- /* FIXME */
- BOOL bIsGlyphIndex = ((flags & ETO_GLYPH_INDEX) == 0);
- if (bIsGlyphIndex && index < 258)
This is essentially the same as it was on try 1. I still think we shouldn't rely on glyph indices mapped to some specific code range, I don't see any documentation that says it should be mapped like that.
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.
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]).
Huw.
On Thu, Sep 3, 2015 at 1:37 AM, Huw Davies huw@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.
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.
Best, Erich
On 03.09.2015 19:36, Erich E. Hoover wrote:
On Thu, Sep 3, 2015 at 1:37 AM, Huw Davies huw@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);elseWARN("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);elseFIXME("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
On Thu, Sep 3, 2015 at 11:09 AM, Nikolay Sivov bunglehead@gmail.com wrote:
On 03.09.2015 19:36, Erich E. Hoover wrote:
...
Format 1 case looks fine, though I think it's better to reuse existing tables if possible for get_standard_glyph_name().
It looks like the existing tables are not in the right order, but I can use the GN_<name> values to make the table.
- else if(post_header->format == MAKELONG(0, 2))
- {
if(index < 258)get_standard_glyph_name(index, name);elseFIXME("PostScript Format 2 custom glyph names are currentlyunsupported.\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.
The index we are passed is the glyphNameIndex entry value, so there's no need to go through the table for those indices. For indices greater than 257 a "patch 2" would allow you to get the glyph name by finding the appropriate string in the table. I can happily prepare such a patch.
- else
FIXME("Only standard PostScript Format 1 glyph names arecurrently 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.
Will do.
Best, Erich
On 03.09.2015 21:04, Erich E. Hoover wrote:
On 03.09.2015 19:36, Erich E. Hoover wrote:
...
Format 1 case looks fine, though I think it's better to reuse existing tables if possible for get_standard_glyph_name().
It looks like the existing tables are not in the right order, but I can use the GN_<name> values to make the table.
Right, this way we won't need to duplicate strings at least.
The index we are passed is the glyphNameIndex entry value, so there's no need to go through the table for those indices. For indices greater than 257 a "patch 2" would allow you to get the glyph name by finding the appropriate string in the table. I can happily prepare such a patch.
How so? As I'm reading docs you always have to use glyph index with Format 2 table and only if glyphNameIndex[glyph_index] is <= 257 you should use this glyphNameIndex[glyph_index] value as index value in Format 1. "patch 2" can wait of course.
Also Apple docs say that Format 2.5 and Format 4 exist, so probably we can just have a single fixme for all formats we don't support.
Based on your feedback, closer reading of the spec, and testing I've attached a proposed patch series. Unfortunately, I cannot test the last patch since OrCAD does not appear to allow me to enter characters outside the standard list. If there's something that you can test the last patch with then that would be greatly appreciated.
Best, Erich
On 3 Sep 2015, at 23:44, Erich E. Hoover wrote:
Based on your feedback, closer reading of the spec, and testing I've attached a proposed patch series. Unfortunately, I cannot test the last patch since OrCAD does not appear to allow me to enter characters outside the standard list. If there's something that you can test the last patch with then that would be greatly appreciated.
You can test the 'custom' glyph names by starting notepad, selecting Tahoma and typing a Euro sign for example. And no, it doesn't work. The length of the pascal strings is stored as a BYTE not a USHORT.
Also, you need to add some checks that you don't read past for end of the POST table and that you don't copy more than MAX_G_NAME chars into the provided name buffer (although this should perhaps be changed to a dynamic buffer).
Huw.
On Fri, Sep 4, 2015 at 3:29 AM, Huw Davies huw@codeweavers.com wrote:
... You can test the 'custom' glyph names by starting notepad, selecting Tahoma and typing a Euro sign for example. And no, it doesn't work. The length of the pascal strings is stored as a BYTE not a USHORT.
Sorry I didn't think of that on my own, I'll go ahead and fix and test that.
Also, you need to add some checks that you don't read past for end of the POST table and that you don't copy more than MAX_G_NAME chars into the provided name buffer (although this should perhaps be changed to a dynamic buffer).
I'll adjust the code to truncate to MAX_G_NAME characters, since (at least older versions) of the spec says that 31 characters is the max I don't think it makes sense to make a dynamic buffer: http://partners.adobe.com/public/developer/opentype/index_glyph2.html
Best, Erich
-
Erich E. Hoover -
Huw Davies -
Nikolay Sivov