matplotlib-devel Mailing List for matplotlib

I think this is a known bug (and maybe a bug should be filed so it doesn't get lost).

Most of the backends don't have support for clipping which would be required for this to work.

Cheers,
Mike

polar_demo agg and polar_demo pdf/ps/svg show different results.  In agg, 
the spiral is clipped to the polar axes.  In pdf/ps/svg it is clipped to 
the rectangle containing the axes.

Note: I don't use polar plots, so I'm mentioning this for completeness only.

	- Paul

I'm attaching a screenshot of Safari rendering svg for mathtext_demo.py
(modified to show that formulae can be rotated by arbitrary angles).

For some reason it is picking the wrong symbols from the font.

Firefox on OS X picks the same incorrect symbols, but it is picking them 
from a courier font so the results are really ugly.

	- Paul

The Agg backend has a feature where if "bmp" was specified as a file 
extension, it saves as a raw RGBA image.  IMHO, this is perhaps too 
easily confused with the "Microsoft Windows Bitmap" format.  There is a 
(someone else's) bug filed against this:

http://sourceforge.net/tracker/index.php?func=detail&aid=1696469&group_id=80706&atid=560720

As part of my recent refactoring of code to map image filetypes to 
backends, I removed this meaning of .bmp.  If anyone has any reasons why 
.bmp should stay as a "raw" format, let me know, and I'll put it back 
in.  Either way, I'll close the bug as either "fixed" or "rejected".

Cheers,
Mike

Paul Kienzle <pki...@ni...> writes:

> We could store a copy of the png output somewhere in the svn tree.  Then,
> whenever we change something we can do a binary comparison on all the
> plots.  It would avoid issues such as breakage of polar plots where the 
> author of the changes didn't consider that it would affect polar plot
> output.  Similarly for ps/pdf.  Differences in fonts between platforms
> might be a problem in this scheme.

For ps/pdf the files would have to be converted to e.g. png for the
comparison to be meaningful. At least pdf files contain a randomly
selected string to identify the file, as well as the creation date, 
and I am not aware of a diff tool for pdf.

Perhaps the template backend could be extended to print out a log of 
all calls to draw_*, and the logs compared. This would enable a kind 
of limited automatic testing of interactive features such as window
resizing and zooming: let the test backend simulate resize or zoom
events and check the draw_* log against a hand-checked version. This
approach could catch bugs like the "handles = ax.lines" which should
have been "handles = ax.lines[:]", which was only visible when alpha 
was less than 1.
(http://article.gmane.org/gmane.comp.python.matplotlib.devel/2574)

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Paul Kienzle wrote:
> On Thu, Sep 06, 2007 at 08:14:19AM -0400, Michael Droettboom wrote:
>> On a broader note, I've been using backend_driver.py as my ersatz 
>> "acceptance test suite."  Not all of these examples are included in it, 
>> of course.  Is there good reason for that, or should I go ahead and add 
>> these to backend_driver?  As we're all well aware, matplotlib has an 
>> unusually large configuration space, so any bit of testing automation 
>> really helps.
> 
> We could store a copy of the png output somewhere in the svn tree.  Then,
> whenever we change something we can do a binary comparison on all the
> plots.  It would avoid issues such as breakage of polar plots where the 
> author of the changes didn't consider that it would affect polar plot
> output.  Similarly for ps/pdf.  Differences in fonts between platforms
> might be a problem in this scheme.

We could have a special flag for font_manager.py that only loads fonts 
from mpl-data/fonts.  Then the results for Agg should theoretically be 
the same across platforms.  The Gdk, Cairo and wxRenderer would all have 
slightly different results across platforms, however, as the underlying 
font engines could change.

Alternatively, we could sidestep this problem by producing a set of PNG 
images for each platform which would have to be individually verified on 
a per-platform basis.  It (at least) triples the verification work, but 
cuts down on work in other areas...

Cheers,
Mike

On Thu, Sep 06, 2007 at 08:46:24AM -0400, Paul Kienzle wrote:
> We could store a copy of the png output somewhere in the svn tree.
> Then,
> whenever we change something we can do a binary comparison on all the
> plots.  It would avoid issues such as breakage of polar plots where the
> author of the changes didn't consider that it would affect polar plot
> output.  Similarly for ps/pdf.  Differences in fonts between platforms
> might be a problem in this scheme.

VTK does this for automated testing.

Gaël

On Thu, Sep 06, 2007 at 08:14:19AM -0400, Michael Droettboom wrote:
> On a broader note, I've been using backend_driver.py as my ersatz 
> "acceptance test suite."  Not all of these examples are included in it, 
> of course.  Is there good reason for that, or should I go ahead and add 
> these to backend_driver?  As we're all well aware, matplotlib has an 
> unusually large configuration space, so any bit of testing automation 
> really helps.

We could store a copy of the png output somewhere in the svn tree.  Then,
whenever we change something we can do a binary comparison on all the
plots.  It would avoid issues such as breakage of polar plots where the 
author of the changes didn't consider that it would affect polar plot
output.  Similarly for ps/pdf.  Differences in fonts between platforms
might be a problem in this scheme.

	- Paul

Paul Kienzle wrote:
> I went through the demo list again today.  Here are some problems:
> 
> $ python fonts_demo.py 
> Traceback (most recent call last):
>   File "fonts_demo.py", line 31, in <module>
>     font.set_name('Script MT')
> AttributeError: 'FontProperties' object has no attribute 'set_name'

Fixed in r3795.

> I'm getting segfaults for the following on wxagg for os x:
> 
>   annotation_demo
>   polar_*
>   transoffset
> 
> The polar demos work for pdf but not agg from backend_driver.py

Fixed in r3796.  (I had changed the size of the alpha buffer to 1-byte 
per pixel to match the type as specified to Agg, but apparently that 
wasn't a good idea.  There's a lot to be confused about in Agg... ;)

On a broader note, I've been using backend_driver.py as my ersatz 
"acceptance test suite."  Not all of these examples are included in it, 
of course.  Is there good reason for that, or should I go ahead and add 
these to backend_driver?  As we're all well aware, matplotlib has an 
unusually large configuration space, so any bit of testing automation 
really helps.

Cheers,
Mike