Apache OpenOffice (AOO) Bugzilla – Issue 94173
Let OpenOffice.org send the data in PDF format to the printing system
Last modified: 2010-11-01 11:30:12 UTC
I am Till Kamppeter, leader of the OpenPrinting work group at the Linux Foundation. As you can see on the page referenced above OpenPrinting has agreed on switching from PostScript to PDF as standard print job format. This decision was made between printing system and driver developers, application developers, desktop developers, and many major printer manufacturers. I want to ask you whether you can switch from PostScript to PDF as print job output format in the upcoming 3.0 series of OpenOffice.org. This should not be a big change as OOo is already capable of generating PDF via the "Export to PDF" function. This code could be re-used. It could also be done in a way that it is run-time configurable whether PostScript or PDF gets generated with default set at build time. This does not require all distributions to switch to a PDF-centric workflow as CUPS has a pdftops filter and so it converts the PDF input to PostScript if it does not have the filters for disrectly working with PDF. As you can also see on the referenced web page, KDE and Qt applications already send jobs in PDF and OpenPrinting has organized the development of the CUPS filters for the PDF printing workflow. Debian and Ubuntu already include CUPS packages with PDF-based printing workflow.
Yes, that can and should be done. We'll need however a method to query which format we actually should use as there are many systems out there which do not have the new PDF centric CUPS workflow but still prefer PostScript.
All CUPS systems from CUPS 1.2.x on can take PDF, independent whether they use the PDF work flow for the further processing or not. Therefore the Qt developers let Qt produce PDF if the system is Unix/Linux with CUPS 1.2.x or newer, otherwise PostScript.
So I think we should go the same way as in Qt also in OOo.
That sounds like a good plan.
Pinging about this issue again... https://www.linuxfoundation.org/en/OpenPrinting/PDF_as_Standard_Print_Job_Format
Ah, your setting this to 3.2 means, you are working on it and have a CWS ? I certainly am open for questions or help. However I currently don't have much time for implementing this, but if you have code already going, the more power to you.
So how is your CWS going ?
No I don't have a patch, sorry.
tentative target
started, CWS is pdfprint
What's nice: transparencies do not have to be handled specially since we can send a "normal" PDF file What's no so nice: at least my current OpenSuSE 11.3 CUPS handles jobs with multiple page sizes by scaling them; e.g. a Document with an A4 and an A3 page comes out as two A4 pages where the second is scaled down to A4. Ugh ! Do I need to do the same as on the mac (start a new job whenever the page size changes) or is there a sensible solution ?
Didn't find any option to handle multiple paper formats transparently, so I ended up starting a new job each time. I guess I need to do the same for differring input slots.
pl, the multiple page size problem I have already addressed, and it works at least in Ubuntu and Debian. I have modified pdftops of Poppler (and this is upstream in the current Poppler) adding the "-origpagesizes" option. pdftops called with this options does not change any page size, the resulting PostScript file is multiple page size like the original PDF file. I have also patched the pdftops CUPS filter to use the new option when calling pdftops of Poppler, but I am not sure whether my patch made it upstream into CUPS.
That's very good news ! Will there be a way to see from the API that I can rely on multiple page sizes work as expected ? Perhaps version info or a CUPS option ?
Unfortunately, the CUPS API does not propagate whether the filters allow multi-page-size jobs or not. My suggestion is to have a config file in /etc where distro packagers and also local system administrators can configure how print output should look like: PDF/PostScript? Are multi-page-size jobs supported (correct Poppler and CUPS installed)? The file could be pre-configured by the distro's packagers so that the data to be printed is sent to CUPS in the most suitable format.
That sounds like a good idea. I'd use that if and when available. In the meantime I'll assume PDF for CUPS >= 1.2 (which is guessed also :-) ) and that each of new page size or input lot needs to start a new job. I already built in using the "job-sheets=none" option for subsequent jobs in the hope of avoiding additional banner pages.
fixed in CWS pdfprint
@hi: please verify in CWS pdfprint A linux install set of the CWS can be found here: ftp://qa-upload.services.openoffice.org/pdfprint/linux-x86/OOo_DEV300m86_Linux_x86_install-arc_en-US.tar.gz I'll send a mail to dev@openoffice.org and dev@qa.openoffice.org so perhaps some people check whether they find problems with the change.
reopen, two issues came up - form controls occasionally get printed with wrong position/size - more important: on a SuSE 11.0 system text comes out as complete garbage although the PDF shows just fine in gs or acroread.
reassign
bugdoc was http://www.openoffice.org/nonav/issues/showattachment.cgi/66489/ManyObjects.odt , will attach produced PDF
Created attachment 71820 [details] produced PDF that prints wrong
I have tried to reproduce the problem of SUSE 11.0 printing garbage on my Ubuntu system. To make the filter chain the same as SUSE uses I have inhibited the PDF printing workflow by giving pdftopdf a cost value of 999. For me the file (many.pdf) prints correctly (PostScript supposed to go to the PostScript printer looks the same as the screen output of many.pdf with the Adobe Reader). So for me it looks like that this particular SUSE distribution has a problem with the fonts. My suggestion is to make the print output format (PostScript or PDF) configurable by the administrator or package, for example via a configuration file in /etc/.
That is a good solution for newer distributions (where the problem does not seem to occur anyway). Anyway people who get problems with the PDF printed version can fallback to PostScript using spadmin. I'll look into the shifted form control issue soon.
That control issue was due to differing resolution settings and the use of pixels as measurement for form controls. fixed in CWS pdfprint. The text issue we have found to be not on OOo's side; for this the user can set printing back to PostScript either in File->Print->Properties (per job) or in spadmin (persistent). Therefore I think the CWS can go back to "ready for QA"
Verified with cws pdfprint = ok
integrated in DEV300_m90 closing