octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fltk printing [changest]


From: Ben Abbott
Subject: Re: fltk printing [changest]
Date: Fri, 30 Jul 2010 08:03:07 -0400

On Jul 30, 2010, at 1:09 AM, Michael D Godfrey wrote:

> On 07/29/2010 05:02 PM, Ben Abbott wrote:
>> I've pushed a changeset.
>> 
>>      
>> http://hg.savannah.gnu.org/hgweb/octave/rev/05ba991794d4
>> 
>> 
>> I've assumed that support for each of the formats, GL2PS_PS / PDF / TEX / 
>> SVG / PGF, will be included in the backend. Presently, only GL2PS_EPS is 
>> available.
>> 
>> The output for PS/PDF should respect the figure's papersize, 
>> paperorientation, and paperposition properties. The output for the 
>> EPS/SVG/TEX/PGF is limited to the box associated with the paperposition 
>> property.
>> 
>> Since eps is output is available, the changeset enables several other 
>> formats as well. Those include all aifm, dxf, emf, fig, gif, hpgl, jpeg, mf, 
>> png, pbm, and pstex. These output formats are obtained by converting eps 
>> using ghostscript, pstoedit, and fig2dev.
>> 
>> While pdf output will produce a full page of output, a figure proper for 
>> inclusion via pdflatex may be produced by ....
>> 
>>      print -dpdfwrite figure1.pdf
>> 
>> The gnuplot printing may be impacted. I'll begin looking at cleaning up 
>> __gnuplot_print__ so that is works in a manner consistent with 
>> __fltk_print__.m, but if someone finds a problem, please report it.
>> 
>> Ben
>> 
>> 
>> 
> Basically, this looks good to me.  Obviously, some more needs to be done, but 
> should be a better
> framework than before.  
> 
> One point: is using  print -dpdfwrite figure1.pdf a good idea for pdf?  I  
> looked at the new code
> before noticing that this was the intended syntax for getting pdf, so I 
> patched in code that
> generates pdf using print -dpdf  figure1.  pdfwrite has to be set in the call 
> to gs  to produce -sDEVICE=pdfwrite,
> but it seems to me that this should be done internally based on the user 
> saying just -dpdf or just figure1.pdf.
> 
> Anyhow, good start!!
> 
> Michael

I intended "-dpdf" and "-dpdfwrite" to give different results.

Using "-dpdf" will produce an 8.5x11in page with the figure inside the box 
defined by the paperposition property. With the current fltk backend, this 
doesn't work correctly. The only backend format/output available is 640x480 pt 
eps (GL2PS_EPS). Thus "-dpdf" currently produces an eps file. Once the backend 
supports GL2PS_PDF, then pdf output will be available.

At present, using "-pdfwrite" will produce output that is always 640x480 pts 
(it is cropped at the eps bbox). This approach can be used to produce figures 
for pdflatex.

In short, I think the m-file part is working correctly for the fltk backend, 
but the fltk backend only allows for eps output with a bbox of 640x480. If the 
selected devices requires an eps file (for conversion by gs, pstoedit, and 
fig2dev) then you'll get what you want, but it will always be 640x480 pts in 
size. If you ask for ps/pdf/tikz/svg, you'll get an eps file that is 640x480 
pts in size.

Ben





reply via email to

[Prev in Thread] Current Thread [Next in Thread]