Re: fltk printing [changest]

[bpabbott]

On 30 Jul, 2010,at 09:56 AM, Shai Ayal <address@hidden> wrote:

On Fri, Jul 30, 2010 at 3:03 PM, Ben Abbott <address@hidden> wrote:
> 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.
>
gl2ps should produce a bounding box which is the size of the figure
window. Is your figure window 640x480? does the bounding box change if
you resize the figure window?

Shai

 

opps!

It appears that the gl2ps output doesn't work properly for me unless I change the figure's position property from its initial value ... i.e. the same MacOS X *feature* that prevents the status bar from showing up, results in the wrong image size.

With the status bar visible, the bbox is "%%BoundingBox: 0 0 560 422", which is close to what is expected.

    octave:15> get (gcf, "position")

    ans =   961   149   560   420

When the status bar isn't present the bbox is "%%BoundingBox: 0 0 640 460", not 640x480 as I wrote above.

In any event, does gl2ps output always conform to the size of the figure window? Or in other words, do we need to change the window size in order to have the output match the paperposition property? What of ps/pdf output? Will the pagesize, in points, reflect the figure size, in pixels?

If "yes" to all, then I think we should place the code needed to produce the proper figure size into __fltk_print__.m.

Ben