That's fine with me. -- Paul
On 2/16/07, Edin Salkovic <[EMAIL PROTECTED]> wrote: > 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
