https://bugs.freedesktop.org/show_bug.cgi?id=33791
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #27 from [email protected] --- (In reply to comment #19) > Presumably the general issue is that if the printer doesn't claim to have > support for the exact right paper size then we're forcing rendering on the > closest size that the printer does claim to have and centering the result on > that. I can only speak for CUPS in a Linux environment with postscript page printers.... To my knowledge CUPS doesn't work that way (or if it does, it shouldn't and hasn't in any other Linux app I have ever used). If you send a document to a printer on a paper size it doesn't have, the *printer* should resolve that difference, not the application and not CUPS. Example- printer has letter paper in two trays. You send legal to it, the printer should ask the user to "load legal". The user can decide, at the printer, to cancel the job, change a tray to legal, insert it manually, or tell printer to force print on loaded media (fit to page, if it has that option on the printer). This issue sounds similar to Bug 61189 where PDF printing mode is apparently not sending a paper size at all to the printer. Our only workaround in our production environment had been to switch back to postscript printing, which worked fine until the regression described in Bug 67802 popped up in 4.1.0. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
