matplotlib-devel Mailing List for matplotlib

For the record,
I just committed the changes to SVN and did a bit of testing.
ft2font.get_charmap now returns a mapping from charcodes to glyph
indices.
Cheers,
Edin
On 2/17/07, Nicolas Grilly <nic...@ga...> wrote:
> On 2/17/07, Paul Barrett <peb...@gm...> wrote:
> > That's fine with me.
> >
> > On 2/16/07, Edin Salkovic <edi...@gm...> wrote:
> > > 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.
>
> Thanks Paul, Edin and Evgeniy.
>
> -- Nicolas
>

On 2/17/07, Paul Barrett <peb...@gm...> wrote:
> That's fine with me.
>
> On 2/16/07, Edin Salkovic <edi...@gm...> wrote:
> > 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.
Thanks Paul, Edin and Evgeniy.
-- Nicolas

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
>