updated print.m

[Ben Abbott]

On Monday, April 20, 2009, at 03:22PM, "John W. Eaton" <jwe at octave.org> wrote:
>On 10-Apr-2009, Ben Abbott wrote:
>
>| I've pushed a changeset that addresses some of the troubles reported  
>| for printing, and have tried to cc all that reported problems.
>| 
>| With this changeset in place, only postscript and pdf output are  
>| assumed to target a printed page. All other outputs (eps, emf, png,  
>| etc) will render an image the size indicated by the figure's  
>| paperposition property.
>| 
>| Regarding pdf output, some linux variants do not have a "pdf" terminal  
>| included. In the event gnuplot does not directly support pdf output a  
>| check is made to see if "convert" is present. If so, a postscript page  
>| is produced and "convert" is used to render the desired pdf output.
>| 
>| I've also updated the help text  for print.m and made some changes to  
>| clarify the code.
>
>Does calling convert work properly on Windows systems?  Do we want the
>run-time dependency on ImageMagick?  Would it be better to depend on
>ghostscript instead?
>
>jwe

As I don't have any experience with Windows, I encourage those who use Windows to respond.

Regarding the run-time dependency, would it be preferred to use GraphicsMagick instead? (which I do not have installed).

I've not used gs except for simple tasks. One issue I haven't looked into is how to tell gs to crop an image according to an eps-file's bounding box. I don't know if or how ImageMagick does this, but thought the question should be raised (the eps files produced by gnuplot imply a convas that have a 50pt margin around the bounding box).

Ben