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.
On 1/23/06, Matt Newville <newville@...192...> wrote:
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
That sounds easier than parsing a dvi file to me. And postscript
backend already exists.
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!
Matplotlib-users mailing list