matplotlib-devel Mailing List for matplotlib

Jared has gotten a nice start on an SVG backend, but there are a few
more things that need to be done and other work has overtaken him.
There has been a lot of interest in an SVG backend, generally, and
Eric and Paul have both expressed some interest in the past in
developing this backend, so I thought I could corral some of that
interest into finishing it off.
Here are the areas I'm aware of
 * font support - currently font support in svg is broken. This is a
 natural one for you Paul, if you still have any hair left after the
 cmex fonts in ps mathtext.
 * mathtext support - shouldn't be too bad after fixing above for
 truetype fonts. Probably involves some issues of how to get svg
 renderers to handle unknown fonts (cm*). Paul?
 * image support - Jared and I discussed this earlier and SVG
 apparently doesn't handle bitmaps as direct includes. So we can't
 use the same trick that worked for PS. But you can include PNG
 files by filename. I just added a "write_png" method to the _image
 module, and implemented a stub draw_image in backend svg that calls
 this method. What's left is to handle the offsets and generate the
 appropriate svg. Eric?
 * numarray broken - for reasons not clear to me I get a "ValueError:
 function not supported' error on the SVG backend on the call to
 y = self.height - y
 in draw_lines running with rc numarray and a matplotlib compiled
 with numerix. Haven't had time to debug this further.
 * is there a figure centering issue in svg as their is in ps, so that
 the image appears in the center of the page, when, for example,
 loaded into a web browser with the svg plugin? 
 * docs - document the backend in backends.html.template, links to svg
 viewers, etc...
 * dpi - is SVG properly setup to ignore dpi calls?
Jared, I had already made some changes to the backend before the diff
you sent me with your latest version so I can't merge. If you could
resend a complete file, I can manually merge with ediff.
Ideally, Paul could fixup the text related stuff since he already has
a lot of expertise there and Eric could take the rest. Let me know...
Thanks!
JDH

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
 Gregory> Hi, I just encounter a problem of robustness when using
 Gregory> semilogy: when all the y data are the same, I got a
 Gregory> ZeroDivisionError: SeparableTransformation:eval_scalars
 Gregory> yin interval is zero; cannot transform
 Gregory> A classic plot have no problem and draw a flat line with
 Gregory> conventional y interval (range 0-2 for y=1).
 Gregory> Minimal example:
 Gregory> from matplotlib.matlab import all x=arange(10) y=0*x+1
 Gregory> plot(x,y) -> ok figure(2) semilogy(x,y) -> error
 Gregory> I guess the special-casing done for plot was not extended
 Gregory> to semilog?
Hi Gregory,
Yes, this is a simple oversight. In the autoscale method of
LogLocator, return
 return self.nonsingular(vmin, vmax)
 
 Gregory> On a related matter (and probably far more difficult to
 Gregory> change), for now if one plot y values having 0 or
 Gregory> negative elements, one got a math error, while in matlab
 Gregory> negative values are ignored...would it be possible to
 Gregory> switch (ideally, optionally with the help of a command or
 Gregory> option in .matplotlibrc) to matlab behavior? I guess
 Gregory> doing a max(epsilon, y) on the data which would be
 Gregory> logarithmically scaled, and not taking into account data
 Gregory> below a certain value (mindouble?) for computing the y
 Gregory> range would do it...
Yes, this is a much more difficult issue. It used to be more
difficult in earlier versions of matplotlib when x and y transforms
were handled independently. Now that transforms of x and y happen
together in the new transform architecture, it should be possible. A
number of users have requested support for plotting arrays with NaN
(this might be considered a special case) but this is made a but
difficult since python doesn't support nan across platforms and
numeric and numarray handle this differently. Not impossible, of
course, just difficult. Special casing this for log would be
considerably easier.
 Gregory> Finally, I am planning to submit a new backend (fltkAgg),
 Gregory> builded on the model of tkagg ang gtkagg but using fltk
 Gregory> and it's pyfltk bindings...is this of interest? It is
 Gregory> almost ready, but I had to modify pyfltk so i prefer to
 Gregory> wait till my modifs are accepted on this side (and also
 Gregory> want to experiment with a matlab-like interractive zoom,
 Gregory> is there something similar present in other interractive
 Gregory> backends?)
I plan on redoing the entire navigation scheme in the near future. It
will provide
 * "hand" pan whether than button click. Ie, you select a hand tool
 and physically move the axis. The axes select menu for multiple
 axes would probably be replaced by a "apply to all" checkbox. Ie,
 your navigation would affect one or all of the axes
 * zoom to rectangle
 * a view limit stack with forward and back buttons like on a web
 browser to navigate through previously defined views.
When this is done, I plan on making the toolbar an rc param (classic
or newfangled or none). So it would be ideal if you implemented a
classic toolbar for your backend before a newfangled one, but is not a
requirement.
As for including new backends in matplotlib. My initial response was
definitely! My new response is definitely, with caveats. Maintaining
the various backends across operating systems has become a challenge.
Eg, 6 backends cross 3 major platforms is 18 combinations, this is
compounded by the fact that most of the GUIs we support have different
versions in play. That says nothing about developing new features,
maintaining the front end, documentation, web page, etc -.
Historically, backend developers have implemented the features they
want and need and don't expend a lot of effort keeping their backend
current with new features, implementing a full feature set, testing
across various operating systems, maintaining web documentation for
installing and using the backend (in backends.html) and answering
mailing list questions specific to your backend. For example, the wx
implementer has done very little since the first, admittedly nice, wx
implementation. Because I care about distributing a product that
works, it usually falls upon me to do it and I don't have any more
free time. A more recent example is the submission of the SVG
backend, which is also in need of a new maintainer. Todd Miller, who
wrote the Tk backend, has been a notable and much welcomed exception.
Because you opted to make a *Agg backend, this task is vastly
simplified since Agg automatically will implement all the new drawing
features for you, ie images, mathtext, fonts and other hard things
come for free. But there will still be fltk version, platform and
installation issues that arise.
If you're willing to make this ongoing commitment, my answer still is
definitely! If this looks like too much to you, I'll be happy to
include links to it on my site but may not want to make it part of the
official distribution.
Sound fair?
JDH