On Thursday 15 February 2007 21:41, Nicolas Grilly wrote: > On 2/14/07, Paul Barrett <[EMAIL PROTECTED]> wrote: > > My first reply: > > > > I suggest that this patch not be applied, since this was the intended > > behavior when the font manager was implemented. The standard behavior > > for indicating a missing character is to print a square. In addition, > > if a space is printed, how will you know when the formatting is > > correct or not. The unanticipated space could mean font is missing > > that character, or the layout manager has a bug? > > I agree with that. The character name .notdef exists for that purpose > and should be represented by a square or a question mark or something > else, depending on the viewing application. Therefore, the character > name .notdef should not be ignored or replaced by a space. > > > and second reply: > > > > If my memory serves 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. > > Matplotlib's method get_charmap is a wrapper around FreeType's > functions FT_Get_First_Char and FT_Get_Next_Char. These functions are > designed to map character codes to glyph indices, nothing else. But > our method get_charmap does the opposite, which seems strange. > > > 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. > > To my knowledge, there is no "reverse mapping" in FreeType. There is > only one mapping: character code -> glyph index. > > John wrote: > > > I don't remember why we did it this way originally, or if was you or I > > > who did it, but if it is correct that the mapping is sometimes many > > > codes point to one one glyph index, but there each glyph index must > > > point to a single character code (the latter must be correct, right?) > > > then reversing it seems to be the right course. But it's been a long > > > time since I delved into freetype internals ... > > 1 character code maps to exactly 1 glyph index. I think the opposite > assumpation, i.e. 1 glyph index maps to exactly 1 character code, is > incorrect. > > > 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. > > Conclusion: > I think we should change the following line in ft2font.cpp from: > charmap[Py::Int((int) index)] = Py::Long((long) code); > to: > charmap[Py::Long((long) code)] = Py::Int((int) index); > as proposed by Evgeniy. > > This will simplify the few lines of code using it in .py files.
I agree with what you said, I've also never heard of glyph index -> character code mapping. I've checked all ps and png outputs from examples/, everything seems ok. ------------------------------------------------------------------------- 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
