Summary: | kpdf+kghostview should not show "Margins" tab in kprinter (see how it is disabled for KWord) | ||
---|---|---|---|
Product: | [Unmaintained] kpdf | Reporter: | S. Burmeister <sven.burmeister> |
Component: | general | Assignee: | Albert Astals Cid <aacid> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | All | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
S. Burmeister
2006-04-09 15:32:13 UTC
If I use the toolbar-button "Print" the saved settings are applied, but if I use the File > Print command, "Custom borders" is re-enabled and 0.00 set as border-size. Now it does not work with the toolbar-button anymore. This is strange. ping. Having to disable "custom borders" for every print is quite annoying. Is nobody able to reproduce this bug, or is it regarded a feature? I can't reproduce your report. Just to make sure I understand correctly what I should test: do you know that "Custom borders" is only applied to printing text (ascii files) directly through kprinter? The options in the "Text" tab shouldn't be applied when printing postscript. Also: does this happen with all printers that you have? With only one? Which model the printer is? Can you check the content of the file ~/.lpoptions file? Try with removing that file (restart the application from which you want to print). Michael. content of the file ~/.lpoptions Dest DESKJET_690C Dest deskjet695c kde-margin-bottom=47.9906 kde-margin-left=36 kde-margin-right=36 kde-margin-top=24.0094 Special An%20Fax%20weiterleiten Special Erweitertes%20Faxprogramm%20(ksendfax) Special In%20Datei%20drucken%20(PDF) Special In%20Datei%20drucken%20(PostScript) Special PDF-Datei%20versenden Deleting that file does not help. If I print and go into the border settings, I still get "custom borders" enabled and all borders set to "0". If I disable the checkbox, the real borders are put into the lines, yet saving them does not help, since next time I start the application (kpdf) "custom-borders" is re-enabled and set to 0. Could this be a kpdf issue? I just opened a .ps-file and the borders were set to the saved setting, i.e. not 0. http://www.igpm.rwth-aachen.de/Numa/NumaI_00/loes_h1_2001.ps works. http://www.igpm.rwth-aachen.de/Numa/NumaMB/l02h_hm.pdf does not, i.e. set the borders to 0 which often results in the printer cutting off some space of the page. Another note. Open the PS, set borders to != 0 and save those settings. Open another PS-file http://www.igpm.rwth-aachen.de/Numa/NumaI_00/kl_fr_2001.ps and look at the border settings, they are set correctly. Open the PDF-file from above, have a look at the border settings, they are set to 0. Open the same PS-file from above that had the correct border settings and look at the settings, they are now set to 0. So it seems that the PDF/kpdf is setting the borders to 0 until the it is changed manually. kghostscript respects those settings until kpdf changes them back to 0 again. Sven, are you still having a problem with this issue? Have you tried with KDE 3.5.5? I must admit, I have not fully understood what your problem is. For me, setting borders works, and saving the previous settings works as well -- in all applications that are made to support setting borders (examples: text editors like kate and kwrite, Konqueror for HTML files). Note that the saved borders are stored per printer and per printer instance and hence may be different for each one. Also, you *can't* really set a border when you print a PostScript or a PDF file -- these do already have set their borders internally and it is not changeable. The good news is that you also do *not* need 'to disable "custom borders" for every print' -- just leave them as they are (0, 0, 0, 0). The next application you use that can handle borders will do so just fine. Aaaaaaahhh... now I understand. kpdf does set upon start its internal "margins" to zero, but mistakenly allows to "Save" these settings. And when this is done, of course it overwrites the ~/.lpoptions settings previously saved by another application. It should not even be the case that kpdf does show the margin setting tab in the printer dialog at all, since it is impossible to set the margins anyway. We need to fix that, because it is really confusing. It is indeed a usability bug as well as a functionality one. Thanks for insisting! kpdf (and kghostview) should do the same as KWord: not show the Margins tab *at* *all* (because in KWord you set the margins in the document itself so there is no need to set them in the print dialog; and in PDFs the margins are fixed). I'll move this bug to the kpdf maintainers for now (and once they fixed it, they should move it to the kghostview maintainers). We need to find all other KDE applications that are not yet fully fixed in this respect. So again: are you also having problems with setting margins in Konqueror printing websites? Let me know. Cheers, Kurt ---------- (Moving this bug to kpdf, changing $summary. Previous $summary: "settings for borders are not remembered, custom 0.00 is used as default border size". kpdf maintainers please note: you do not show the "Image" tab either, correctly so. [The "Image" tab contains settings applicable only for image printing; can be seen when starting kprinter from the commandline]. Also, the "Poster" tab does not work for kpdf -- we've still to investigate whose bug that is.) @ kpdf maintainers: Just to emphasize: this bug causes problems for users who happen to save their print settings in kpdf even if they do not even look at the margins. They may intend to save the settings for paper size, duplex printing, banners, n-up, and what-not -- but this will also un-advertedly overwrite their margin settings to "0, 0, 0, 0" for all other applications that are able to use margins. print settings are saved by kprinter into ~/.lpoptions. Maybe bug #124192 ? Yes, that's the same bug. Well, it is a completely different bug (at least from my point of view), but since we fixed bug #124192 we no longer set margins to 0,0,0,0 and that makes this bug fixed too. Closing for now, if it still does not work on KDE 3.5.6 (due to release shortly) please reopen the bug. |