matplotlib-devel Mailing List for matplotlib (Page 2)

Can anyone reproduce this error? I am using up-to-date svn matplotlib, with 
either numpy or numeric:

plot([1,2])

---------------------------------------------------------------------------
exceptions.TypeError                                 Traceback (most recent 
call last)

/home/darren/<ipython console>

/usr/lib64/python2.4/site-packages/matplotlib/pylab.py in plot(*args, 
**kwargs)
   3087         hold(h)
   3088     try:
-> 3089         ret =  gca().plot(*args, **kwargs)
   3090         draw_if_interactive()
   3091     except:

/usr/lib64/python2.4/site-packages/matplotlib/axes.py in plot(self, *args, 
**kwargs)
   2137         lines = [line for line in lines] # consume the generator
   2138
-> 2139         self.autoscale_view(scalex=scalex, scaley=scaley)
   2140         return lines
   2141

/usr/lib64/python2.4/site-packages/matplotlib/axes.py in autoscale_view(self, 
tight, scalex, scaley)
    991             if xl[1] < xl[0]:
    992                 XL = XL[::-1]
--> 993             self.set_xlim(XL)
    994         if scaley:
    995             yl = self.get_ylim()

/usr/lib64/python2.4/site-packages/matplotlib/axes.py in set_xlim(self, xmin, 
xmax, emit)
   1233             xmax += 1e-38
   1234
-> 1235         self.viewLim.intervalx().set_bounds(xmin, xmax)
   1236         if emit: self._send_xlim_event()
   1237         return xmin, xmax

TypeError: only length-1 arrays can be converted to Python scalars.

Darren

Thank you John for your answer.

You're right: efficiency is a non-issue. I shouldn't have mentioned it.

On 11/5/06, John Hunter <jdh...@ac...> wrote:
>     Nicolas> But in this function, I don't like the idea to try an
>     Nicolas> operation on a string, and wait for an exception in order
>     Nicolas> to know if we really have a string or not. It's not very
>     Nicolas> efficient, nor very beautiful.
>
>     Nicolas> I guess initial developer did that to keep compatibility
>     Nicolas> with old Python versions.
>
> I did it because it is general, elegant, and efficiency doesn't matter
> here (any string operation is insignificant to the work we do making a
> figure).  What if a user writes their own string class, eg someone
> wants a mutable string, or a lower case string, or any number of
> custom string objects, and these aren't covered by the types module?
>
> We make heavy use of duck typing in matplotlib, and it hasn't caused
> us any problems I know of.
>
> JDH

Hi,

I have submitted a bug report
1591708 pylab.axis('equal') scales wrong axis
In the attached script axis('eqaul') shrink x instead of expanding y with 
the result that no
datapoints are seen.

I have also submitted a simple patch
1591716 Expand y if data don't fit into x_lim
It would be great if someone could take look.
It fixes the test case, but I'm not sure if it is the right way to do it.

regards
Ulf Larsson

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

May I ask again for hints ???

