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.
-- Nicolas
-------------------------------------------------------------------------
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
