matplotlib-devel Mailing List for matplotlib (Page 4)

Paul Kienzle wrote:
> On Fri, Sep 07, 2007 at 03:09:10PM -0400, Michael Droettboom wrote:
>> Paul Kienzle wrote:
>>> On Fri, Sep 07, 2007 at 12:09:01PM -0400, Michael Droettboom wrote:
>>>> Paul Kienzle wrote:
>>> Note: Adobe SVGViewer doesn't see the embedded fonts, but it works if I
>>> have the fonts installed.  Oh, well!
>> With the embedded fonts, you mean the text just doesn't show up at all? 
> 
> It looks the same as the version without embedded fonts, which is that it
> chooses some incorrect default font with the wrong character codes as I
> showed earlier.

That's very surprising, since when the characters are embedded, there's 
no notion of characters (<text> elements) in the file at all -- it just 
uses references to paths in the file that have non-meaningful names like 
c_a2.

> I thought unicode was supposed to give unique codes to the characters
> so that even if the font was wrong, at least you would get the correct
> glyph from the font.  Or does this only happen at a higher level?

Unfortunately, the Bakoma fonts (Truetype conversions of TeX fonts) are 
not encoded in Unicode.  They're in an encoding that closely resembles 
the somewhat arbitrary encoding that was used to design the original 
fonts (that pre-dates Unicode).  Unless we were to remap those fonts to 
Unicode, we have to suffer along with the encoding they have.  I've been 
playing with ways to rebuild the fonts, but nothing has come up very 
satisfactory.  Long term, hopefully by the time I retire, the Stix fonts 
will be available and we can go over to Unicode whole-hog.

>>   Do you know if the SVG output from Cairo works with Adobe?  They use a 
>> similar (but not identical) approach to embedding the character outlines.
> 
> I'm not set up to run Cairo, but I can check if someone sends me an svg.

Attached (gzipped).

-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Sorry -- that used to work, but fell through the cracks in the recent 
mathtext rewrite.  It shouldn't be difficult to add back in.  I'll let 
you know when that's done.

Cheers,
Mike

william ratcliff wrote:
> Maybe I'm doing something wrong, but is there support for \AA  {the 
> angstrom} symbol within mathtext for any of the backends?  If not, would 
> it be difficult to add?
> 
> Thanks,
> William
> 
> On 9/7/07, *Paul Kienzle* <pki...@ni... <mailto:pki...@ni...>> 
> wrote:
> 
>     On Fri, Sep 07, 2007 at 03:09:10PM -0400, Michael Droettboom wrote:
>      > Paul Kienzle wrote:
>      > > On Fri, Sep 07, 2007 at 12:09:01PM -0400, Michael Droettboom wrote:
>      > >> Paul Kienzle wrote:
>      > > Note: Adobe SVGViewer doesn't see the embedded fonts, but it
>     works if I
>      > > have the fonts installed.  Oh, well!
>      >
>      > With the embedded fonts, you mean the text just doesn't show up
>     at all?
> 
>     It looks the same as the version without embedded fonts, which is
>     that it
>     chooses some incorrect default font with the wrong character codes as I
>     showed earlier.
> 
>     I thought unicode was supposed to give unique codes to the characters
>     so that even if the font was wrong, at least you would get the correct
>     glyph from the font.  Or does this only happen at a higher level?
> 
>      >   Do you know if the SVG output from Cairo works with
>     Adobe?  They use a
>      > similar (but not identical) approach to embedding the character
>     outlines.
> 
>     I'm not set up to run Cairo, but I can check if someone sends me an svg.
> 
>             - Paul
> 
>     -------------------------------------------------------------------------
>     This SF.net email is sponsored by: Splunk Inc.
>     Still grepping through log files to find problems?  Stop.
>     Now Search log events and configuration files using AJAX and a browser.
>     Download your FREE copy of Splunk now >>   http://get.splunk.com/
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 

-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

\angstrom also does not work.

Thanks,
William

