Hello, On May 20 09:12 Johannes Mueller-Lahn wrote (excerpt):
When you then select the queue for a particular paper tray from the KDE4 print dialog, does it then print form this tray? No, doesn't work. Same problem.
Please verify as the user who actually prints with the "lpoptions -p queue_name -l" command that the tray default setting for the queue is really what you expect. There is no such thing as "THE" default settings for a print queue, see http://en.opensuse.org/SDB:Print_Settings_with_CUPS If the tray default setting for your queues are really what you expect, then the above looks really broken. If you don't select an option in an application print dialog, the application must always and in any case without any exception produce clean printer independent PostScript without any kind of implicit option setting neither in the PostScript (totally wrong) nor as print job option (wrong). The application must only submit clean PostScript to the printing system, just as if one prints a clean PostScript file using "lp -d queue_name file.ps". I don't know about Qt and KDE so that I cannot make an educated comment here - but from my unexperienced point of view it looks as if Qt perhaps produces PostScript which is not printer independent. Perhaps Qt produces PostScript where the tray is specified in the PostScript with a fallback/default "setpagedevice" PostScript command or something like this. To test this, you may disable printing for those queues and inspect the PostScript in the print spool data files. If my guess is right, Qt does the same nonsense as OpenOffice does or did, see this terrible old bug report which started in 2005 and is still in state "NEW": https://bugzilla.novell.com/show_bug.cgi?id=80448 For more information follow in particular the links in https://bugzilla.novell.com/show_bug.cgi?id=80448#c25 in particular you should read (see "FYI" below) https://bugzilla.mozilla.org/show_bug.cgi?id=334485#c7 If an application produces PostScript which is not printer independent, it is in contradiction how printing works under Linux - in particular since CUPS, see "FYI" below. In exceptional cases an application may produce on explicit user request printer-specific PostScript but never ever by default without selecting an option in an application print dialog. But it could be perhaps somehow in compliance how printing works under Windows when applications produce printer-specific PostScript? See "Differences in Printing between Windows and Linux" at http://en.opensuse.org/SDB:Printing_from_Windows_to_Linux FYI: ---------------------------------------------------------------------- An application can either produce 100% ready-to-print printer specific data and then it must be printed in "raw" mode to avoid that the CUPS filtering system tries to filter the printer specific data again (i.e. print like in "lp -d QUEUE -o raw file.prn") or it must produce 100% printer-independent generic data (e.g. 100% printer-independent generic PostScript) and then let the CUPS filtering system produce the printer specific data from it. The second problem in the applications is that they create whatever nice looking document but they don't care about the actual values for a particular printer: - the paper size for which the document is made is not used on the printer (e.g. document is A4 but printer has Letter) - the imaged area in the document is bigger than the imageable area of the printer The print engines in the applications should ask the CUPS printing system for the actual defaults of the queue to which the user actually wants to print because this is the only way which results the real facts and which matches to the printer to which the printout should be actually sent. As long as the applications ignore CUPS and make the printout on their built-in assumptions the mess will never end. Regarding the default media size values: If an application cannot or does not want to be linked with CUPS, the application can use the locale setting of the user who runs it (in particular the "teritory" part of the locale) to determine a reasonable default/fallback media size (usually A4 or Letter) and if even this fails (or is not possible) it should use A4 as fallback paper size because A4 is more often used on the whole world than Letter. In this case the imageable area must be fail-safe which means there must be big unprinted margins (i.e. a small imaged area) so that nothing is clipped on any printer (in particular older inkjet printers cannot print the last 2cm at the bottom of the sheet). ---------------------------------------------------------------------- This was written by me in April 2006, see https://bugzilla.mozilla.org/show_bug.cgi?id=324635#c6 ---------------------------------------------------------------------- Regarding comment #4 "Mozilla's use of setpagedevice to set paper size and number of copies is straight out of the PLRM": The Adobe PostScript Language Reference has only PostScript output devices in mind (e.g. a PostScript printer). Therefore setpagedevice stuff may not work on a non-PostScript output device. For example Ghostscript cannot (or does not) translate any setpagedevice stuff for any non-PostScript output device. Sometimes it may work (depending on the Ghostscript driver) sometimes it may not work. In contrast when CUPS is used, the application doesn't need to care about how to actually set whatever kind of output device specific stuff. This is done by the CUPS pstops filter and for non-PostScript printers by additional stuff like GhostScript and foomatic-rip. When CUPS is used, the application only needs to produce PostScript "images" (i.e. plain PostScript page description without output device specific stuff, I do not mean bitmap images, I mean any kind of PostScript page description) in a reasonable image size (i.e. the bounding box of the image shoud not exceed the imageable area of the media). When CUPS is used, the application can additionally ask the CUPS system for various output device specific values (like imageable area, whether it is a monochrome or color device, ...) so that it can produce an optimal matching PostScript page description. When CUPS is used, the application can additionally implement a user interface to let the user choose output device specific stuff and produce an optimal matching PostScript page description for what the user has actually choosen but even then the application does not include any output device specific stuff in its PostScript output but it would set all output device specific stuff as print job parameters to let the CUPS system do the output device specific stuff based upon those job parameters. This makes sure that the output device specific stuff works for any kind of output device and not only for PostScript output devices. In particular see the Adobe PostScript Language Reference "Using Page Devices" section regarding the "two seperate tasks when printing from an application": ...................................................................... 1. Generate a device-independent page description. 2. Request that the page description be rendered on a particular device. At this point, the user should have an opportunity to add processing options, including device-dependent ones, to the page description. ...................................................................... With old-style printing systems, an application had to do both steps. Since CUPS it is different: CUPS does step 2 and it does it even for non-PostsScript devices. Therefore with CUPS an application has to do only step 1. Regarding "print to file", also see the Adobe PostScript Language Reference "Using Page Devices" section: ...................................................................... Even if a single application performs both of these functions, it is best to maintainthe distinction. Many applications have an option to store the generated page description in a file for later use. Such a file should not contain unnecessary device-dependent processing options. The distinction between document generation and document rendering is essential when using PostScript programs for document storage and interchange. ...................................................................... By the way: I wonder why there seems to be any confusion at all about the plain device-independent page description and the device-dependent stuff when it is so clearly described in the well known Adobe PostScript Language Reference? ---------------------------------------------------------------------- This was written by me also in April 2006, see https://bugzilla.mozilla.org/show_bug.cgi?id=334485#c7 Note that this Mozilla bug is also still in state "NEW". Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer