matplotlib-devel Mailing List for matplotlib

Yes! Thank you!
As extra debugging info, the issue was happening regardless of me choosing
GTK, GTKAgg, and others for backends.
Ben Root
On Thu, Jun 3, 2010 at 2:45 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Jun 3, 2010 at 2:41 PM, Benjamin Root <ben...@ou...> wrote:
> > Hello,
> >
> > I am getting this runtime error for some of my plotting scripts ever
> since I
> > did a clean build and install of matplotlib from the svn repo:
> >
> > [snip]
> > File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/text.py",
> line
> > 524, in draw
> > bbox, info = self._get_layout(renderer)
> > File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/text.py",
> > line 298, in _get_layout
> > ismath=False)
> > File
> >
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gdk.py",
> > line 309, in get_text_width_height_descent
> > layout, inkRect, logicalRect = self._get_pango_layout(s, prop)
> > File
> >
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gdk.py",
> > line 283, in _get_pango_layout
> > font_str = '%s, %s %i' % (prop.get_name(), prop.get_style(), size,)
> > File
> >
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/font_manager.py",
> > line 742, in get_name
> > return ft2font.FT2Font(str(findfont(self))).family_name
> > RuntimeError: Could not open facefile
> > /home/bvr/Programs/matplotlib/lib/matplotlib/mpl-data/fonts/ttf/Vera.ttf;
> > Cannot_Open_Resource
> >
> > The file exists, and is certainly read-able. The program "Fonty Python"
> > even checked and said that the fonts in that folder were valid, and
> > displayed samples. Looking back at discussion threads before, this error
> has
> > come up before back in 2007:
> >
> http://www.mail-archive.com/mat...@li.../msg05229.html
> >
> > Any thoughts?
>
> Just a shot in the dark, but does it help to flush the font cache in
> your .matplotlib dir?
>
> > rm -rf ~/.matplotlib/font*.cache
>
> JDH
>

On Thu, Jun 3, 2010 at 2:41 PM, Benjamin Root <ben...@ou...> wrote:
> Hello,
>
> I am getting this runtime error for some of my plotting scripts ever since I
> did a clean build and install of matplotlib from the svn repo:
>
> [snip]
> File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/text.py", line
> 524, in draw
>   bbox, info = self._get_layout(renderer)
>  File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/text.py",
> line 298, in _get_layout
>   ismath=False)
>  File
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gdk.py",
> line 309, in get_text_width_height_descent
>   layout, inkRect, logicalRect = self._get_pango_layout(s, prop)
>  File
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gdk.py",
> line 283, in _get_pango_layout
>   font_str = '%s, %s %i' % (prop.get_name(), prop.get_style(), size,)
>  File
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/font_manager.py",
> line 742, in get_name
>   return ft2font.FT2Font(str(findfont(self))).family_name
> RuntimeError: Could not open facefile
> /home/bvr/Programs/matplotlib/lib/matplotlib/mpl-data/fonts/ttf/Vera.ttf;
> Cannot_Open_Resource
>
> The file exists, and is certainly read-able. The program "Fonty Python"
> even checked and said that the fonts in that folder were valid, and
> displayed samples. Looking back at discussion threads before, this error has
> come up before back in 2007:
> http://www.mail-archive.com/mat...@li.../msg05229.html
>
> Any thoughts?
Just a shot in the dark, but does it help to flush the font cache in
your .matplotlib dir?
 > rm -rf ~/.matplotlib/font*.cache
JDH

Hello,
I am getting this runtime error for some of my plotting scripts ever since I
did a clean build and install of matplotlib from the svn repo:
[snip]
File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/text.py", line
524, in draw
 bbox, info = self._get_layout(renderer)
 File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/text.py",
line 298, in _get_layout
 ismath=False)
 File
"/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gdk.py",
line 309, in get_text_width_height_descent
 layout, inkRect, logicalRect = self._get_pango_layout(s, prop)
 File
"/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gdk.py",
line 283, in _get_pango_layout
 font_str = '%s, %s %i' % (prop.get_name(), prop.get_style(), size,)
 File
"/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/font_manager.py",
line 742, in get_name
 return ft2font.FT2Font(str(findfont(self))).family_name
RuntimeError: Could not open facefile
/home/bvr/Programs/matplotlib/lib/matplotlib/mpl-data/fonts/ttf/Vera.ttf;
Cannot_Open_Resource
The file exists, and is certainly read-able. The program "Fonty Python"
even checked and said that the fonts in that folder were valid, and
displayed samples. Looking back at discussion threads before, this error has
come up before back in 2007:
http://www.mail-archive.com/mat...@li.../msg05229.html
Any thoughts?
Thanks,
Ben Root

