Example plot in Manual lacks text

[Ben Abbott]

On Tuesday, April 07, 2009, at 01:51PM, "Michael D. Godfrey" <godfrey at isl.stanford.edu> wrote:
>>
>> How can we determine if "convert.exe" exists for Windows?
>It is likely that Windows has a "which" command.  We need a windows
>expert...
>
>In any case, it would be good to remove "pdf" from the terminal list
>for gnuplot 4.2.3  (in fact for all 4.2 versions) since now the use of "pdf"
>just crashes.
>
>Is ghostscript required for windows, or is there some other way to
>generate the manual?  If ghostscript is required and it is not possible to
>test for convert, then I would say just use gs instead of convert.  I tested
>both and they both work.
>
>I am copying John on this in case he has a definite preference.
>For jwe:  the background is:  currently Octave fails on print("xxx.pdf")
>for systems running gnuplot 4.2.xx.  The reason for this is that the 4.2
>gnuplots do not have a terminal type pdf.  The 4.2 Manual says that pdf
>is supported, but it is not true.  (Also, the gnuplot web page lists 
>support for
>pdf as a new feature in 4.3.)  Currently, the print command has code that
>runs "convert" in cases such that gnuplot does not have the terminal type,
>but convert can make the conversion from a type supported by gnuplot.
>Neither Ben nor I know if this code works on Windows systems, which may
>not have "convert."  I ran a test replacing the "convert" call with 
>"gs."  This
>also works.  So, I have recommended:
>
>1. Remove the pdf type as a type supported by gnuplot 4.2.xx.  This
>    fixes the error when using print("xxx.pdf") in systems that have 
>"convert."
>    The current code assumes that "convert" exists in any case.
>
>2. Consider switching from "convert" to "gs."  This is known to work for
>    the pdf case in systems that have "gs" (Ghostscript).  This must be most
>    supported systems since the install process assumes Ghostscript.  
>(Used for
>    the Figures in the Manual.  And, it would be nice to have the 
>Figures in the
>    Manual generated the same way that the example code would run for users.
>    Until you made the recent change from png to pdf, the code in the Manual
>    did not produce the Figure shown in the Manual.)   However, this change
>    would need to be tested for all cases that end up calling the convert
>    code.
>
>Do you have a preference about this?
>

Regarding producing pdf output like is in the manual, this will not be possible unless the code for producing the figures for the manual is modified or the goal of Matlab compatibility is sacrificed ... thus, I think we need to give that goal futher thought.

Regarding the rest, I'll try to put a changeset together and post it to the list.

Ben