On 9/7/07, william ratcliff <wil...@gm...> wrote:
>
> Maybe I'm doing something wrong, but is there support for \AA  {the
> angstrom} symbol within mathtext for any of the backends?  If not, would it
> be difficult to add?
>
> Thanks,
> William
>
> On 9/7/07, Paul Kienzle <pki...@ni...> wrote:
> >
> > On Fri, Sep 07, 2007 at 03:09:10PM -0400, Michael Droettboom wrote:
> > > Paul Kienzle wrote:
> > > > On Fri, Sep 07, 2007 at 12:09:01PM -0400, Michael Droettboom wrote:
> > > >> Paul Kienzle wrote:
> > > > Note: Adobe SVGViewer doesn't see the embedded fonts, but it works
> > if I
> > > > have the fonts installed.  Oh, well!
> > >
> > > With the embedded fonts, you mean the text just doesn't show up at
> > all?
> >
> > It looks the same as the version without embedded fonts, which is that
> > it
> > chooses some incorrect default font with the wrong character codes as I
> > showed earlier.
> >
> > I thought unicode was supposed to give unique codes to the characters
> > so that even if the font was wrong, at least you would get the correct
> > glyph from the font.  Or does this only happen at a higher level?
> >
> > >   Do you know if the SVG output from Cairo works with Adobe?  They use
> > a
> > > similar (but not identical) approach to embedding the character
> > outlines.
> >
> > I'm not set up to run Cairo, but I can check if someone sends me an svg.
> >
> >         - Paul
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >>   http://get.splunk.com/
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>

Maybe I'm doing something wrong, but is there support for \AA  {the
angstrom} symbol within mathtext for any of the backends?  If not, would it
be difficult to add?

Thanks,
William

On 9/7/07, Paul Kienzle <pki...@ni...> wrote:
>
> On Fri, Sep 07, 2007 at 03:09:10PM -0400, Michael Droettboom wrote:
> > Paul Kienzle wrote:
> > > On Fri, Sep 07, 2007 at 12:09:01PM -0400, Michael Droettboom wrote:
> > >> Paul Kienzle wrote:
> > > Note: Adobe SVGViewer doesn't see the embedded fonts, but it works if
> I
> > > have the fonts installed.  Oh, well!
> >
> > With the embedded fonts, you mean the text just doesn't show up at all?
>
> It looks the same as the version without embedded fonts, which is that it
> chooses some incorrect default font with the wrong character codes as I
> showed earlier.
>
> I thought unicode was supposed to give unique codes to the characters
> so that even if the font was wrong, at least you would get the correct
> glyph from the font.  Or does this only happen at a higher level?
>
> >   Do you know if the SVG output from Cairo works with Adobe?  They use a
> > similar (but not identical) approach to embedding the character
> outlines.
>
> I'm not set up to run Cairo, but I can check if someone sends me an svg.
>
>         - Paul
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Fri, Sep 07, 2007 at 03:09:10PM -0400, Michael Droettboom wrote:
> Paul Kienzle wrote:
> > On Fri, Sep 07, 2007 at 12:09:01PM -0400, Michael Droettboom wrote:
> >> Paul Kienzle wrote:
> > Note: Adobe SVGViewer doesn't see the embedded fonts, but it works if I
> > have the fonts installed.  Oh, well!
> 
> With the embedded fonts, you mean the text just doesn't show up at all? 

It looks the same as the version without embedded fonts, which is that it
chooses some incorrect default font with the wrong character codes as I
showed earlier.

I thought unicode was supposed to give unique codes to the characters
so that even if the font was wrong, at least you would get the correct
glyph from the font.  Or does this only happen at a higher level?

>   Do you know if the SVG output from Cairo works with Adobe?  They use a 
> similar (but not identical) approach to embedding the character outlines.

I'm not set up to run Cairo, but I can check if someone sends me an svg.

	- Paul

Paul Kienzle wrote:
> On Fri, Sep 07, 2007 at 12:09:01PM -0400, Michael Droettboom wrote:
>> Paul Kienzle wrote:
> Note: Adobe SVGViewer doesn't see the embedded fonts, but it works if I
> have the fonts installed.  Oh, well!

With the embedded fonts, you mean the text just doesn't show up at all? 
  Do you know if the SVG output from Cairo works with Adobe?  They use a 
similar (but not identical) approach to embedding the character outlines.

Cheers,
Mike

-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

