Bug 177360

> Advanced printer properities come up blank, I know there are some.

This seems related to the fact that the "print to files" options are disabled.
Anyway, Qt bug.

Is this also a problem in other KDE and Qt apps?  Or is it solely Okular (and thus probably something triggered by not having print-to-file enabled)?  Everything to do with printer properties, printer detection, talking to CUPS, etc is handled by Qt, so you will need to raise a bug in their tracker at http://trolltech.com/developer/task-tracker.

Thanks!

Ref Comment#2: I filed a bug report with QT earlier this morning. Since I only have Okular installed I have no other PDF application to test with. Used to use KPDF but its not available for my X64 OS (OpenSUSE 11.0) Other documents from OpenOffice 3.0, Konqueror, Konsole and lpr all print fine.

My main problem is a downloaded PDFSERVLET.zo document. with KDE 3.5.9 I'd load it into KPDF, Save it as a .PDF, then use PDFtoPS, and print the ps version. Just trying to print the .zo to my Xerox Phaser_6120 hangs the printer. I've wated two hours and it never printed, I have to power down the printer and some times the system to free it

Thanks for your response. is there a way to enable the print to file and see if things work?

Do other KDE or Qt apps have this problem when printing other types of documents, e.g. kwrite when printing text?

You can't turn print to file on in okular, it's an option we can't support at this time.