> However, there is problem with the asterisk symbols I'm not sure how to
> solve, and I ask for your advice!!! As you can see in the attached
> example output, custom_symbol2a.png, the length of the arms of the
> asterisk-symbol appear different even so have numerically all the same
> length. An asterisk-symbol is drawn by connecting the origin (0,0) with
> one end of an arm, e.g. (1,0) and again back to the origin (0,0), then
> to the next end of an arm and so on.
> - Is there a better way to do this?
> - And is there a way to avoid output artefacts like those in the example
> attached ?
> 
> The artefact seems to be present for a pixel-devices only (like .png)
> but not for a vector-drawing-device like eps :-( So it seems that it is
> an issue of rounding to int ???

The basic question is: is there a way to ensure that a line is drawn
with a fixed length irrespective of location and direction of the line.

I really would like to add more features (line-style symbols for
scatter), but the actual problem makes the patch embryonic ...

Manuel

Hi Paul,

On 11/6/06, Paul Barrett <peb...@gm...> wrote:
> The ft2font module provides a Python interface to the FT2Font C API.
> get_charmap is one of the methods in this API as is set_charmap.  A
> font can have multiple character maps.

Ok.

> get_charmap() returns the default one.  Others can be specified
> by providing an argument to get_charmap(). To add a new charmap
> to the font, you must first find out what charmaps it contains,
> so get_charmap is needed for this.

I disagree. Method FT2Font::get_charmap doesn't return the list of
available character maps; it returns a dictionary mapping glyph
indices to character codes in the *current character map*.

You wrote "other character maps can be specified by providing an
argument to get_charmap", but method FT2Font::get_charmap doesn't
accept any parameter (I looked at line 1208 of file ft2font.cpp).

> In addition, changing this method to return the reverse mapping would
> violate the rule of least surprise.

Yes, but in my opinion, this is the current solution that violates
"the rule of least surprise".

Method FT2Font::get_charmap calls two important methods of FreeType:
FT_Get_First_Char and FT_Get_Next_Char. These two methods are used to
parse all character codes from first to last in the current character
map, and returning corresponding glyphs.

You can read those methods description and an example at this URL:
http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Get_First_Char

Reading this example, it seems apparent the "least surprising
solution" is a mapping from character codes to glyph indices, doesn't
it?

> Note that creating the reverse dict is easy in Python.

Yep, it's why we love programming in Python!

>>>>> "Nicolas" == Nicolas Grilly <nic...@ga...> writes:

    Nicolas> It proves it's possible to achieve it in pure Python,
    Nicolas> without requiring fonttools. And it can be a good source
    Nicolas> of inspiration.  Perhaps the licence is compatible with
    Nicolas> matplotlib's one?

it is BSD which is compatible-- it appears that ttfonts pull in a bit
more or report lab, but this might be worth looking into.  I don't
know if and how the techniques cold be generalized to PS embedding.  I
think the problem Paul ran into (who did the PS embedding work) was
not getting the relevant info for specific glyphs, but how to write
the postscript to encode the subset.

JDH

On 11/5/06, Jouni K Seppanen <jk...@ik...> wrote:
> Does anyone here have experience with subsetting TrueType fonts (or
> Type 1 or OpenType, for that matter)? One pretty frequent complaint is
> that the eps files produced by matplotlib can be huge because they
> include the full font. Nowadays some popular fonts include characters
> for Greek, Cyrillic, Hebrew, Arabic, and possibly even Chinese,
> Japanese, and Korean, so a font can be several megabytes large.

I do not have experience in subsetting TrueType fonts, but I read the
pure Python code dedicated to this task in ReportLab:

    http://www.reportlab.co.uk/svn/public/reportlab/trunk/reportlab/pdfbase/ttfonts.py

It proves it's possible to achieve it in pure Python, without
requiring fonttools. And it can be a good source of inspiration.
Perhaps the licence is compatible with matplotlib's one?

> "Nicolas Grilly" <nic...@ga...> writes:
> > I've just some issues with:
> > - text alignment (I fixed it on my working copy of matplotlib);
>
> Great! Is there a patch somewhere?

Yes, I'm preparing one and I'll submit it in the next few days.

On 11/5/06, Nicolas Grilly <nic...@ga...> wrote:
> In module ft2font, the method FT2Font.get_charmap returns a dict that
> maps glyph indices to char codes.
>
> I don't understand the purpose of this mapping, and why the method
> doesn't return the reverse mapping, i.e. char codes mapped to glyph
> indices.

The ft2font module provides a Python interface to the FT2Font C API.
get_charmap is one of the methods in this API as is set_charmap.  A
font can have multiple character maps.  get_charmap() returns the
default one.  Others can be specified by providing an argument to
get_charmap(). To add a new charmap to the font, you must first find
out what charmaps it contains, so get_charmap is needed for this.

In addition, changing this method to return the reverse mapping would
violate the rule of least surprise. Note that creating the reverse
dict is easy in Python.

 -- Paul

> For example, in backend_ps.py, line 754, the charmap is immediately
> reversed, just after being loaded:
>
>         cmap = font.get_charmap()
>         glyphd = reverse_dict(cmap)
>
> Thanks,
>
> Nicolas Grilly
>

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:

    Jouni> OK. Was it just that you don't want to require mpl users to
    Jouni> install fonttools, or were there other problems with it?

One problem was that it was large compared to mpl at the time, and mpl
was pure python.  So it complicated the distribution to have a large
piece of extension code that wasn't quite as ubiquitous as numpy.  Of
course now mpl is much larger and has it's own extension code headaches.

    Jouni> Does anyone here have experience with subsetting TrueType
    Jouni> fonts (or Type 1 or OpenType, for that matter)? One pretty
    Jouni> frequent complaint is that the eps files produced by
    Jouni> matplotlib can be huge because they include the full
    Jouni> font. Nowadays some popular fonts include characters for
    Jouni> Greek, Cyrillic, Hebrew, Arabic, and possibly even Chinese,
    Jouni> Japanese, and Korean, so a font can be several megabytes
    Jouni> large.

I would love for someone how to figure out how to extract and embed
just the needed glyphs rather than dump the whole file in.  I'm 99%
sure this is possible, it just takes some dedication.

JDH

John Hunter <jdh...@ac...> writes:

> FYI, matplotlib used to depend on fonttools, but we found the
> dependency too onerous and booted it and wrote our own, lighter
> freetype support.  So I would be reluctant to reintroduce this
> dependency.

OK. Was it just that you don't want to require mpl users to install
fonttools, or were there other problems with it?

Does anyone here have experience with subsetting TrueType fonts (or
Type 1 or OpenType, for that matter)? One pretty frequent complaint is
that the eps files produced by matplotlib can be huge because they
include the full font. Nowadays some popular fonts include characters
for Greek, Cyrillic, Hebrew, Arabic, and possibly even Chinese,
Japanese, and Korean, so a font can be several megabytes large.

-- 
Jouni

"Nicolas Grilly" <nic...@ga...> writes:

[about is_string_like]
> But in this function, I don't like the idea to try an operation on a
> string, and wait for an exception in order to know if we really have a
> string or not. It's not very efficient, nor very beautiful.

I wouldn't worry about efficiency until there is a demonstrable need
to speed something up.

> I guess initial developer did that to keep compatibility with old
> Python versions.

I've always thought that is_string_like is there to allow
compatibility with _future_ code where someone is using a new kind of
string-like object that works just like a string but for which
isinstance(x, (str, unicode)) is false.

-- 
Jouni

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:

    Jouni> able to do font subsetting. I was going to look into the
    Jouni> Fonttools library by Just van Rossum, but lately I've been
    Jouni> too busy with other things to.

FYI, matplotlib used to depend on fonttools, but we found the
dependency too onerous and booted it and wrote our own, lighter
freetype support.  So I would be reluctant to reintroduce this
dependency.

JDH

Andrew Straw <str...@as...> writes:

> When I get back to that manuscript (ahem), I'll probably try to bang
> the PDF backend further into shape. What bits need to be
> added/fixed? Is the PDF backend TODO list documented anywhere? 
> where?

The TODO list is in the comments of backend_pdf.py:

# * the alpha channel of images
# * image compression could be improved (PDF supports png-like compression) 
# * encoding of fonts, including mathtext fonts and unicode support
# * Type 1 and Base-14 font support (i.e., "pdf.use_afm") 
# * TTF support has lots of small TODOs, e.g. how do you know if a font  
#   is serif/sans-serif, or symbolic/non-symbolic? 
# * draw_markers, draw_line_collection, etc. 
# * use_tex 

I think the most important thing to fix is the font support. TTF
embedding mostly works but I haven't figured out the encoding issues,
and it would be really nice to be able to do font subsetting. I was
going to look into the Fonttools library by Just van Rossum, but
lately I've been too busy with other things to.

"Nicolas Grilly" <nic...@ga...> writes:

> I've just some issues with:
> - text alignment (I fixed it on my working copy of matplotlib);

Great! Is there a patch somewhere?

-- 
Jouni

In module ft2font, the method FT2Font.get_charmap returns a dict that
maps glyph indices to char codes.

I don't understand the purpose of this mapping, and why the method
doesn't return the reverse mapping, i.e. char codes mapped to glyph
indices.

For example, in backend_ps.py, line 754, the charmap is immediately
reversed, just after being loaded:

        cmap = font.get_charmap()
        glyphd = reverse_dict(cmap)

Thanks,

Nicolas Grilly

>>>>> "Nicolas" == Nicolas Grilly <nic...@ga...> writes:
    Nicolas> But in this function, I don't like the idea to try an
    Nicolas> operation on a string, and wait for an exception in order
    Nicolas> to know if we really have a string or not. It's not very
    Nicolas> efficient, nor very beautiful.

    Nicolas> I guess initial developer did that to keep compatibility
    Nicolas> with old Python versions.

I did it because it is general, elegant, and efficiency doesn't matter
here (any string operation is insignificant to the work we do making a
figure).  What if a user writes their own string class, eg someone
wants a mutable string, or a lower case string, or any number of
custom string objects, and these aren't covered by the types module?

We make heavy use of duck typing in matplotlib, and it hasn't caused
us any problems I know of.

JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:

    Andrew> BTW, what's the "official" status of the PDF backend? Last
    Andrew> I checked (a month or so ago), it seemed to work fine, has
    Andrew> a couple of Python 2.4-isms, but was generally great. I
    Andrew> was surprised that it didn't appear to make it onto the
    Andrew> list of officially-sanctioned backends (e.g. in the "save"
    Andrew> button on the toolbar, IIRC). I found it really useful for

Hmm, in backend_agg.py 
FigureCanvasAgg.print_figure there is an entry for pdf in the print
switch routine.  Which backend are you having trouble on?  All the
*Agg backends should just pass the print request right through to agg,
which should handle PDF (and PS, EPS, SVG, etc...)

JDH

On 11/5/06, Andrew Straw <str...@as...> wrote:
> BTW, what's the "official" status of the PDF backend? Last I checked (a
> month or so ago), it seemed to work fine, has a couple of Python
> 2.4-isms, but was generally great. I was surprised that it didn't appear
> to make it onto the list of officially-sanctioned backends (e.g. in the
> "save" button on the toolbar, IIRC). I found it really useful for making
> vectorized figures with alpha for inclusion in a pdflatex document. (Is
> that possible going via an (e)ps route?) When I get back to that
> manuscript (ahem), I'll probably try to bang the PDF backend further
> into shape. What bits need to be added/fixed? Is the PDF backend TODO
> list documented anywhere? where?

