The newly redesigned File->Print dialog for writer and calc always completely ignores the paper size, paper orientation, and duplex settings that are stored/saved in the document. Instead, it guesses what they should be, on the fly, based solely on the format->page size/page (guessing what the user might want). If one changes any of those settings in the print dialog, none are them are saved in the document (plus they are ignored anyway the next time the print dialog appears). Even worse, the File->Printer Settings Dialog STILL SHOWS what is saved in the document AND remembers any changes you make there, which is then subsequently ignored by the new File->Print dialog. Example (just paper size): * Create new writer document with defaults (letter sized page in our case). * File->Printer Settings change paper size to legal and say "OK". * Go back into File->Printer Settings, see that the setting is saved in the document and it still says "legal". * Go into File->Print and see that the paper size has changed to letter. * Go back to File->Printer Settings, see that it is still set to legal. * Go into File->Print and change paper size from letter to A4 and print it. * Go back into File->Print and see that it is back to letter again. * Go into File->Printer Settings and see that it is actually still legal saved as the paper size. * Save document, close it, open it, and go into File->Printer Settings to prove that it was saved in the document as legal. This current behavior is inconsistent, confusing, and messy. I understand why the designers of the new File->Print dialog might have it ignore the saved settings and not allow any of those changed settings to be saved- perhaps to try and reduce confusion by less experienced users who simply don't understand the need for PAGE size/orientation to be different from PAPER size/orientation. However, mis-matching the two is needed when using brochure printing, posterizing, and printing N-up. It is still possible to do all those functions with the current behavior, but it is far more frustrating, since it is not possible to have the settings remembered/saved/honored in that document. And having the File->Printer Settings dialog not follow the same logic as File->Print is just insane. There are cases where certain types of print settings should not be saved or remembered, like number of copies, page ranges, or maybe even n-up printing. With some other settings it is far less clear. I don't know the "perfect" behavior for all use cases, but the current behavior is worse than the previously used behavior. Tested Using LO 4.0.0, vanilla RPM, under RHEL 6.2 Linux. Also verified on several other Linuxes and versions of LO. I suspect this has been a problem since the first redesign of the print dialog. I originally reported this as a comment on bug 42657 but was told it is actually worthy of being a separate report, so here it is.
Confirmed, going to bibisect in the next day or two to see if it ever worked. If not, will add to MAB and trying to track down someone who can solve this one. Quite annoying Changing version to 3.6.4.3 as I can confirm it on an older version (version field is for oldest version we can confirm the issue is on). New (Confirmed) Major (loss of settings is loss of data) High (while there is a workaround by setting settings in file - print, this could seriously impede some workflows) bibisectrequest (I'll try to do this), might not be necessary depending on if this is a regression from some really old release
So with earlier bibisect it's even trickier - I am adding Bjoern to this as I'm not sure if a bibisect is useful: Bjoern - on earlier releases through bibisect we see very strange behavior here. Once you set page size through printer settings, it sticks (to legal for instance) Then go to file -> Print -> click "properties" and see that it's set to Letter (should be legal) Then go back to file -> printer settings and see legal again Now go back through print -> properties, change to A4 Print Go to file -> printer settings (this is where it is different) you'll see it is updated to A4 (which is correct!) but... then go to file -> print and go to properties again, you'll see Letter (default) again! So basically, is a bibisect useful here, it just seems like the whole system is screwed up and needs a major rework :-/ And it's a serious bug as it deals with a major component (simple printing)
"The newly redesigned File->Print dialog for writer and calc" for the record, in this context the newly refers to http://wiki.openoffice.org/wiki/Printerpullpages the printerpull stuff, and so was in something like version 3.3. So not "new" in the context of the later conversion to .ui format which left any printerpull behaviour unchanged, so bibisecting won't help. "always completely ignores the paper size ... in the document. Instead, it guesses what they should be, on the fly, based solely on the format->page size/page" I'm not sure, outside of the simple math case, that this is new behaviour. e.g. back in OpenOffice.org 3.2.0 with an old print dialog this is also the case. "If one changes any of those settings in the print dialog, none are them are saved in the document" But if I use file->print, then properties, and change the paper size there and do ok + ok, and then visit file->printer settings, then the same paper size appears there, in other words the file->print->properties->paper settings do change those of file->printer settings Now, what I do see is that if use file->print, it goes into its default and automatic mode of honouring the document page styles for different pages. And when print is pressed that those settings are getting written to the printer settings, overriding the manually set settings. That, to me, is a definite bug anyway. We should only write explicitly selected settings as the new defaults.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7a5bfde13afd98f1a8e110a96a636119da2ad911 Related: fdo#61186 ensure printer settings paper format is not clobbered The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 79465 [details] demo doc for one particular scenario scenario 1: with attached test document a file->printer settings->properties->paper set a paper size, ideally something not used in the test doc, e.g. Executive b file->print->print c file->printer settings->properties->paper the paper size here should now still be what was selected in a and *not* what happened to be the last page format used in the document which is letter
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=71ebe4404b6e7c78a7d2e352f6af88d57209680a Related: fdo#61186 always operate on printer settings paper format The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f937ef20f57b306191f7583c2d47b5ad3f2a73ee Related: fdo#61186 add a toggle to override the paper format The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
scenario 2: with attached test document a file->printer settings->properties->paper set a paper size, ideally something not used in the test doc, e.g. Executive b file->print->properties the paper size here should now still be what was selected in a and *not* what happened to be the current page format shown in the preview which is legal so the properties subdialog in file print now operates on the printer settings, so what gets shown here and changed here mirrors the printer settings dialog, which removes that confusion, and leads to scenario 3 scenario 3: forcing printing to use the printer settings paper a file->printer settings->properties->paper set a paper size, ideally something not used in the test doc, e.g. Executive b file->print->page layout and set pages per sheet to 4 the auto selection for paper will be the first paper size in use, i.e. legal c flip to options and toggle "use only paper size from printer preferences" preview should reconfigure as "Executive" That's kind of as good as I can think of. a) For super simple apps like math everything is unchanged and the underlying printer paper defaults get used as always b) For apps that have per-page paper size possibilities like writer the default is that different paper sizes get used if they are there c) If (esp for nup printing) the user wants to force the print job to use the underlying printer paper defaults, then toggle that option on d) The bugs where the last paper size in a document when printing a multi-paper-style doc get saved as the printing settings for that document is fixed e) The paper shown in file->print->properties is now consistent with that of the printing settings, rather than showing the current paper size in the preview, and changing it changes the printer settings size I'd appreciate it, if this isn't sufficient or if there are more bugs, to not reopen this bug, but to file a new one, and feel free to add me on CC
*** Bug 58853 has been marked as a duplicate of this bug. ***
I can confirm this is fixed in LO 4.1 under Linux! Thanks, this was one of the nastiest bugs we have ever encountered!
Due to last comment - marking as Verified Fixed :) Thanks crxssi for the update, glad it's resolved :-D