matplotlib-devel Mailing List for matplotlib (Page 2)

Hello everyone,
I just committed some accelerator-related updates to the WXAgg 
backend. I have fixed the problem with the way I was calling the 
wxBitmap constructor in _wxagg.src. More importantly, I written 
another set of the agg-to-wx.Bitmap conversion routines that uses the 
new BitmapFromBufferRGBA() function in wxPython 2.8. The blit() 
routine also got a bit faster after I realized it was more efficient 
to just convert the whole buffer and blit part of it instead of 
clipping during conversion.
I have tested these changes with wxPython 2.8.1.1 under OSX 10.4.8. 
My goal is that none of the changes break compatibility with wxPython 
2.4 or 2.6. I'd really appreciate it if someone could test and 
benchmark those versions using `examples/animation_blit_wx.py'.
Ken

"Nicolas Grilly" <nic...@ga...> writes:
> Have you had time to look at my patch regarding the PDF backend? :-)
A bit, and I couldn't quite get it to work. But what the heck, let's
put it in the repository so we can all hack on it. It is quite an
improvement to the backend, and it doesn't seem to break anything that
used to work. (I ran the examples using backend_driver.py on both agg
and pdf.) Your patch (slightly modified) is committed as of svn
revision 3027.
The problem I'm having is that if I set use14corefonts on, I have to
make sure that Helvetica (or whatever) is chosen as the text font.
I used to have the setting
font.sans-serif : Bitstream Vera Sans
because that font works, and some other fonts that mpl finds (on my 
OS X system) don't; but then setting use14corefonts on caused the afm
header parser to be called on Vera.ttf, which it obviously couldn't
make any sense of. I'm not sure I quite understand the Matplotlib font
selection system, though.
Replacing the setting by
font.sans-serif : Helvetica, Bitstream Vera Sans
helps, but it would be nice to put in some sanity checks so that we
don't send the ttf file to the afm parser.
On another note, the dpi setting was used for images. Removing it does
make the code simpler, but then all images will be at a resolution of
72 dpi. Can you be more specific about the problems that the dpi
setting was causing? Anyway, perhaps we should find a better interface
for specifying image resolution for vectorial backends.
Regards,
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hello Jouni,
Have you had time to look at my patch regarding the PDF backend? :-)
Regards,
Nicolas

When using a vectorial backend like PS or PDF, I noticed tick marks
and grid lines are not perfectly aligned.
Here is a little script revealing the problem:
 import os
 from pylab import *
 rc('axes', linewidth=0.5, axisbelow=True)
 rc('xtick', direction='out')
 rc('ytick', direction='out')
 t = arange(0.0, 2.0, 0.01)
 s = sin(2*pi*t)
 plot(t, s, linewidth=1.0)
 title('Tick marks, grid lines and other marks should be aligned')
 xlabel('time (s)')
 ylabel('voltage (mV)')
 grid(True, linestyle='-', color='#d3d3d3')
 axhline(0.5, linewidth=0.5)
 plot([0.5], [0.5], '+')
 plot([1.0], [0.5], marker=0)
 savefig('testchart.eps')
 savefig('testchart.png')
 show()
The attached file testchart-misaligned.eps shows the result with the
PS backend: tick marks and grid lines are not perfectly aligned, which
is bad; but the "+" mark placed in the plot is correctly aligned with
the grid lines, as expected.
In the attached file testchart-misaligned.png, produced with the Agg
backend, this is the opposite: tick marks and grid lines are perfectly
aligned, but the "+" mark is not exactly over the grid lines.
I think this is caused by a workaround used in lines.py, in methods
_draw_tickleft, _draw_tickright, _draw_tickup and _draw_tickdown,
consisting in adding 0.5 to marks coordinates in order to place them
in pixel center. This is good for bitmap backends like Agg, but it's
bad for vectorial backends like PS, PDF and SVG. I propose to remove
this behavior from lines.py and move it in _backend_agg.cpp.
The attached file alignment.patch is a patch implementing this proposition.
The files testchart_aligned.eps and testchart_aligned.png show the
results with the PS and Agg backends after applying the patch:
everything is aligned.
Do you agree to apply this patch, or have I misunderstood something? :-)
Cheers,
-- Nicolas Grilly

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
>

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

On Thursday 15 February 2007 21:41, Nicolas Grilly wrote:
> On 2/14/07, Paul Barrett <peb...@gm...> 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.

I'll be away on vacation fro Feb 16th-Feb23rd, and for the most part
out of email contact. Hold down the fort for me!
JDH

On 2/15/07, Robert Kern <rob...@gm...> wrote:
> On 2/15/07, Keir Mierle <mi...@gm...> wrote:
> > On the DocstringStandard page I have also put a completely re-done docstring
> > for the 'contour' function from matplotlib. I think it is far more readable
> > than the original [3]. JDH and other matplotlibheads, what do you think?
> > Travis, do you find my additions reasonable? Scipy maintainers, would you
> > consider adopting this format (especially if someone helps with the gruntwork)?
>
> It looks like you took the initial proposal rather than the result of
> that discussion. Please see the document that we came up with:
>
> http://svn.scipy.org/svn/numpy/trunk/numpy/doc/HOWTO_DOCUMENT.txt
Ah, I apologize for not checking the dates; I thought the HOWTO_DOCUMENT.txt
was the older proposal.
Nevertheless, I think the issues raised in my proposed version are significant
enough to warrent further discussion; especially for the more demanding needs
of matplotlib.
I would like to re-open this discussion to be sure there is consensus among the
numpy, scipy, and matplotlib folk before I invest signifcant time into
massaging the docstrings into the right form.
I am clearly biased as I invested time and thought into the proposed docstring
format I posted [1], but nevertheless I do not like the style listed in the
HOWTO_DOCUMENT.txt. The different sections have different styles of headings,
i.e. the difference style for :Pamaraters: and Examples, which is not good for
readability. Furthermore, it does not specify enough formatting, for e.g.
keyword arguments with defaults.
For specifics, here are my issues with the current HOWTO:
 * Non-capitalized headers
 Capitalized headers are far more visually obvious when viewed on a text
 terminal (i.e. via function? in IPython)
 * Two different header styles
 The distinction between
 :Parameters:
 and
 Examples
 --------
 seems unnecessary; if this is necessary for reST, could a preprocessing step
 not fix this? The inconsistency appears unprofessional when viewed in a
 terminal.
 * No suggestions on how to handle functions which have multiple invocations,
 i.e. multiple function signatures. I have a proposal for this in [1].
 * Parameters / Returns instead of INPUTS / OUTPUTS. This is no doubt a
 preference, but nevertheless I vastly prefer having INPUTS / OUTPUTS instead
 of Parameters / Returns. I understand that the parameter/return form is more
 common for Python, so I realize this is contentious. Nevertheless, inputs /
 outputs has the clear advantage of being informative to someone who is just
 starting programming and may not realize the meanings of parameters /
 returns; but input/output is absolutely clear even to the non-programmer.
If it comes down to me writing a parser for my proposed format, I will do that.
Keir
[1] http://scipy.org/DocstringStandard

On 2/14/07, Paul Barrett <peb...@gm...> 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

> 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 ...
FreeType 2 documentation states very clearly that character codes are
mapped to glyph indices, not the opposite.
I think the mapping from glyph indices to character codes is useless,
and I've not seen any use case of that in matplotlib.
The page http://www.freetype.org/freetype2/docs/tutorial/step1.html says:
- "A face object contains one or more tables, called charmaps, that
are used to convert character codes to glyph indices."
- "To convert a Unicode character code to a font glyph index, we use
FT_Get_Char_Index, as in "glyph_index = FT_Get_Char_Index( face,
charcode );". This will look the glyph index corresponding to the
given charcode in the charmap that is currently selected for the
face."
The page http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html
says:
- "FT_Get_First_Char: This function is used to return the first
character code in the current charmap of a given face. It also returns
the corresponding glyph index."
- "FT_Get_Next_Char: This function is used to return the next
character code in the current charmap of a given face following the
value 'char_code', as well as the corresponding glyph index."
Thanks,
-- Nicolas

I'd like to help the docstring formats of numpy, scipy. and matplotlib converge
on a high-quality standard (hence the cross-posting). However, before that can
happen all maintainers from all three packages need to agree on a format. In
the interest of speeding things along, I've taken the liberty of extending [1]
the docstring format proposed by Travis on January 10th on the scipy-dev
mailing list [2]. I also volunteer to convert a non-trivial portion of the
numpy, scipy, and matplotlib docstrings. If all goes well on the consensus
front, I'll try to coordinate an IRC docstring sprint or two.
The notable differences from the format Travis posted is that I have
capitalized headers for readability; the other changes are mostly modest, or
additions to handle the more demanding requirements of matplotlib docstrings.
On the DocstringStandard page I have also put a completely re-done docstring
for the 'contour' function from matplotlib. I think it is far more readable
than the original [3]. JDH and other matplotlibheads, what do you think?
Travis, do you find my additions reasonable? Scipy maintainers, would you
consider adopting this format (especially if someone helps with the gruntwork)?
Thanks in advance,
Keir
[1] http://scipy.org/DocstringStandard
[2] http://article.gmane.org/gmane.comp.python.scientific.devel/5572
[3] http://matplotlib.sourceforge.net/matplotlib.pylab.html#-contour
p.s. This is part of my plan to kick off http://scipy.org/PyLab

On 2/14/07, John Hunter <jd...@gm...> wrote:
> On 2/14/07, Paul Barrett <peb...@gm...> wrote:
>
> > I still feel this way, but maybe I should change my tune and let the
> > changes go in.
>
> What do you think about the comments made earlier in this thread:
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?
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.
> > FT2Font.get_charmap() returns a mapping from glyph index to character code.
> > This looks like a very bad design decision to me, because several character
> > codes can correspond to one glyph. For example, in Times New Roman, both 0x32
> > (space) and 0xA0 (nbsp) are mapped to glyph index 3. Of course, the first one
> > gets lost in get_charmap().
>
> 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 ...
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

On 2/14/07, Michiel Jan Laurens de Hoon <md...@c2...> wrote:
> Dear Charles,
>
> I was trying to use your cocoa-agg backend for matplotlib, but it seems
> to have a problem to read Matplotlib.nib. Opening this nib with
> Interface Builder also gives an error. It appears that the problem is
> caused by the file keyedobjects.nib in the Matplotlib.nib folder. If I
> run plutil on keyedobjects.nib, it crashes. The other two files in
> Matplotlib.nib look fine. So I was wondering if it is possible that the
> keyedobjects.nib file included in matplotlib is damaged. If so, do you
> have a valid copy of this file?
>
> Many thanks in advance,
>
> --Michiel de Hoon.
We recently moved the data files, and I think the nib files got
interpreted as text instead of binary files. I grabbed an old copy
from a previous source release and committed them as binary. They
should work now.
- Charlie

On 2/14/07, Paul Barrett <peb...@gm...> wrote:
> I still feel this way, but maybe I should change my tune and let the
> changes go in.
What do you think about the comments made earlier in this thread:
> FT2Font.get_charmap() returns a mapping from glyph index to character code.
> This looks like a very bad design decision to me, because several character
> codes can correspond to one glyph. For example, in Times New Roman, both 0x32
> (space) and 0xA0 (nbsp) are mapped to glyph index 3. Of course, the first one
> gets lost in get_charmap().
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 ...
JDH

John,
I still feel this way, but maybe I should change my tune and let the
changes go in.
 -- Paul
On 2/14/07, John Hunter <jd...@gm...> wrote:
> On 2/14/07, Evgeniy Stepanov <eug...@gm...> wrote:
>
> > I also prefer the first way. Here is the patch. Please re-check at least the
> > changes to mathtext.py, I could miss something. mathtext_demo.py still works,
> > but it obviously does not test all the changes.
>
> Thanks for looking into this -- last time Nicolas brought this up back
> in November, Paul argued that reversing the dictionary "violated the
> principle of least surprise" but clearly you two disagree. If Paul is
> still monitoring this, he can weig in again if he still objects to the
> reversal. You should try tunning examples/backend_driver and looking
> at as many of the PS and PNG outputs as you can to make sure the text
> looks right, and then send on a final patch if any revisions are
> needed and one of us can see to it that it gets incorporated.
>
> JDH
>
> -------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 2/14/07, Evgeniy Stepanov <eug...@gm...> wrote:
> I also prefer the first way. Here is the patch. Please re-check at least the
> changes to mathtext.py, I could miss something. mathtext_demo.py still works,
> but it obviously does not test all the changes.
Thanks for looking into this -- last time Nicolas brought this up back
in November, Paul argued that reversing the dictionary "violated the
principle of least surprise" but clearly you two disagree. If Paul is
still monitoring this, he can weig in again if he still objects to the
reversal. You should try tunning examples/backend_driver and looking
at as many of the PS and PNG outputs as you can to make sure the text
looks right, and then send on a final patch if any revisions are
needed and one of us can see to it that it gets incorporated.
JDH

On Wednesday 14 February 2007 21:53, Nicolas Grilly wrote:
> On 2/14/07, Evgeniy Stepanov <eug...@gm...> wrote:
> > FT2Font.get_charmap() returns a mapping from glyph index to character
> > code. This looks like a very bad design decision to me, because several
> > character codes can correspond to one glyph. For example, in Times New
> > Roman, both 0x32 (space) and 0xA0 (nbsp) are mapped to glyph index 3. Of
> > course, the first one gets lost in get_charmap().
> >
> > I think, get_charmap should be fixed to return mapping from character
> > codes to glyph indices. Alternatively, get_charmap() could be left as it
> > is, and get_rcharmap() added.
>
> I agree with you. I've already posted something about this issue some
> time ago: http://sourceforge.net/mailarchive/message.php?msg_id=37418828
>
> > I'm willing to implement either one. Which do you prefer ?
>
> I think we should prefer the first alternative: I've made a quick grep
> through matplotlib's code and I've observed that each time get_charmap
> is called, the returned dict is never used as is, but immediately
> reversed.
I also prefer the first way. Here is the patch. Please re-check at least the 
changes to mathtext.py, I could miss something. mathtext_demo.py still works, 
but it obviously does not test all the changes.

On 2/14/07, Evgeniy Stepanov <eug...@gm...> wrote:
> FT2Font.get_charmap() returns a mapping from glyph index to character code.
> This looks like a very bad design decision to me, because several character
> codes can correspond to one glyph. For example, in Times New Roman, both 0x32
> (space) and 0xA0 (nbsp) are mapped to glyph index 3. Of course, the first one
> gets lost in get_charmap().
>
> I think, get_charmap should be fixed to return mapping from character codes to
> glyph indices. Alternatively, get_charmap() could be left as it is, and
> get_rcharmap() added.
I agree with you. I've already posted something about this issue some
time ago: http://sourceforge.net/mailarchive/message.php?msg_id=37418828
> I'm willing to implement either one. Which do you prefer ?
I think we should prefer the first alternative: I've made a quick grep
through matplotlib's code and I've observed that each time get_charmap
is called, the returned dict is never used as is, but immediately
reversed.
-- Nicolas Grilly

Sorry, I was too hasty. The patch is wrong, here is the real reason:
FT2Font.get_charmap() returns a mapping from glyph index to character code. 
This looks like a very bad design decision to me, because several character 
codes can correspond to one glyph. For example, in Times New Roman, both 0x32 
(space) and 0xA0 (nbsp) are mapped to glyph index 3. Of course, the first one 
gets lost in get_charmap().
I think, get_charmap should be fixed to return mapping from character codes to 
glyph indices. Alternatively, get_charmap() could be left as it is, and 
get_rcharmap() added.
I'm willing to implement either one. Which do you prefer ?

On 2/14/07, John Hunter <jd...@gm...> wrote:
> Apparently all we have to do is include the README along with the
> licensing terms. You probably should do that in the the same
> directory the fonts live to ensure that they are always distributed
> together. We also have a licenses directory.
In this purpose, I've provided a readme.txt file, located in the same
directory as the AFM files, and containing this text:
"""
 Font Metrics for the 14 PDF Core Fonts
 ======================================
 This directory contains font metrics for the 14 PDF Core Fonts (files with .afm
 extension), downloaded from
http://partners.adobe.com/public/developer/font/index.html.
 This file and the 14 PostScript(R) AFM files it accompanies may be
used, copied,
 and distributed for any purpose and without charge, with or without
modification,
 provided that all copyright notices are retained; that the AFM files are not
 distributed without this file; that all modifications to this file or any of
 the AFM files are prominently noted in the modified file(s); and that this
 paragraph is not modified. Adobe Systems has no responsibility or obligation
 to support the use of the AFM files.
"""
The original file from Adobe just contained the last paragraph; I
added the first one to make clear the files origin.
NG

On 2/14/07, Nicolas Grilly <nic...@ga...> wrote:
> I hope there is no license issue with the AFM files. I'm pretty sure
> I've seen them integrated in some TeX distributions.
Apparently all we have to do is include the README along with the
licensing terms. You probably should do that in the the same
directory the fonts live to ensure that they are always distributed
together. We also have a licenses directory.
JDH

T24gMi8xNC8wNywgSm91bmkgSy4gU2VwcMOkbmVuIDxqa3NAaWtpLmZpPiB3cm90ZToKPiBUaGFu
a3M7IG9uIGZpcnN0IGxvb2sgdGhpcyBzZWVtcyByZWFsbHkgbmljZSEgU28gZmFyIEkgaGF2ZSBv
bmUKPiByZXF1ZXN0IHRvIHlvdSBhbmQgb25lIHRvIEpvaG46CgpZb3UncmUgd2VsY29tZTsgSSdt
IGhhcHB5IHRvIGNvbnRyaWJ1dGUgdG8gbWF0cGxvdGxpYiB3aGVuIEkgY2FuISA6LSkKCj4gTmlj
b2xhczogd291bGQgaXQgYmUgZWFzeSBmb3IgeW91IHRvIHN0cmlwIHRoZSBeTSAoY2FycmlhZ2Ut
cmV0dXJuKQo+IGNoYXJhY3RlcnMgZnJvbSB5b3VyIGZpbGVzIGFuZCB0aGVuIHJlLXJ1biBkaWZm
PyBJIHNlZSBpbiB5b3VyIHBhdGNoCj4gc2V2ZXJhbCBwYXJ0cyB3aGVyZSB0aGUgb25seSBjaGFu
Z2Ugc2VlbXMgdG8gYmUgYW4gYWRkaXRpb24gb2YgXk0gYXQKPiB0aGUgZW5kIG9mIGVhY2ggbGlu
ZSwgYnV0IHRoZXJlIGNvdWxkIGJlIHNpZ25pZmljYW50IGNoYW5nZXMgaGlkZGVuCj4gd2l0aGlu
IHRoZXNlIHBhcnRzLiAoUGVyaGFwcyBqdXN0IGdpdmUgdGhlIC1iIG9wdGlvbiB0byBkaWZmPyBU
aG91Z2gKPiB0aGF0IG1pZ2h0IGJhY2tmaXJlIGlmIHNvbWUgb3RoZXIgd2hpdGVzcGFjZSBjaGFu
Z2VzIGFyZSBzaWduaWZpY2FudCwKPiBlLmcuIGlmIHlvdSBoYXZlIGNoYW5nZWQgdGhlIGluZGVu
dGF0aW9uIG9mIHNvbWUgY29kZSBibG9ja3MuKQoKT2suIEkndmUgcmVtb3ZlZCB0aGUgY2Fycmlh
Z2UtcmV0dXJuIGNoYXJhY3RlcnMgYW5kIGFkZGVkIHByb3BlcnR5CnN2bjplb2wtc3R5bGUgPSBu
YXRpdmUgdG8gYmFja2VuZC5wZGYuIE5vdyB0aGUgcGF0Y2ggbG9va3MgcmlnaHQgKHNlZQp0aGUg
YXR0YWNoZWQgZmlsZSkuCgpJIGhvcGUgdGhlcmUgaXMgbm8gbGljZW5zZSBpc3N1ZSB3aXRoIHRo
ZSBBRk0gZmlsZXMuIEknbSBwcmV0dHkgc3VyZQpJJ3ZlIHNlZW4gdGhlbSBpbnRlZ3JhdGVkIGlu
IHNvbWUgVGVYIGRpc3RyaWJ1dGlvbnMuCgotLSBOaWNvbGFzIEdyaWxseQo=