I agree: the PDF backend is almost usable!

I've just some issues with:
- text alignment (I fixed it on my working copy of matplotlib);
- accentuated characters (nearly fixed);
- embedding of TTF fonts in the PDF (in progress - we need to limit
the /Widths array to the 256 characters used in WinAnsiEncoding).

Hi Andrew,

Andrew Straw <str...@as...> wrote:
> I'm not speaking with the authority of one who actually wrote the
> function or uses it, so I don't know the specific reasons, if there are
> any. However, this kind of thing is common (and encouraged) practice in
> Python. It's a use of "duck typing". For more info see
> http://en.wikipedia.org/wiki/Duck_typing

Thank you for your answer. I use Python for two years now and know
"duck typing" very well. It's one of the most powerful features of
this language.

But in this function, I don't like the idea to try an operation on a
string, and wait for an exception in order to know if we really have a
string or not. It's not very efficient, nor very beautiful.

I guess initial developer did that to keep compatibility with old
Python versions.

SGkgR2HDq2wsCgpHYWVsIFZhcm9xdWF1eCA8Z2FlbC52YXJvcXVhdXhAbm9ybWFsZXN1cC5vcmc+
IHdyb3RlOgo+IEkgYW0gYWxsIGZvciBhIGdvb2QgUERGIGJhY2tlbmQsIGJ1dCB5b3Ugc2hvdWxk
IGJlIGF3YXJlIHRoYXQgdW5kZXIKPiB1bmljZXMgeW91IGNhbiB0ZWxsIG1hdHBsb3RsaWIgdG8g
dXNlIGEgZGlzdGlsbGVyLCBhcyBpbGx1c3RyYXRlZCBpbjoKPiBodHRwOi8vd3d3Lm1haWwtYXJj
aGl2ZS5jb20vbWF0cGxvdGxpYi1kZXZlbEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQvbXNnMDAxNjAu
aHRtbAoKWWVzLCBJIGtub3cgaXQncyBwb3NzaWJsZSB0byB1c2UgYSBkaXN0aWxsZXIgdW5kZXIg
VW5pY2VzIHRvIGNvbnZlcnQKbXkgUERGIGludG8gYW4gRVBTLCBidXQgSSdtIHVuZGVyIFdpbmRv
d3MuLi4gTW9yZW92ZXIsIEkgdGhpbmsgaXQncwpnb29kIHRvIGhhdmUgYSBtb3JlIHN0cmFpZ2h0
Zm9yd2FyZCB3YXkgdG8gcHJvZHVjZSBQREYgY2hhcnRzLCB3aXRob3V0CnJlcXVpcmluZyBhIGRp
c3RpbGxlci4K

