Nice plots for TeX in windows environments?

[John W. Eaton]

On  5-Oct-2007, Schirmacher, Rolf wrote:

| I want to use octave/gnuplot plots for latex documents and as I have to work
| on an win xp machine, the most convenient way is to use pdf(la)tex directly,
| i.e. no dvi/ps/... postprocessing. pdf(la)tex supports pdf, png and jpeg
| directly, but no ps, etc.
| 
| As I am thinking about high quality graphics, jpeg is not well suited for
| plots (it is for photos, not for line drawings). pdf would be perfect, but
| there seems to be no pdf terminal device / print support in the 2.9.13
| binary distribution of octave. So, png is the only way to go (at least, if
| you do not want to do any intermediate or post processing)
| 
| The default png output is 800x600 pixle which is fine for some on-screen
| display  but is totally not sufficient for high quality plots. In addition
| to (largely) increasing the resolution of the plot, something like adapting
| the linewith and fontsize would be fine as all these quantities also seem to
| be attributed in "pixel" and do not seem to have any idea of "resolution".
| 
| Is there any simple and direct method to convince octave/gnuplot to produce
| a high resolution, pdf(la)texable plot without extra
| re-formatting/postprocessing in a "standard" windows environment?

Use the epslatex terminal type and convert the EPS parts to PDF using
something like epstopdf, or (gasp) acro-something-or-other.  A quick
trip to google turned up this page:

  http://centaur.maths.qmw.ac.uk/Info/pdf-faq.html#Windows

which should give you some ideas about what can be done about the
conversion step on Windows systems.

If you have epstopdf set up, then epstopdf.sty can even automatically
convert the EPS file to PDF for you when pdflatex processes your
source file.  However, the last I checked, it doesn't notice when a
converted PDF file is out of date with respect to the corresponding
EPS file.  I prefer to use some Makefile rules to handle the
conversion and keep everything up to date.

I know this method requires a "postprocessing" step, but it think it
will give you *much* better results than using some bitmap format.

| What is the current state of implementing some idea of physical size and
| resolution to the plotting/printing frontend? To me, it looks like the only
| "paper"-like property of a figure currently is the PaperOrientation, but
| PaperType, PaperPosition, etc. are missing and print.m seems to have no idea
| about "resolution".

I don't recall seeing any patches for this.

jwe