lib/matplotlib/mpl-data/matplotlibrc is generated at build time by 
interpolating some fields in matplotlibrc.template.

Since it always get changed, it always shows up as a modified file by 
svn status.  This is only a minor annoyance when working on the trunk. 
However, when working on a branch with svnmerge, svnmerge won't let me 
merge from trunk if I have any modified files at all, so every time I 
want to merge, I have to be sure to revert that file.

Is there any reason not to just remove this file from SVN?

-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> On a related note, I'm curious about usage of the Gdk and Wx (non-Agg) 
> rendering backends.  They both have various shortcomings relative to Agg 
> (no antialiasing, limited mathtext rotation, etc.).  Is there a real 
> performance or other reason to keep these maintained at this point?

I'm a heavy wx users, and have only used the wxAgg back-end.

However, if you are running an X application from a remote server, then 
the *Agg backends are much slower than the raw wx (or gtk) back ends -- 
I've never done it, but it has come up on this list. The reason is that 
it's faster to send the drawing commands over the network than the 
entire image buffer.

> don't see them as significantly easier for embedding in applications 
> than Agg (since both GtkAgg and WxAgg spell out how to get a native 
> image buffer from the Agg buffer without using C extensions).

You're right -- I don't think that's an issue.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On 9/7/07, Michael Droettboom <md...@st...> wrote:

> > Embedding characters increased the size of the svg file for this example
> > from 12k to 42k but will decrease tech support by a lot, so its probably
> > worth making it the default.
>
> If I hear no objections on this list, I'll go ahead and do that.

I think this is well worth it -- we want to insure that the file will
render properly across SVG views.

On 9/7/07, Michael Droettboom <md...@st...> wrote:
> [Moved to the devel list from users]
>
> On a related note, I'm curious about usage of the Gdk and Wx (non-Agg)
> rendering backends.  They both have various shortcomings relative to Agg
> (no antialiasing, limited mathtext rotation, etc.).  Is there a real
> performance or other reason to keep these maintained at this point?  I
> don't see them as significantly easier for embedding in applications
> than Agg (since both GtkAgg and WxAgg spell out how to get a native
> image buffer from the Agg buffer without using C extensions).
>
> Hope the question doesn't offend -- I can see their "reason to be"
> historically, but maybe those reasons are no longer relevant.

The two adbantages of GTK that I am aware of are

  -- a bit faster than GTKAgg

  -- better support over X11 because you don't have to transfer the
entire bitmap on every redraws since the native X11 commands can be
transmitted.

