On 01.09.2015 19:21, Erich E. Hoover wrote:
/* These PostScript Format 1 glyph names are stored by glyph index, do not reorder them. */const char *glyph_table[] = {".notdef",".null","nonmarkingreturn","space",
I don't think it can work like that for anything except .notdef. If I understand it correctly one of wineps.drv tasks is to generate Type1/Type42 font description from currently selected font, including converting outline data and metrics to proper format, and that selected font could be anything scalable.
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. 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.
[1] https://github.com/adobe-type-tools/agl-aglfn/blob/master/glyphlist.txt
On Tue, Sep 1, 2015 at 11:57 AM, Nikolay Sivov bunglehead@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.
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
On 01.09.2015 22:05, Erich E. Hoover wrote:
On Tue, Sep 1, 2015 at 11:57 AM, Nikolay Sivov bunglehead@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
On 1 Sep 2015, at 21:38, Nikolay Sivov wrote:
On 01.09.2015 22:05, Erich E. Hoover wrote:
On Tue, Sep 1, 2015 at 11:57 AM, Nikolay Sivov bunglehead@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?
Yes, we can only really do this for for non-ETO_GLYPH_INDEX case.
Huw.
-
Erich E. Hoover -
Huw Davies -
Nikolay Sivov