Re: [Printing-architecture] [gsl-dev] The Common Printing Dialog and PDF as standard print job format in OpenOffice.org

Re: [Printing-architecture] [gsl-dev] The Common Printing Dialog and PDF as standard print job format in OpenOffice.org

[Till Kamppeter]

Philipp Lohmann wrote:
> I have ot yet seen through all the references you gave, but some initial 
> questions occured to me.
> 
> - There does not seem to be an implementation either in gtk+ or KDE/Qt 
> mentioned yet. Would you want to use a gtk dialog then ? This would be 
> easily done when using the gtk plugin, however less trivial in the Qt 
> plugin or the native X plugin (because the latter two do not run any 
> kind of toolkit "native" event queue). Or would there be an 
> implementation using OOo's native toolkit VCL ? That would seem to 
> contradict the idea of having a system wide dialog however. OTOH this 
> would work out of the box on all our plaforms.
>

The dialog implementation is currently in the works by one GSoC student 
(Alexander Wauck). Another student (Lars Uebernickel) is working on a 
DBUS interface between dialog and application. The dialog will be a 
plug-in coupled via DBUS (and additional socket for high-volume data 
transfer). So no dialog needs to be coded for OOo, also OOo does not 
need to be linked with additional GUI toolkit libraries. Any dialog 
using Lars' interface will work with OOo, independently which GUI 
toolkit it uses.

Lars (CCed) will work together with you on adding the DBUS interface to 
OOo. Please let the right people contact him.

> - The dialog provides a preview feature. We can do this similar to the 
> current MacPort native dialog, which implementationwise comes up after 
> OOo has prepared the whole document for printing. This is a little 
> awkward because the whole document is held in memory for, however until 
> we change our applications to give up the "push" model they currently 
> employ, this is the only way we can provide this kind of preview 
> functionality. However how would the preview actually work ? What API 
> would be used to render the page content to the preview ?
> 

See

http://www.linuxfoundation.org/en/OpenPrinting/Specifications

and

http://www.linuxfoundation.org/en/OpenPrinting/Requirements

Lars will update these pages regularly.

> Actually the biggest advantage I see here would be that CUPS could now 
> support print jobs containing multiple page formats (like e.g. a letter 
> with one page being the envelope) as PDF has the possibility to size 
> every page. Will that be possible ? The other big advantage is to 
> reliably use transparency.

CUPS does not nail down the page size for the job. A change of the page 
size in the middle of a job should not be a problem if the printer is 
configured to select the tray by page size.

    Till