But these advantages may not outweigh their disadvantages
(maintenance, inertia preventing us from refactoring).  We could
consider adding an svn dir w/ a bunch of experimental and/or noncore
and/or not supported backends.  If the backend lookup machinery were a
bit more sophisticated (eg if 'backend : myformat' is specified, the
imported will try and 'import backend_myformat' or something like
that, thern users could use backends outside the normal install tree.
Then we could remove backends we do not want to actively maintain,
while providing a location in svn for those who want to keep using
them and providing a friendly way for them to keep using them with
mpl.

JDH

JDH

On Fri, Sep 07, 2007 at 01:24:37PM +0200, Stefan van der Walt wrote:
> I am interested in this problem, too.  A binary comparison would
> probably be too sensitive.  How about comparing coefficients of some
> transform?  I.e. the residual on certain Fourier coefficients or parts
> of a wavelet transform?

OK, so I'll reply to the list (I already replied to Andrew in private).
I don't know much about this. Prabhu Ramachandran might know more.

I can however point you to where this is used in Mayavi2:

The file where the tvtk code is, is:
https://svn.enthought.com/enthought/browser/branches/enthought.mayavi_2.0/tests/
common.py
the function you are interested in is "compare_image".

It is used in tests in the directory:
https://svn.enthought.com/enthought/browser/branches/enthought.mayavi_2.0/tests

I hope you'll find what you are interested in with this info and the tvtk
code related. From the tvtk code you can go up to the vtk code (the
functions have the same name).

If you don't find what you are interested in, you will have to ask Prabhu
or someone who knows vtk better than I do.

Cheers,

Gaël

On Fri, Sep 07, 2007 at 12:09:01PM -0400, Michael Droettboom wrote:
> Paul Kienzle wrote:
> > I was going to check if this also fixed the dot on the 'i' in sin as
> > well as the equals sign,
> 
> FWIW, it did for me in Inkscape.

And for me in Safari.

Note: Adobe SVGViewer doesn't see the embedded fonts, but it works if I
have the fonts installed.  Oh, well!

> > but I get the following:
> > 
> >   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/mathtext.py", line 616, in _get_info
> >     raise ValueError('unrecognized symbol "%s"' % sym)
> > ValueError: unrecognized symbol "\sin"
> 
> Strange.  My recent bugfixes shouldn't have affected that file.
> 
> That line number doesn't match up with what I have in svn trunk. 
> Perhaps you somehow have reverted to an older version...?

Oops ... my error.  I modified PYTHONPATH in bashrc but didn't
refresh my terminals.

	- Paul

Paul Kienzle wrote:
> I was going to check if this also fixed the dot on the 'i' in sin as
> well as the equals sign,

FWIW, it did for me in Inkscape.

> but I get the following:
> 
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/mathtext.py", line 616, in _get_info
>     raise ValueError('unrecognized symbol "%s"' % sym)
> ValueError: unrecognized symbol "\sin"

Strange.  My recent bugfixes shouldn't have affected that file.

That line number doesn't match up with what I have in svn trunk. 
Perhaps you somehow have reverted to an older version...?

Cheers,
Mike

-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, Sep 07, 2007 at 10:58:47AM -0400, Michael Droettboom wrote:
> Paul Kienzle wrote:
> > On Fri, Sep 07, 2007 at 06:40:55AM -0400, Michael Droettboom wrote:
> >> I'd be curious to see a screenshot of what Safari looks like.  It may be a simple fix on our end.
> > 
> > See attached.
> 
> It turns out this "difference" (I'm not calling it a bug) is visible in 
> Inkscape as well.
> 
> There seems to be some disagreement about the 'Z' operator on SVG paths 
> (which is supposed to close the current path segment).  In Firefox, 'Z' 
> doesn't move the reference point for subsequent relative operations, 
> whereas in Inkscape (and presumably Safari) it does.  So the delta 
> problem is because the inner triangle was being drawn offset outside of 
> the outer triangle.  The workaround in matplotlib is to never do a 
> relative operation after the 'Z' operator (r3808) and avoid exercising 
> this difference.
> 
> Unfortunately, the SVG 1.1 and 1.2 specs don't appear to directly 
> address this issue (at least it isn't very explicit):
> 
> 	http://www.w3.org/TR/SVG/paths.html
> 
> So it's hard to say who's "to blame" here, but perhaps the spec should 
> be clarified.

I was going to check if this also fixed the dot on the 'i' in sin as
well as the equals sign, but I get the following:

  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/mathtext.py", line 616, in _get_info
    raise ValueError('unrecognized symbol "%s"' % sym)
ValueError: unrecognized symbol "\sin"


	- Paul

On Fri, Sep 07, 2007 at 10:31:13AM -0400, Michael Droettboom wrote:
> Paul Kienzle wrote:
> > On Fri, Sep 07, 2007 at 06:40:55AM -0400, Michael Droettboom wrote:
> >> I'd be curious to see a screenshot of what Safari looks like.  It may be a simple fix on our end.
> > 
> > See attached.
> > 
> >> As for file sizes, the SVG spec makes an "informational recommendation" to allow gzip-compressed SVG files.  So some tools support commpression (Inkscape), and others don't (Firefox).  Hopefully more will start supporting that.
> > 
> > Safari doesn't.  IE 7 does.
> 
> By IE7 you mean "IE7 on OS-X with Adobe SVG Plugin?"  I've never used 
> that browser -- it doesn't have built-in SVG support, correct?

Actually it is running on Parallels on Windows XP SP2.

> > Note that IE 7.0.5730.11 doesn't render mathtext_demo.svg with the Adobe 
> > 3.03 SVGViewer plugin.  Instead it reports bad CSS selector.  I looked around
> > for a bit, but couldn't find an alternative viewer.  Other svg files work.
> 
> In general, I'm not too concerned about supporting a long abandoned tool 
> like the Adobe SVG viewer.

Long abandoned it maybe, but I don't see any real alternatives for IE.  I
suppose one could use a java-based implementation and write a full-featured
web app, but a browser plugin is a lot more convenient.

	- Paul

Paul Kienzle wrote:
> On Fri, Sep 07, 2007 at 06:40:55AM -0400, Michael Droettboom wrote:
>> I'd be curious to see a screenshot of what Safari looks like.  It may be a simple fix on our end.
> 
> See attached.

It turns out this "difference" (I'm not calling it a bug) is visible in 
Inkscape as well.

There seems to be some disagreement about the 'Z' operator on SVG paths 
(which is supposed to close the current path segment).  In Firefox, 'Z' 
doesn't move the reference point for subsequent relative operations, 
whereas in Inkscape (and presumably Safari) it does.  So the delta 
problem is because the inner triangle was being drawn offset outside of 
the outer triangle.  The workaround in matplotlib is to never do a 
relative operation after the 'Z' operator (r3808) and avoid exercising 
this difference.

Unfortunately, the SVG 1.1 and 1.2 specs don't appear to directly 
address this issue (at least it isn't very explicit):

	http://www.w3.org/TR/SVG/paths.html

So it's hard to say who's "to blame" here, but perhaps the spec should 
be clarified.

Cheers,
Mike

-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Paul Kienzle wrote:
> On Fri, Sep 07, 2007 at 06:40:55AM -0400, Michael Droettboom wrote:
>> I'd be curious to see a screenshot of what Safari looks like.  It may be a simple fix on our end.
> 
> See attached.
> 
>> As for file sizes, the SVG spec makes an "informational recommendation" to allow gzip-compressed SVG files.  So some tools support commpression (Inkscape), and others don't (Firefox).  Hopefully more will start supporting that.
> 
> Safari doesn't.  IE 7 does.

By IE7 you mean "IE7 on OS-X with Adobe SVG Plugin?"  I've never used 
that browser -- it doesn't have built-in SVG support, correct?

> Note that IE 7.0.5730.11 doesn't render mathtext_demo.svg with the Adobe 
> 3.03 SVGViewer plugin.  Instead it reports bad CSS selector.  I looked around
> for a bit, but couldn't find an alternative viewer.  Other svg files work.

In general, I'm not too concerned about supporting a long abandoned tool 
like the Adobe SVG viewer.  However...

I suspect this is related to a recent change to localize all the styles 
into a stylesheet (to save on filesize).  There is a CSS stylesheet at 
the bottom that looks like this:

._6 { fill: #000000 }
._1 { fill: #bfbf00; stroke: #000000; stroke-width: 1.0; 
stroke-linejoin: miter; stroke-linecap: square;  opacity: 1.0 }

It seems there might be a small discrepancy between the SVG spec and 
CSS2 specs.  SVG 1.1 says using a period as a class selector is ok:

http://www.w3.org/TR/SVG/styling.html#ClassAttribute

CSS2 says they should only work with HTML:

http://www.w3.org/TR/REC-CSS2/selector.html#class-html

On second look, this change also breaks support for inkscape (which 
AFAICT doesn't support external stylesheets).  So, I'll take this stuff 
out back out, which should also fix Adobe SVG problem.

Cheers,
Mike

-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, Sep 07, 2007 at 06:40:55AM -0400, Michael Droettboom wrote:
> I'd be curious to see a screenshot of what Safari looks like.  It may be a simple fix on our end.

See attached.

> As for file sizes, the SVG spec makes an "informational recommendation" to allow gzip-compressed SVG files.  So some tools support commpression (Inkscape), and others don't (Firefox).  Hopefully more will start supporting that.

Safari doesn't.  IE 7 does.

Note that IE 7.0.5730.11 doesn't render mathtext_demo.svg with the Adobe 
3.03 SVGViewer plugin.  Instead it reports bad CSS selector.  I looked around
for a bit, but couldn't find an alternative viewer.  Other svg files work.

	- Paul

Paul Kienzle wrote:
> Firefox renders the dashed grid lines as solid,
> so neither is perfect.

Turns out that's a matplotlib bug.  Fixed in r3804.

> SVG is not quite ready for prime time.

I agree, it's probably not as far along in the details as Ps and Pdf. 
An alternative is to use the Cairo backend to produce SVGs.  That code 
is probably a bit more mature, though FWIW the files it produces are 
larger.  (And there was already a long discussion on this list about 
pros/cons of Cairo wrt matplotlib that I won't get into...)

> Embedding characters increased the size of the svg file for this example 
> from 12k to 42k but will decrease tech support by a lot, so its probably 
> worth making it the default.

If I hear no objections on this list, I'll go ahead and do that.

Cheers,
Mike

-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

[Moved to the devel list from users]

On a related note, I'm curious about usage of the Gdk and Wx (non-Agg) 
rendering backends.  They both have various shortcomings relative to Agg 
(no antialiasing, limited mathtext rotation, etc.).  Is there a real 
performance or other reason to keep these maintained at this point?  I 
don't see them as significantly easier for embedding in applications 
than Agg (since both GtkAgg and WxAgg spell out how to get a native 
image buffer from the Agg buffer without using C extensions).

Hope the question doesn't offend -- I can see their "reason to be" 
historically, but maybe those reasons are no longer relevant.

Cheers,
Mike

Eric Firing wrote:
> If you are using the gd or paint backends, please speak up *now*, and 
> tell me what the advantage is over the myriad other ways of generating 
> png files with mpl.  I would like to delete these backends *soon* unless 
> there is some real advantage in keeping them.
> 
> Thanks.
> 
> Eric
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 
Michael Droettboom
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, Sep 06, 2007 at 07:55:13PM -0700, Andrew Straw wrote:
> Gael Varoquaux wrote:
> > 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 th=
e
> >> 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 plo=
t
> >> output.  Similarly for ps/pdf.  Differences in fonts between platfor=
ms
> >> might be a problem in this scheme.
> >=20
> > VTK does this for automated testing.
>=20
> Is there a URL that describes this in much detail -- a little searching=
=20
> turns up the odd tidbit, but nothing I can sink my teeth into. I'm=20
> interested because my understanding is that different OpenGL=20
> implementations draw things (slightly) differently, so I'd be curious=20
> how they deal with that...

I am interested in this problem, too.  A binary comparison would
probably be too sensitive.  How about comparing coefficients of some
transform?  I.e. the residual on certain Fourier coefficients or parts
of a wavelet transform?

Cheers
St=E9fan

I'd be curious to see a screenshot of what Safari looks like.  It may be a simple fix on our end.

As for file sizes, the SVG spec makes an "informational recommendation" to allow gzip-compressed SVG files.  So some tools support commpression (Inkscape), and others don't (Firefox).  Hopefully more will start supporting that.

As of yesterday, you can save a gzipped SVG file directly from matplotlib by specifying "svgz" as an extension.

Cheers,
Mike

On Thu, 6 Sep 2007 19:44:51 -0500, "John Hunter" wrote:
>
> A minor correction -- all the backends support rectangular clipping --
> but only agg supports polygon clipping currently.  The polar axes uses
> a polygon approximation to a circle for the axes border which is used
> to clip the lines.  I think this would be fairly easy to add to ps,
> pdf, and svg since i think they all have support for polygon clipping.
>  I'm not sure what the cairo status is.

I'm not sure about the cairo backend in matplotlib. But cairo itself
definitely has very good for polygon, (and curve-based path),
clipping. So it should be extremely trivial to add that to the cairo
backend in matplotlib if it's not there already.

And I'd be glad to help anyone doing this if they got stuck.

-Carl

Gael Varoquaux wrote:
> 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.

Is there a URL that describes this in much detail -- a little searching 
turns up the odd tidbit, but nothing I can sink my teeth into. I'm 
interested because my understanding is that different OpenGL 
implementations draw things (slightly) differently, so I'd be curious 
how they deal with that...

-Andrew

On 9/6/07, Michael Droettboom <md...@st...> wrote:
> 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.
>

A minor correction -- all the backends support rectangular clipping --
but only agg supports polygon clipping currently.  The polar axes uses
a polygon approximation to a circle for the axes border which is used
to clip the lines.  I think this would be fairly easy to add to ps,
pdf, and svg since i think they all have support for polygon clipping.
 I'm not sure what the cairo status is.

JDH