matplotlib-devel Mailing List for matplotlib

> That sounds more feasible -- however, keep in mind that anything without a
> public interface (a get_* method) is free to change in a future version of
> matplotlib. I suspect (though haven't thought it all the way through) that
> you may be required to dig into private members to get everything you need.
That may be possible, particularly I suppose for the actual plot data
(x, y(, z) values). I'm going to have to look into what
matplotlib.get* can offer me. Is there a list with all the methods
available?
> I also suspect that this will be a lot of work to support all of the kinds
> of plots that matplotlib supports, and problems are likely to arise when the
> semantics of Pgfplot and/or TikZ don't mesh well. For example, does Pgf
> plot support the same set of nonlinear transformations as matplotlib?
matplotlib and Pgfplots certainly have a different feature set, but
for a couple of common simple plots (e.g., 2D x, y data, log-scaled
axes, lines, markers, and so forth) it should be possible to write a
very basic extendible translator.
> Other people have suggested TikZ support in the past, and I, personally,
> haven't been very convinced of the usefulness of such a thing.
Well, yeah, I guess it is possible to export PDF files in such a way
that it looks sort of nice if you watch out what you do with the font
sizes, and font family in general. Over the years I've become somewhat
tired of that whole tinkering with the fonts, and eventually I'd be
about 80% happy with the result I got. If you don't want to do that
every time, and you want 100%, TikZ/Pgfplots can come in quite handy;
especially if a simple module can be written rather quickly. If you
have a simple 2D plot and you would like to get it cleanly into your
LaTeX file, why not use TikZ if it's available?
Cheers,
Nico

Nico Schlömer wrote:
> Hi,
>
> I'm looking into replacing my MATLAB(R) plotting routines by something
> slicker, and quite naturally found matplotlib. It has all the
> capabilities that I would need, except that I can't yet transform my
> plots into TikZ.
> For MATLAB(R), I used this rather elaborate script
> <http://win.ua.ac.be/~nschloe/content/matlab2tikz>.
>
> Well, I thought I can just go ahead and start writing and equivalent
> backend; the documentation is really nice and clear (quite unlike
> MATLAB's!) so it was no big problem to get into the concepts of the
> backend. I played around a little and thought about how I could
> implement this and that, and some questions arose which can maybe best
> answered here.
>
> For the sake of clarity, let me just give a snippet of Pgfplots (TikZ)
> code that I would like the backend to produce
>
> ===================== *snip* =====================
> [...]
> \begin{semilogyaxis}
> [axis on top,
> xtick={2,4,6,8,10,12,14,16},
> ytick={1e-15,1e-10,1e-05,1,100000},
> xmin=0.000000e+00,xmax=1.700000e+01,
> ymin=1.000000e-15,ymax=1.000000e+05,
> xmajorgrids,
> ymajorgrids,
> title={$\norm{F(\psi)}_2$},
> xlabel={$k$},
> width=\figurewidth,
> height=\figureheight,
> scale only axis
> ]
> % Line plot
> \addplot [color=red,only marks,mark=*,mark options={solid,fill=red}]
> coordinates{
> (1.000000e+00,3.206000e+01) (2.000000e+00,3.860000e+01)
> (3.000000e+00,1.421000e+03) (4.000000e+00,4.143000e+02)
> (5.000000e+00,1.445000e+02) (6.000000e+00,3.775000e+01)
> (7.000000e+00,7.455000e+00) (8.000000e+00,7.228000e-01)
> (9.000000e+00,2.275000e-02) (1.000000e+01,4.953000e-05)
> (1.100000e+01,9.718000e-10) (1.200000e+01,5.534000e-07)
> (1.300000e+01,4.217000e-11) (1.400000e+01,3.930000e-03)
> (1.500000e+01,2.067000e-07) (1.600000e+01,7.231000e-12)
> };
> \end{semilogyaxis}
> [...]
> ===================== *snap* =====================
>
> This yields a purely marker plot (without lines) on a coordinate
> system where the y-coordinate is log-scaled. You see that the code is
> rather semantic and can easily be edited (which is think is the whole
> point of Pgfplots as opposed to pure TikZ).
>
> Now, if for a matplotlib plot I had query functions for the the axes
> ranges, ticks, grids, titles, data values, and so on and so forth, it
> would be a more or less complicated parsing of those and creating what
> we see above.
>
> However, it seems to me that the concept of backends is different.
> draw_path() would be called to plot the graph itself, the coordinate
> axes, and basically everything that resembles a line, giving its
> outline (color, shape, markers, start and end points) but *no*
> semantic information, that is, whether the path is part of an axis, an
> arrow or whatever.
> Is that correct?
> 
Yes -- the backend interface is designed for "dumber" output formats 
that don't know anything about the semantics of plots -- PDF, PS, SVG 
etc. are basically "draw a line here, put some text there" sorts of 
things. Of course, you could probably write a TikZ backend without much 
semantic detail fairly easily.
> Considering this, what do matplotlob masterbrains :) think would be a
> good way to extract Pgfplots code out of a matplotlib figure? Is a
> backend feasible at all? Would a function as "matplotlib2tikz(
> myFigure )" be more advisable, making use of all sorts of query
> functions? (Such as myFigure.axes.get_xlim() -- Does something like
> that exist at all?)
> 
That sounds more feasible -- however, keep in mind that anything without 
a public interface (a get_* method) is free to change in a future 
version of matplotlib. I suspect (though haven't thought it all the way 
through) that you may be required to dig into private members to get 
everything you need. I also suspect that this will be a lot of work to 
support all of the kinds of plots that matplotlib supports, and problems 
are likely to arise when the semantics of Pgfplot and/or TikZ don't mesh 
well. For example, does Pgf plot support the same set of nonlinear 
transformations as matplotlib?
Other people have suggested TikZ support in the past, and I, personally, 
haven't been very convinced of the usefulness of such a thing. It's 
just as easy to include a PDF or EPS in LaTeX, and the mathtext and/or 
usetex functionality goes a long way to making the plots blend in nicely 
-- though it does take some care to control the size of the plots to 
make the font sizes match, it's by no means impossible. Jae-Joon's work 
with fancy arrow styles brings in a lot of the finesse features of TikZ 
to matplotlib. What do you see as the use cases for a TikZ backend?
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
I'm looking into replacing my MATLAB(R) plotting routines by something
slicker, and quite naturally found matplotlib. It has all the
capabilities that I would need, except that I can't yet transform my
plots into TikZ.
For MATLAB(R), I used this rather elaborate script
<http://win.ua.ac.be/~nschloe/content/matlab2tikz>.
Well, I thought I can just go ahead and start writing and equivalent
backend; the documentation is really nice and clear (quite unlike
MATLAB's!) so it was no big problem to get into the concepts of the
backend. I played around a little and thought about how I could
implement this and that, and some questions arose which can maybe best
answered here.
For the sake of clarity, let me just give a snippet of Pgfplots (TikZ)
code that I would like the backend to produce
===================== *snip* =====================
[...]
\begin{semilogyaxis}
[axis on top,
xtick={2,4,6,8,10,12,14,16},
ytick={1e-15,1e-10,1e-05,1,100000},
xmin=0.000000e+00,xmax=1.700000e+01,
ymin=1.000000e-15,ymax=1.000000e+05,
xmajorgrids,
ymajorgrids,
title={$\norm{F(\psi)}_2$},
xlabel={$k$},
width=\figurewidth,
height=\figureheight,
scale only axis
]
% Line plot
\addplot [color=red,only marks,mark=*,mark options={solid,fill=red}]
coordinates{
 (1.000000e+00,3.206000e+01) (2.000000e+00,3.860000e+01)
(3.000000e+00,1.421000e+03) (4.000000e+00,4.143000e+02)
(5.000000e+00,1.445000e+02) (6.000000e+00,3.775000e+01)
(7.000000e+00,7.455000e+00) (8.000000e+00,7.228000e-01)
(9.000000e+00,2.275000e-02) (1.000000e+01,4.953000e-05)
(1.100000e+01,9.718000e-10) (1.200000e+01,5.534000e-07)
(1.300000e+01,4.217000e-11) (1.400000e+01,3.930000e-03)
(1.500000e+01,2.067000e-07) (1.600000e+01,7.231000e-12)
};
\end{semilogyaxis}
[...]
===================== *snap* =====================
This yields a purely marker plot (without lines) on a coordinate
system where the y-coordinate is log-scaled. You see that the code is
rather semantic and can easily be edited (which is think is the whole
point of Pgfplots as opposed to pure TikZ).
Now, if for a matplotlib plot I had query functions for the the axes
ranges, ticks, grids, titles, data values, and so on and so forth, it
would be a more or less complicated parsing of those and creating what
we see above.
However, it seems to me that the concept of backends is different.
draw_path() would be called to plot the graph itself, the coordinate
axes, and basically everything that resembles a line, giving its
outline (color, shape, markers, start and end points) but *no*
semantic information, that is, whether the path is part of an axis, an
arrow or whatever.
Is that correct?
Considering this, what do matplotlob masterbrains :) think would be a
good way to extract Pgfplots code out of a matplotlib figure? Is a
backend feasible at all? Would a function as "matplotlib2tikz(
myFigure )" be more advisable, making use of all sorts of query
functions? (Such as myFigure.axes.get_xlim() -- Does something like
that exist at all?)
Cheers,
Nico