octave-maintainers
[Top][All Lists]
Advanced

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

Re: Printing with QtHandles (Was: Fixing fltk printing)


From: Michael Goffioul
Subject: Re: Printing with QtHandles (Was: Fixing fltk printing)
Date: Tue, 15 Jan 2013 16:59:59 -0500

On Tue, Jan 15, 2013 at 4:21 PM, Ben Abbott <address@hidden> wrote:
On Jan 15, 2013, at 2:55 PM, Michael Goffioul wrote:

> On Tue, Jan 15, 2013 at 2:08 PM, Ben Abbott <address@hidden> wrote:
> On Jan 15, 2013, at 11:47 AM, Michael Goffioul wrote:
>
> > The gl2ps method seemed simplest at the time, but was never expected to work all that well.  It is slow and requires the plot to be visible.  And, you could be right that it causes the known race conditions.  It was worse, but various patches have made it better.  I do hope that some graphics expert can spend time on this to find a better method.
>
> <snip>
>
> > Also do not confuse backend/toolkit and renderer. The backend/toolkit provides the windowing system, while the renderer do the actual drawing on the graphics context provided by the toolkit. In theory, the same toolkit could use multiple renderers and I actually designed QtHandles that way (as well as JHandles), though it only support the OpenGL renderer at the moment.
> >
> > Michael.
>
> The lack of print() support for QtHandles had caught my attention.  If you're interested in working on that, I can handle the m-file part.  The m-file part should just involve changing from checking if the fltk toolkit is active to checking if OpenGL rendering is being used.  Of course, it will be necessary to add a function that is able to determine which renderer is active.  For now that can be done on the m-fie side of things by using a if-block or case-blcok.
>
> Indeed, QtHandles does not support printing yet. From the look at it, a large part (if not all) of __fltk_print__.m can be re-used. Also I don't see any strong assumption on the use of OpenGL in that file. It seems the only assumption is that the renderer will generate PS (or maybe EPS).
>
> Michael.

When the gl2ps was added, I decided to treat gnuplot and fltk as equilalents so that they share as much code as possible.  For example, both gnuplot and fltk (usually) output eps that is then piped through gs to produce most other formats.  So all that is (should be) needed from QtHandles is an eps-output and a way to specify the size in points.

There are some instances where gnuplot is asked to provide output other than eps (latex for example).  But, I think you are correct that the __fltk_print__.m only expects eps.

I suppose the simplest and safest approach would to be copy __fltk_print__.m to __qt_print__.m  and make the the renderer part of the toolkit?  Or is it safe to assume a cairo (something else?) renderer would work well for all OpenGL tooklits?


Actually, the print system shouldn't care at all (or as less as possible) about the renderer. It should simply ask for a given output format and do post-processing if required. Though one can imagine to have the output format coming out of the toolkit being dependent on the active renderer, initially it would always be EPS.

At the moment, I don't even think there's a need to __qt_print__.m, as it defaults to __fltk_print__.m for any toolkit other than gnuplot. So the only thing that would be required from QtHandles is the ability to generate EPS, in other words to implement graphics_toolkit::print_figure(). There's a slight complication in QtHandles, compared to FLTK, that it runs in a separate thread, so synchronization will be required.

I'll try to have a look when I get some time, but I'm quite busy with classdef at the moment.

Michael.


reply via email to

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