Hi,
Till Kamppeter wrote:
The interface is designed and implemented by Lars Uebernickel, one of
the Google Summer of Code students [7]. The specs for this interface are
work in progress on [4]. Requirements are written up on [5]. This
interface needs also to be implemented in the applications and/or their
common GUI libraries, in our case OpenOffice.org. Lars will work on
patching the application, but these patches should not only go into
packages of Linux distributions but also into the upstream software
repositories. So I ask you for working together with Lars to make these
patches also part of the upstream code.
Patches should only be used as a backport of a feature from a future
software version to the software in the current version of a
distribution (in the case the software currently under development will
not make it into the next releases of the distros).
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 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 ?
PDF as the Standard Print Job Format
------------------------------------
To improve the reliability of the printing process, especially for
complex graphics, high color depths, and for jobs where pages get
separated and reordered (2 pages per sheet, booklets, selected pages,
...) we are switching from PostScript to PDF as standard print job format.
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.
On the client (application) side it is needed that the applications
generate the print jobs in PDF and not in Postscript. This would mean a
change of the print job generation part of OpenOffice.org. As
OpenOffice.org has an excellent "Export to PDF" function, there will not
be needed much new code. One can use this functionality to generate
print jobs, using PDF settings optimized for printing.
New glue code to the printer should use vcl's PDFWriter class then.
Going the way around to the pdf export filter would be awkward. We could
move some specialized code (namely the mapping from the produce
metafiles to PDFWriter calls) from the filter into vcl if necessary to
achieve the most cost effective result.
So I am asking you whether you can change OpenOffice.org to make the
"Print" command emitting PDF instead of PostScript. To not break lagacy,
non-PDF-capable environments, make this a configurable option.
Certainly that's possible. Actually I think it will provide less of a
problem than the dialog since we have more of the parts already solved.
I am very grateful for any support from the OpenOffice.org side in terms
of these OpenPrinting projects. They will improve the printing workflow
a lot and will make many bugs and user complaints go away.
... and replace them with another set ;-) Whatever we do we'll not run
out of either bugs or complaints.
Kind regards, pl
--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
-- Author unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