On Sun, Nov 05, 2006 at 09:27:54AM -0800, Andrew Straw wrote:
> When I get back to that manuscript (ahem), I'll probably try to bang
> the PDF backend further into shape.

That would be great for pdf generation under windows, where you can
hardly assume the user has xpdf or epstopdf installed. It has been
holding back the portability of pyreport (which is by default non
portable as I don't have windows).

Ga=EBl

Gael Varoquaux wrote:
> On Sun, Nov 05, 2006 at 06:07:50PM +0100, Nicolas Grilly wrote:
>   
>> I'm hacking the PDF backend because I need this format to import
>> charts in ConTeXt (this is TeX macro package, similar to LaTeX, we use
>> to produce PDF reports).
>>     
>
> I am all for a good PDF backend, but you should be aware that under
> unices you can tell matplotlib to use a distiller, as illustrated in:
> http://www.mail-archive.com/mat...@li.../msg00160.html
>   
BTW, what's the "official" status of the PDF backend? Last I checked (a
month or so ago), it seemed to work fine, has a couple of Python
2.4-isms, but was generally great. I was surprised that it didn't appear
to make it onto the list of officially-sanctioned backends (e.g. in the
"save" button on the toolbar, IIRC). I found it really useful for making
vectorized figures with alpha for inclusion in a pdflatex document. (Is
that possible going via an (e)ps route?) When I get back to that
manuscript (ahem), I'll probably try to bang the PDF backend further
into shape. What bits need to be added/fixed? Is the PDF backend TODO
list documented anywhere? where?

