[changeset] improved support for pdf output (was: Example plot in Manual lacks text)

[Ben Abbott]

On Apr 7, 2009, at 4:02 PM, Ben Abbott wrote:

> 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

The attached changeset uses "convert" to produce pdf output on unix  
systems.

The motive is to permit Octave to produce pdf output when gnuplot  
4.2.x does not include a pdf terminal driver.

To do this a temporary postscript output is produced and  
"convert" (ImageMagick) is used to obtain the desired pdf result.

The implementation is intended to produce a result that is compatible  
with Matlab.

Michael, please give this a test drive. I won't push this until we've  
had more time to discuss the detail.

Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: changeset-pdf.patch
Type: application/octet-stream
Size: 10011 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090407/7d64cd1d/attachment.obj 
-------------- next part --------------