Re: [changeset] print() options not working

[John W. Eaton]

On 29-Jan-2009, Ben Abbott wrote:

| On Wednesday, January 28, 2009, at 05:59PM, "Jim H" <address@hidden> wrote:
| >
| >print() works for me in octave 3.0.3 and gnuplot 4.2.2.  But there is a
| >caveat:
| >
| >* With my gnuplot, I have to give the file type in uppercase:  '-dPDF',
| >otherwise gnuplot complains that the terminal type is unknown.  If this is
| >also true for others users, then perhaps the keepers of the manual updates
| >can make a mental note to mention this in later editions.  Confusingly, "set
| >terminal" in gnuplot shows all terminals in lowercase and does not include
| >jpeg, pdf, etc. but the gnuplot command generated by octave "set terminal
| >XXXX..." does work.  So there is something odd about the online gnuplot
| >help.
| >
| >-Jim
| >
| 
| I get a different result.
| 
| octave:6> plot(1:10)
| octave:7> print('test.pdf','-dpdf')
| 
| This produces a pdf. However using "-dPDF" ...
| 
| octave:8> print('test.pdf','-dPDF')
| sh: convert: command not found
| error: print: could not convert
| error: evaluating if command near line 422, column 5
| error: evaluating if command near line 418, column 3
| error: called from `print' in file `/sw/share/octave/3.0.3/m/plot/print.m'
| 
| What do you get when you type "which print"?

The print function has a list of terminals that it expects gnuplot
to handle directly.  The string "pdf" is in that list.  If you call
print with -dpdf, then the print function sends a "set term pdf"
command to gnuplot.  If your copy of gnuplot was not compiled with pdf
support, then it fails.  If you use -dPDF, then the print function
will not find "PDF" in its list of terminals, so it will use gnuplot
to generate postscript and then call the external command "convert"
(from ImageMagick) to create a PDF file.  If your system doesn't have
"convert", then you see the message from the shell.  If "convert" does
exist and you have specified an unknown format, then I suppose that
will also fail.

It might be better to attempt to get the list of supported terminals
directly from gnuplot and use that (I guess you would need to send a
"set term" command to gnuplot and then parse the output).  Then the
print function would not attempt to use "pdf" if it determined that
gnuplot did not support the pdf terminal type and it would generate
postscript and call convert to do the conversion.  Maybe we should
also try to do a better job of handling the case of "convert"
missing.

I'd consider a patch.

jwe