A print job's page size is not recalculated if you change your paper size BEFORE selecting "Fit to printable page" or "Distribute on multiple sheets of paper." When you change page size first, LO ignores your printer setting paper size in favor of the paper size from the page format. This is expected, but it never recalculates again after selecting "Fit to printable page" or "Distribute on multiple sheets of paper." This leads to an incorrect print preview and a corrupted print job. To get things to work correctly, you then need to change your paper size two more times to force it to recalculate, since it only does so after closing the print properties dialog. Note that this bug is currently not reproducible in any versions of the latest branches (4.2.7+, 4.3.2+, or 4.4.0+) because of a regression (bug 84051) that is caused by the fix from bug 63905. I tested this in 4.2.6.2. Steps to reproduce: 1. Create a new drawing 2. File -> Print 3. Properties... -> Paper size to something smaller than default (A6) 4. LibreOffice Draw tab 5. Check Fit to printable page Expected: Since we have set a page size of A6 and have now enabled Fit to printable page, our preview should show A6 dimensions. Actual: Our preview window still shows the default paper size, in my case, Letter. When you print, it generates a job that is still on Letter, not A6. We can then fix it by going back to the "General" tab, clicking "Properties...", changing our page size to something else, applying, changing it back to A6, and applying again. You can see the correct behavior by going through the steps above in a different order: 1. Create a new drawing 2. File -> Print 3. LibreOffice Draw tab 4. Check Fit to printable page 5. "General" Tab 6. Properties... -> Paper size to something smaller than default (A6) I tested this using LibreOffice 4.2.6.2 on 64bit RHEL6. This was probably introduced way back in LibreOffice 4.1.x, when LO started preferring page format's page size/orientation over printer preferences. I can confirm the same behavior in LO 4.1.3.2 using 32bit Fedora17, but not using LO 4.0.6.2, so I'll set the version to 4.1.3.2.
I can’t reproduce the bug with LibreOffice 4.2.6.2 on Windows, because LO ignores the page size in favor of the printer format. And I can’t reproduce the bug on master (on GNU/Linux) with my patch from bug 63905: when I check “Fit to printable page”, the preview shows the paper size I have previously set in Printer Properties.
(In reply to Clément Lassieur from comment #1) > I can’t reproduce the bug with LibreOffice 4.2.6.2 on Windows, because LO > ignores the page size in favor of the printer format. I just tested again and I am able to reproduce using 4.2.6.2. LO ignoring page size when you attempt to set it before enabling fit-to-page IS the problem. Did you try enabling fit-to-page before changing page size to see how it is supposed to work? In 4.2.6.2, once fit-to-page is enabled, it does honor page size from print preferences. > And I can’t reproduce the bug on master (on GNU/Linux) with my patch from > bug 63905: when I check “Fit to printable page”, the preview shows the paper > size I have previously set in Printer Properties. Is that available as a current master nightly? I would be interested in testing.
(In reply to tmacalp from comment #2) > I just tested again and I am able to reproduce using 4.2.6.2. LO ignoring > page size when you attempt to set it before enabling fit-to-page IS the > problem. Did you try enabling fit-to-page before changing page size to see > how it is supposed to work? In 4.2.6.2, once fit-to-page is enabled, it > does honor page size from print preferences. Got it. Now I can reproduce with 4.2.6.2. (Sorry, I had in fact enabled fit-to-page previously.) I confirm, however, that I can’t reproduce with master patched. It might have something to do with the part of my patch that deals with cache (printdlg.cxx:1623). Page size in cache was used when the OK button of the Printer Properties dialog was pressed. > Is that available as a current master nightly? I would be interested in > testing. I don’t think so, it has to be reviewed before.
(In reply to Clément Lassieur from comment #3) > (In reply to tmacalp from comment #2) > > > I just tested again and I am able to reproduce using 4.2.6.2. LO ignoring > > page size when you attempt to set it before enabling fit-to-page IS the > > problem. Did you try enabling fit-to-page before changing page size to see > > how it is supposed to work? In 4.2.6.2, once fit-to-page is enabled, it > > does honor page size from print preferences. > > Got it. Now I can reproduce with 4.2.6.2. (Sorry, I had in fact enabled > fit-to-page previously.) Status -> NEW > I confirm, however, that I can’t reproduce with master patched. > Clement: Do you want to take this bug, as it looks like you have a patch that might fix it? > It might have something to do with the part of my patch that deals with > cache (printdlg.cxx:1623). Page size in cache was used when the OK button of > the Printer Properties dialog was pressed. > > > Is that available as a current master nightly? I would be interested in > > testing. > > I don’t think so, it has to be reviewed before. Link to changeset on gerrit?
(In reply to Robinson Tryon (qubit) from comment #4) > Clement: Do you want to take this bug, as it looks like you have a patch > that might fix it? Yes, I take it. > Link to changeset on gerrit? https://gerrit.libreoffice.org/#/c/13763/ (I’m working on it.)
(In reply to Clément Lassieur from comment #5) > https://gerrit.libreoffice.org/#/c/13763/ (I’m working on it.) I see that your commit has been merged to master. I tested a nightly, and using fit-to-page does cause the preview's page size to be recalculated as I would expect. But it also appears that there is now a horrible bug that causes the print job to print if you click OK or Cancel. I'm not sure if it's related to your commit or not. If not, I could report that as another bug. Tested on: Version: 5.0.0.0.alpha1+ Build ID: badec7478035008f514e0976a94438fe2e32dc40 TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-04-22_00:50:58 Locale: en_US If your commit does not cause the new bug mentioned above, would it be possible to have this applied to 4.4 as well? In such a case, it could also be marked as RESOLVED: FIXED. :) Thanks for the fix!
(In reply to tmacalp from comment #6) > But it also appears that there is now a horrible bug that causes the print > job to print if you click OK or Cancel. I'm not sure if it's related to > your commit or not. If not, I could report that as another bug. Any news about that bug? I couldn’t reproduce it. Did you report it?
(In reply to Clément Lassieur from comment #7) > (In reply to tmacalp from comment #6) > > > But it also appears that there is now a horrible bug that causes the print > > job to print if you click OK or Cancel. I'm not sure if it's related to > > your commit or not. If not, I could report that as another bug. > > Any news about that bug? I couldn’t reproduce it. Did you report it? Sorry for the delay. No I didn't report that bug, but it appears to have been fixed at some point, since I'm no longer able to reproduce it in 5.0.0 rc1. I believe this fix is implemented for 5.0.0, so I'll set the whiteboard target. Thanks for the fix!