(In reply to comment #4)
> Do other KDE or Qt apps have this problem when printing other types of
> documents, e.g. kwrite when printing text?
> 
> You can't turn print to file on in okular, it's an option we can't support at
> this time.
> 

See comment #3 other applications and documents seem to work fine. All so I just tried something different. I took the PDFServlet.zo document, used PDFTOPS to create a ps document, opened it in Okular and then went to print where it had correct margins, and file-->print-->properities-->advanced had the correct additional printer options.

It appeard the problem is just a .pdf or .zo document that does not see options and margins correctly. If it is the print to file causing this I can live with the above work around until that problem is solved.

Thanks for all your responses.

Could you provide a sample file?  e-mail me direct if you don't want to attach to the bug report.

I've just hacked up Print to File support for PDF, so I'll be able to tell if its a problem with the document or the Qt print support.

John not sure what kind of sample you want. it is 
 Okular 0.7.3 using KDE 4.1.3 now release 68. 1

It does it with any PDF file.

If I convert the pdf file to ps (pdftops) and then open the ps file with Okular, the margins and advanced options appear. I have attached a PDF that does it. 

 steps:
  open PDF with Okular
  select file --> print
  printer name is Phaser_6120 
  select properties
  the page tab shows incorrect page size A4 when page is actually letter and incorrect margins (should all be .17 instead of 1.XXX). 
  the Advanced tab show blank information.

Again thanks for all your help.

Created attachment 29305 [details]
pdf file that does not print correctly

see comment above on steps.

Created attachment 29306 [details]
ps file tha prints correctly and with correct properties.

used pdftops to create from above pdf file sent to list.

*** Bug 177779 has been marked as a duplicate of this bug. ***

*** Bug 174324 has been marked as a duplicate of this bug. ***

Russ, I thought you meant that only the PDF's you got from the PDFServlet.zo thingy were a problem, not all of them, but I've actually just tried to print my own pdf's and I can see the problem is for all pdf's.  Running okular under 4.2 where I've added support for print to file it's ok.  I suspect if you have 2 real printers installed then switching from one to the other and back again will work around it, but I don't have a printer handy to test right now.

Definitely a Qt bug then, can't see any reports in the Qt tracker so raised as new issue, awaiting response.

I suspect it is related to bug https://bugs.kde.org/show_bug.cgi?id=177544 where the Print to File bits of the dialog don't get initialised correctly.

I have created a new task on the Qt bug tracker about the issue of the Advanced panel: http://trolltech.com/developer/task-tracker/index_html?id=238661&method=entry

I'm still investigating about the problem of printer default properties.

I checked about the printer properties, and I have not found a problem there (apart from the problem with the advanced panel)...

*** Bug 177000 has been marked as a duplicate of this bug. ***

I can confirm the problem with the Page properties tab too, it displays default values for Paper Size and Margins instead of the proper PPD values.  If you set you CUPS printer options to be Letter then you will see the Page tab shows A4 by mistake as that is the default.  I'm guessing that the PPD values are not being retrieved for the printer, possibly because the dialog thinks it actually has a Print to File?  

Thanks John, glad to hear it wasn't just me. If I can be of any assistance testing  an fixes, let me know. 

I appreciate all the help.

I just reported this for openSUSE 11.1.
https://bugzilla.novell.com/show_bug.cgi?id=462833

The options not appearing can be "fixed" by adding a second printer and then select the second and then the first again. 

Btw. It does work to print a *.jpg from okular... So this is bug #162793 again.

I can confirm this much: Okular is the only program I have encountered that exhibits this problem, and even then only for trying to print PDF files.  By contrast, when using Okular to print PostScript, EPS, PNG, GIF, TIFF, and JPG files; the correct paper size (e.g., Letter) has been selected by default and the Advanced tab shows the PPD options.  (Other KDE4 programs, such as KWrite, Konquerer, and Gwenview; all behave properly when printing.)

Could anyone enlighten me how this is a QT issue if all those other programs work fine AND PDF files are the only type that exhibit this behavior (so far as I can see via experimentation)?  Are there any other programs that exhibit this behavior?

Trying to consolidate what seem to be duplicate bugs.  Bug #174354 and Bug #176999 seem to be describing this same problem.

openSUSE 11.1

(In reply to comment #19)
> Could anyone enlighten me how this is a QT issue if all those other programs
> work fine AND PDF files are the only type that exhibit this behavior (so far as
> I can see via experimentation)?  Are there any other programs that exhibit this
> behavior?
Have a look at http://trolltech.com/developer/task-tracker/index_html?id=238661&method=entry.

okular is the only program i know which prohibits printing to PDF/PS. (printDialog.setOption(QAbstractPrintDialog::PrintToFile, false);) Therefore all other programs have two entries more in the list. Without these entries the advanced options are not shown. There already was a problem with these being disabled in bug #162793.

@letc  As explained above, this is a Qt bug that is only exposed when the application disables the 'Print to File' options.  No other KDE app does this, and every other Okular supported file format except DVI does not do this.  Only Okular PDF and DVI formats disabled Print to File as we had no support for printing to PDF, as the print output is postscript based.  We now have Print to PDF support using ps2pdf in the background so this problem will be resolved with either the next 4.1.x release, the 4.2 release, or the Qt bug fix, whichever comes first.

#174354 does appear to be a duplicate but confirmation is needed, but #176999 is two other issues.

Huh? Why do we have to convert a PDF to PostScript and back to PDF to print it to a PDF? Can't this done in a more direct way? Going through PostScript makes sense for DVI, but why for PDF?

Well, a number of technical reasons.  First up, the Poppler library that we use for rendering PDF's doesn't yet support output to PDF, i.e. if you choose to print only pages 3 to 5 of a PDF then poppler will output a ps file with the result.  Secondly,  we can't use the screen render as the basis of the printed output as this is low resolution and would look a mess compared to the original.  Finally, even if you wanted the entire PDF printed, Qt doesn't support directly printing files, so we have to submit the file directly to CUPS in the background.

Thanks for explaining this John. My work around is convert the pdf to ps and then use the lpr command to print the file to my ps printer (Xerox 6120 Phaser).
It has been working OK that way so I can wait for a fix. 

Qt tracker has bug marked as fixed and due for release in 4.5.0.  We also avoid this bug in latest versions of Okular now by supporting print to PDF.

Thats great. Thanks for all your help. I'll either get an RPM from openSUSE or see If In get a source from QT and compile it. I assume Okular will also need recompiling. I just installed opensuse 11.1 but it has 4.4.3.

Whats the latest verssion of Okular? I was think of trying 4.2 since its available in the unstable version on openSUSE.

Again thanks for all your help.

Qt 4.5.0 won't be released for another 2 months or so.  Better to wait for KDE 4.1.4 or 4.2.0 (RC1 or later).

John: 
I am not into Qt development.
Bug #162793 was similar and fixed by Trolltech/Nokia/Qt Software and a patch was added to qt-copy. I am not sure if distributions will upgrade KDE/okular to KDE 4.1.4.
So is the Qt Patch available somewhere?

*** Bug 180280 has been marked as a duplicate of this bug. ***

Fedora will provide KDE 4.1.4 as an update (it's already queued for updates-testing). KDE 4.2 and Qt 4.5 will probably both be pushed out as well when they're ready.

That said, can't the fix for the Qt bug be added to qt-copy? We'd pick it up from there.

I believe openSUSE and Kubuntu either have 4.1.4 available now or will have as soon as their build farms get done.  I expect most other major distro's and a fair few minor ones to do the same.  qt-copy will also likely be switching to 4.5.0 not long after KDE 4.2 gets released.  So I don't think a patch will be worth it.  If anyone does we would need to ask Benjamin at Qt for the diff file.

*** Bug 174354 has been marked as a duplicate of this bug. ***

John just to let you know I installed KDE 4.2 with Okular 0.8. When I load a PDF document it now displays the correct page type (letter) and margins. when I go to the print properities advanced all my printer options are now shown. and selectable.

Thanks for your help on getting this resolved. I'm using QT 4-4.4 from the openSUSE respositories. Also thank the team for me. 

*** Bug 177000 has been marked as a duplicate of this bug. ***

John This appears fixed in Okular version 0.8 KDE 4.2 release 88.2 and .4.
libQtWebKit4-4.4.3+20090129-2.1

At least its working on the latest openSUSE version. I have not tried the Qt4.5 to see if its Ok. Even prints without hanging printer.

*** Bug 177000 has been marked as a duplicate of this bug. ***

(In reply to comment #35)
> John This appears fixed in Okular version 0.8 KDE 4.2 release 88.2 and .4.
> libQtWebKit4-4.4.3+20090129-2.1
> 
> At least its working on the latest openSUSE version. I have not tried the Qt4.5
> to see if its Ok. Even prints without hanging printer.

> When trying to print a PDF file, printer settings for Okular are "stuck" at A4.
> Cannot find way to change default to US Letter
...
> Now fixed upstream for forthcoming Qt 4.5.0, but also bypassed in forthcoming
> KDE 4.2 and KDE 4.1.4 releases.

i'm seeing exactly the same behavior on openSUSE 11.1, with KDE sourced from
the KDE 'Factory' repo mix:

 .../KDE:/KDE4:/Community/openSUSE_11.1_KDE4_Factory_Desktop/
 .../KDE:/KDE4:/Factory:/Desktop/openSUSE_11.1/
 .../KDE:/KDE4:/Factory:/Extra-Apps/openSUSE_11.1/
 .../KDE:/Qt/openSUSE_11.1

including, in particular,

    kde4-okular-4.2.1-83.1
    libqt4-4.5.0-43.1
    libQtWebKit4-4.5.0-45.1

which doesn't yet look 'fixed' ... _is_ the fix "in"?

(In reply to comment #37)
> which doesn't yet look 'fixed' ... _is_ the fix "in"?

In Qt? Looks not.
Anyway, the "Qt print dialog ignores KDE paper size settings" bug is #174354.