On 06/02/2010 01:20 PM, Benjamin Root wrote:
>
>
> On Wed, Jun 2, 2010 at 10:26 AM, John Hunter <jd...@gm...
> <mailto:jd...@gm...>> wrote:
>
> On Wed, Jun 2, 2010 at 9:48 AM, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
> > I am curious as to why bar() should even be acting like
> errorbar(). As a
> > user, I would expect bar() to do bar graphs and errorbar() to do
> error bar
> > graphs. Is there some sort of use-case that I am missing where
> it makes
> > sense to generate errorbars from a bar() function?
See barchart_demo.py. I don't use barcharts myself, but I can imagine 
that if I did, I might want errorbars on them.
>
> Some of this stuff is just really old (circa 2003). When you have
> just a few users and someone sends you a patch, you tend to accept it
> :-)
>
> First we had bar, then we had errorbar, and someone wanted the
> convenience of easily adding errorbars to bar plots. Over time, these
> conveniences have grown into a fairly complex interface (xerr, yerr,
> asymmetric errors). So it has grown more organically than by design
> and some rationalization and normalization of functionality would be a
> good thing. We have to balance that with the downsides of code
> breakage, however.
>
> I kinda figured something like that was the case. I am just cautious
> about additional "organic" development of these functions. I have
> encountered some functions where it was a bug that the function did not
> pass on the kwargs, and others where it wasn't a bug. Does the approach
> of using a separate dict called error_kw fit in with some sort of
> overall design/best practices or might there be a better way to approach
> this.
It is precedented--see the relatively new subplots command, and 
Axes.text, which has had a fontdict kwarg for a long time.
I don't know of a better way of handling this sort of thing. Perhaps it 
could be used more frequently and consistently within mpl.
Organic growth, with its faults and its advantages, is inherent in 
projects like mpl--and even in commercial products like Matlab.
mpl has only a little bit of written coding guidance. See 
http://matplotlib.sourceforge.net/devel/coding_guide.html, most of which 
is not actually about coding.
>
> I merely ask because I am quite new here and I am curious about what
> style we want for our code. Maybe we should consider some sort of
> special universal (for matplotlib) module that does special handling of
> kwargs? I am just throwing out some thoughts.
You are welcome to propose something, but to have a chance of adoption 
it will need to be something that, for the most part, doesn't break 
users' code.
Eric
>
> Ben Root

On Wed, Jun 2, 2010 at 11:41 AM, Eric Firing <ef...@ha...> wrote:
> On 06/01/2010 05:21 PM, Benjamin Root wrote:
> > I have finally managed to test against TkAgg, and the faint white lines
> > do not appear to occur. So, as far as I can tell (no clue about Macs),
> > the GTKCairo, pdf and svg backends have this display bug. Shall I file
> > a bug report for this and another for the misaligned title?
>
> Yes. Please include the simplest scripts you can devise that generate
> and illustrate the problems. In the pcolormesh case, this means keeping
> the plot (and the data being plotted) as simple as possible. If the
> problem can be illustrated with only two color regions, for example,
> that is ideal.
>
> Eric, I have attached scripts to both bug reports. I have noticed that the
svn repo still does not have rasterization decorators for some of the
collections (e.g., PolyCollection, EllipseCollection, CircleCollection if I
remember correctly). Don't know what are supposed to be the final list of
Collection that are eligible for that decorator, but it is incomplete at
this point in the trunk.
Ben Root
> Eric
>
> >
> > Ben Root
> >
> > On Tue, Jun 1, 2010 at 1:07 PM, Benjamin Root <ben...@ou...
> > <mailto:ben...@ou...>> wrote:
> >
> > Correction -- the problem with pcolormesh and the faint white lines
> > are occurring for pdf and svg files, *not* eps files as I originally
> > stated. I am also checking a number of display backends and found
> > that the problem occurs for GTKCairo. I am sure it also happens for
> > TkAgg, but I can not confirm that right now. I am unable to test
> > the Mac backends, though.
> >
> > On a side note, when testing the backends, I noticed that GTKCairo
> > was *slow* for displaying the figures. Also, the GTK backend
> > produced misaligned titles. I can start a new thread about the
> > misaligned titles, if someone wishes.
> >
> > Ben Root
> >
> >
> > On Tue, Jun 1, 2010 at 11:05 AM, Benjamin Root <ben...@ou...
> > <mailto:ben...@ou...>> wrote:
> >
> >
> >
> > On Tue, Jun 1, 2010 at 9:39 AM, Ryan May <rm...@gm...
> > <mailto:rm...@gm...>> wrote:
> >
> > On Mon, May 31, 2010 at 11:28 AM, Benjamin Root
> > <ben...@ou... <mailto:ben...@ou...>> wrote:
> > > Markus,
> > >
> > > That is good to know that it has been fixed. As for the
> > difference in
> > > pcolor and pcolormesh, I think it has to do with the fact
> > that pcolormesh is
> > > composed of many lines while pcolor is composed of many
> > polygons. It is
> > > probably more efficient to rasterize polygons than lines.
> >
> > To be blunt, this makes no sense whatsoever. First,
> > pcolormesh and
> > pcolor differ in that it pcolor uses a generic
> > PolyCollection to draw
> > the quads, while pcolormesh uses a quadmesh object, which
> > can be more
> > efficient at the cost of generality, as it only needs to
> > render a set
> > of identical quads. Second, if you're talking rasterized
> > drawing, in
> > the end what gets written to a file is a 2D array of RGBA
> > values. It
> > doesn't matter what you use to produce the results:
> > identical image on
> > the screen -> identical array in file. It's possible that
> > there are
> > slight differences that you can't really see that produce
> > different
> > arrays, but that won't cause a factor of 8 difference in
> > size. My
> > guess is that pcolormesh isn't rasterizing properly.
> >
> > Indeed, you are right that lines aren't drawn. I have looked
> > back at the images produced by my test script that I posted to
> > this thread and I see where I got confused. The pcolormesh
> > result in pdf and eps files have very faint white blocks around
> > each quad. At high enough data resolution, the color part of
> > the quads look like lines while the white lines look like dots.
> > This happens regardless of using rasterized=True or not, and I
> > don't think it is visible in png files (although I am testing
> > some very high resolution png files to verify).
> >
> > Ben Root
> >
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>