Re: Highlevel printing API - proposal

В Срд, 25/01/2006 в 19:32 +0100, Alexander Larsson пишет:
> On the summit owen and some people hacked up a proposal for a Gtk+
> printing API. It is availible in libegg/libegg/print in cvs. Having
> looked at various other APIs and platform requirements I have a
> different idea of how such a highlevel API could look. 
> Attached is a example implementation of the API ideas. Look at
> testprint.c and testprintfileoperation.c to see how it is used.
> The basic idea is that each time you want to print (i.e. when the user
> selects File->Print) you create a new GtkPrintOperation, set various
> information on it like:
> * default page settings (size, orientation etc)
> * initial printer settings (from last print)
> * various settings controlling the print operation
> Then you kick off the operation, with egg_print_operation_run(). We then
> display a print dialog (if requested), and create a cairo context for
> the correct printing backend. Then various signals are emitted on the
> EggPrintOperation:
> begin_print: emitted at start, here you can e.g. allocate resources
> request_page_settings: emitted before page rendering, letting you change
>                        the page settings on a per-page basis
> draw_page: render the page nr given, return FALSE if no such page (you
>            can hint on the nr of pages with
>            egg_print_operation_set_nr_of_pages)
> end_print: emitted at end, even if cancelled, here you can free  
>            resources
> When this is done the job is sent to the spooler, and the function
> returns. We could add some form of feedback on the printing progress as
> other signals on the object. At this point you should get the new
> printer settings object and save that for the next print operation.
> Another way to use this API is to subclass EggPrintOperation, like the
> TestPrintFileOperation class in the example code.
> Opinions on this?

It would be useful for evince to have the ability to print postscript
file created by external libraries but use standard dialog for print
settings configuration. I think other apps which print to postscript
first will require such ability.

Although I don't know exactly, probably the solution will be in creation
of the ghostscript's cairo backend and convertion postscript to cairo
commands first (to convert them back to postscript later)

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