[Matplotlib-users] Re: doing tex support the right way

Development matplotlib-devel
1

While the gnuplot approach of outputing an eps file plus a tex file
that does all the axis labeling is probably lots easier to implement,
I am nervous that if the tex file ever gets seperated from the eps
file, I am left with a plot with no axis or tick mark labels - or
labels that were accidentally editted. That may not be a big enough
concern to justify the extra work to parse the dvi, but it is a
concern of mine.

It may be irrational on my part, but something about a single eps file
feels cleaner to me than the seperate eps and tex file approach.

Ryan

···

On 1/23/06, Matt Newville <newville@...192...> wrote:

Hi Darren,

It may be very different than what you're doing, but the hybrid
approach of gnuplot's 'pslatex' terminal device might be worth
considering and looking into. This writes postscript for the graphics
part and leaves simple lines (for the axes) and the text as plain
latex that overlays the postscript. I think for mpl, you might want
to have all the non-text go into the postscript and all the text go
into an accompanying latex file, but the idea is the same.

One advantage there is portability, as the output is latex+embedded
postscript (using \special). It also allows pretty fine-grained
control on the output, including changing fonts or doing latex things
that mpl can't do (and this can all be done after the fact, so that
you can create the figure, and then change the fonts). It does
require latex to create the figure, but this step could be automated,
at least to stage of the dvi-with-eps-figure stage. Getting to ps,
pdf, or png would be less easy to automate but may be doable in a
portable way.

That sounds easier than parsing a dvi file to me. And postscript
backend already exists.

--Matt

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

2

While the gnuplot approach of outputing an eps file plus a tex file
that does all the axis labeling is probably lots easier to implement,
I am nervous that if the tex file ever gets seperated from the eps
file, I am left with a plot with no axis or tick mark labels - or
labels that were accidentally editted. That may not be a big enough
concern to justify the extra work to parse the dvi, but it is a
concern of mine.

It may be irrational on my part, but something about a single eps file
feels cleaner to me than the seperate eps and tex file approach.

Actually, this was what the first incarnation of usetex looked like: a ps file
and a separate latex file. In fact, it still does that, but I put a lot of
work into hiding that from the user and making mpl do the extra work behind
the scenes to deliver a single eps file. I didnt like the idea of having to
insert an eps file and some latex code on top of it. What if the file is not
destined for a latex document? I might want to use the image with all the
fancy markup in a poster created with inkscape or adobe illustrator.

···

On Monday 23 January 2006 19:06, Ryan Krauss wrote:

On 1/23/06, Matt Newville <newville@...192...> wrote:
> Hi Darren,
>
> It may be very different than what you're doing, but the hybrid
> approach of gnuplot's 'pslatex' terminal device might be worth
> considering and looking into. This writes postscript for the graphics
> part and leaves simple lines (for the axes) and the text as plain
> latex that overlays the postscript. I think for mpl, you might want
> to have all the non-text go into the postscript and all the text go
> into an accompanying latex file, but the idea is the same.
>
> One advantage there is portability, as the output is latex+embedded
> postscript (using \special). It also allows pretty fine-grained
> control on the output, including changing fonts or doing latex things
> that mpl can't do (and this can all be done after the fact, so that
> you can create the figure, and then change the fonts). It does
> require latex to create the figure, but this step could be automated,
> at least to stage of the dvi-with-eps-figure stage. Getting to ps,
> pdf, or png would be less easy to automate but may be doable in a
> portable way.
>
> That sounds easier than parsing a dvi file to me. And postscript
> backend already exists.
>
>
> --Matt
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems? Stop! Download the new AJAX search engine that
> makes searching your log files as easy as surfing the web. DOWNLOAD
> SPLUNK! http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users@lists.sourceforge.net
> matplotlib-users List Signup and Options

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dd55@...143...
office: (607) 255-9894
fax: (607) 255-9001

3

Hi Darren,

It's reasonable to be concerned about having two files necessary to
make one plot. The gnuplot pslatex output doesn't do this: it writes
one output file that is essentially a latex "picture" environment
which includes an encapsulated postscript program for the "graphics
part" with a \special command, and uses \put(x,y){\makebox(0,0){TEXT}
for all the text. Since latex has a preferred orientation for text
flow, each piece of rotated text is handled with another \special
command. BTW, I was mistaken earlier when I said that axes were
drawn in latex with gnuplot's pslatex terminal -- they are included in
the postscript, and only text for axis labels and other text is added
in with latex. So I think that emulating this solution would not be
too hard.

The output latex files do not render a figure by themselves, as they
are intended to be used in-place in documents and latex insists on
exactly one \begin{document} / \end{document} pair. But it's trivial
to have a boilerplate outer latex file:

  \documentclass[11pt]{article}
  \usepackage{color,....}
  \pagestyle{empty}
  \begin{document}\begin{figure}{\input{fig.pstex}}\end{figure}\end{document}

for generating individual graphs, and then doing standard latex / dvips.

I am not necessarily advocating this as "the right way", but offer it
as a suggestion. I've made figures like this for many years. OK, I
admit that I still make many figures for papers and talks this way, as
I know gnuplot, have scripts I've used for years, and there are some
things I can do more easily in gnuplot/latex than mpl.

Advantages of this approach are that a) the latex is not interpreted
by gnuplot, but handed off to latex (any valid latex can be used),
and b) the output latex/postscript is easily hackable. The latex
parts (say, the labels) can be easily changed. Colors and linestyles
of the traces can also be changed simply by editng the postscript. Of
course, "Oh, just hack the postscript" is not what mpl should aspire
too, but it's nice to know it's there when you need it.

A sample gnuplot script and output pslatex are at
    http://cars9.uchicago.edu/~newville/Python/MPlot/gnuplot-pslatex/

I also put a python script gp2ps (which requires Gnuplot.py) I use to
turn gnuplot command files with latex labels into eps (using dvips)
and png (using ImageMagick's convert) outputs. Feel free to use this
any way you want, or ignore it. Again, I'm not saying that this is
"doing tex support the right way", but it might beat the headache of
relying on version-specific features of gs.

Cheers,

--Matt