-Andrew

On Sun, Nov 05, 2006 at 06:07:50PM +0100, Nicolas Grilly wrote:
> I'm hacking the PDF backend because I need this format to import
> charts in ConTeXt (this is TeX macro package, similar to LaTeX, we use
> to produce PDF reports).

I am all for a good PDF backend, but you should be aware that under
unices you can tell matplotlib to use a distiller, as illustrated in:
http://www.mail-archive.com/mat...@li.../msg001=
60.html


Ga=EBl

Hello everybody,

I'm in the process of replacing R by matplotlib to plot all of our charts.

I'm hacking the PDF backend because I need this format to import
charts in ConTeXt (this is TeX macro package, similar to LaTeX, we use
to produce PDF reports).

My first question, very basic, is why function is_string_like, in
module cbook, doesn't simply

   return isinstance(s, types.StringTypes)

instead of

   try: obj + ''
   except (TypeError, ValueError): return 0
   return 1

Thanks for your work,

Nicolas


-- 
Garden - Marketing & Datamining Consultancy
Nicolas Grilly
Tel +33 1 45 72 48 78
Mob +33 6 03 00 25 34
www.garden-paris.com

John Hunter wrote:
>>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes:
>>>>>>             
>
>     Jeff> John Hunter wrote:
>
>     Jeff> John: In the process of updating the proj4 source files to
>     Jeff> version 4.5.0, I've somehow munged the repository.  Could
>     Jeff> you try revision 2836?  If that works for you, I'll try to
>     Jeff> revert the repository.
>
> Yes, this works.
>
> But now I am getting a traceback with basemap + mpl svn in contour
> with the attached file.  I don't know if this is a bug in the example
> code or in the contour module (it appears tcolors is not getting set
> because the changed method is not being called, but I only looked at
> it briefly)
>
> matplotlib/htdocs/screenshots> python
> plotmap.py
> /usr/lib/python2.4/site-packages/matplotlib/figure.py:690:
> DeprecationWarning: Old colorbar kwargs (tickfmt) found; using
> colorbar_classic.
>   warnings.warn(msg, DeprecationWarning)
> Traceback (most recent call last):
>   File "plotmap.py", line 36, in ?
>     colorbar(tickfmt='%d', cax=cax) # draw colorbar
>   File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line
>   342, in colorbar
>     ret = gcf().colorbar(mappable, cax = cax, **kw)
>   File "/usr/lib/python2.4/site-packages/matplotlib/figure.py", line
>   691, in colorbar
>     self.colorbar_classic(mappable, cax, **kw)
>   File "/usr/lib/python2.4/site-packages/matplotlib/figure.py", line
>   825, in colorbar_classic
>     CS = cax.contourf(*args, **kw)
>   File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line
>   4097, in contourf
>     return ContourSet(self, *args, **kwargs)
>   File "/usr/lib/python2.4/site-packages/matplotlib/contour.py", line
>   456, in __init__
>     for level, level_upper, color in zip(lowers, uppers,
>     self.tcolors):
> AttributeError: ContourSet instance has no attribute 'tcolors'
>
>   
John:  If you take the 'tickfmt' argument out of the colorbar call, it 
works.  Apparently, it's a problem with the deprecated 
colorbar_classic.  Note that the updated plotmap.py example in the 
basemap examples directory doesn't use colorbar_classic, and works.

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg