On 2/14/07, Paul Barrett <[EMAIL PROTECTED]> wrote: > and second reply: > > If my memory ser ves me correctly - or if the implementation has > changed over the past few years - get_charmap() is a wrapper on the > FreeType method. FreeType had no reverse mapping and creating one may > have caused problems later. > > I prefer the second alternative. If FreeType now has a reverse > mapping, then by all means create a wrapper for it. If not, then you > will need to take some care that get_rcharmap is reasonably future > proof, so that it does cause maintenance problem later on. >
(...) > I think I did it. At the time the reverse mapping seemed the best > approach, since this ultimately is what the code demanded. (I guess > my memory has failed me!) We also did not have any examples of the > many to one mapping. As you state, this has now changed and the > latter must be correct. This now explains the FreeType implementation. > > -- Paul > I used the wayback machine to search the FreeType docs. See: http://web.archive.org/web/19990302062419/www.freetype.org/docs/user.txt In 1999 (FreeType 1) you had to use the same approach as today - convert character code to glyph index, not vice versa. From the above file: === (...) g. Load the glyph: The glyph loader is easily queried through TT_Load_Glyph(). This API function takes several arguments: o An instance handle to specify at which point size and resolution the loaded glyph should be scaled and grid-fitted. o A glyph container, used to hold the glyph's data in memory. Note that the instance and the glyph must relate to the _same_ font file. An error would be produced immediately otherwise. o A glyph index, used to reference the glyph within the font file. This index is not a platform specific character code, and a character's glyph index may vary from one font to another. To compute glyph indexes from character codes, use the TT_CharMap handle created in section (f.) with TT_Char_Index(). We strongly recommend using the Unicode charmap whenever possible. (...) === >From the FAQ (same year): === 25. Does FreeType support "foreign languages"? Short Answer: YES, it does! From a TrueType font file point of view, there are several parts to the file, one of them being the 'glyphs', i.e. picture representation of the symbols. Another part is the mapping table, also called "charMap". For example, glyph #1 could be letter "A", and glyph #2 could be letter "Z". Glyphs can be stored in any order in a font file. The mapping tables contains at least one char-map entry. For example, you could have an ASCII-map that maps 0x41 to glyph #1, and 0x5A to glyph #2, etc. FreeType provides a "charMap" object class to access and use this information easily. There are several character encodings recognized and defined by the TrueType specification, like Latin-1, Unicode, Apple Scripts, WGL, etc., but a font file might only contain one or two of them. When using a more 'exotic' character encoding, like EBCDIC (this is IBM mainframe stuff!), you would need to translate it to one of the available formats (or to add a charmap table to the font). Cf. section 8. === >From the above it's clear that FreeType *never* explicitly supported the glyph->char mapping, but exactly the opposite. In conclusion, I agree with Nicolas' proposition to change get_charmap to do what it *should* do, map chars to glyph indexes. If others agree, I could try to make the changes to SVN this weekend. Best, Edin ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
