Re: [matplotlib-devel] [PATCH] don't print undefined glyphs in ps backend

[Paul B. <peb...@gm...>]

That's fine with me.

 -- Paul

On 2/16/07, Edin Salkovic <edi...@gm...> wrote:
> On 2/14/07, Paul Barrett <peb...@gm...> 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
>