Created attachment 107932 [details] Document exhibiting bug. A document is created that starts in portrait, changes to landscape in the middle of the document and returns to portrait for the last page. When printing the document, the last page remains in landscape mode. When advancing pages by presing the right arrow button under the preview window of the printing dialog, the incorrect orientation is shown in the last page. Then, when reviewing previous pages by clicking the left button under the preview window, the first page ends up showing in landscape mode as well. Example document attached.
bug confirmed under Win7x64 using LO 4.3.2.2 status NEW
I have the same problem. This error does not occur in version 4.2.3 and 4.2.8
As a work-around, I found that you can use the "Export directly as PDF" or install a PDF printer (like CutePDF) to keep the document in the proper printable format. These features do not seem to be affected by this bug. It's annoying but, at least, you can print the document.
This issue is still present in version 5.1.4.2 (Windows 7 Professional x64)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170901
This bug still exists in Version: 5.4.1.2 Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527 CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: gtk2; Locale: en-CA (en_CA.UTF-8); Calc: group Running under Ubuntu 16.04 LTS 64 bit.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Repro 6.2+. Worked fine with 4.2.8.2.
Just encountered this bug in version 6.0.6.2 Also like to clarify the bug. Every page after the landscape page will print in landscape mode and be cut off on the bottom. Wasted 50 pages of printing because of this. A really odd workaround is that if you set the portrait page width to something custom, the problem disappears. (other than the printer settings are now off for paper size.)
Created attachment 145424 [details] Source doc and sample output from xps printer Uploaded a new sample. I used the built in xps printer in windows to show what goes wrong and that it somehow works when using the pdf printer instead.
Found some interesting behavior with this bug. For example, if the landscape page is on pg 2, if you print pgs 3-10, they will print correctly, but if you print 2-10, they won't. If you go to the print dialog, and it has that mini preview, and you go to the landscape page, it will now print every page in landscape (with bottoms cut off) including pg 1.
Bibisected with win32-4.3 to https://gerrit.libreoffice.org/plugins/gitiles/core/+/674a8a084bff6aa089d073b2710cd6a8b6662546%5E!/ Resolves: #i122984# Avoid too many Print JobSetups... Adding Cc: to Armin Le Grand This was a difficult bibisect, because there were commits where printing caused a crash. Thankfully, I was able to find out that the actual range between the good and bad commits did not contain these crashes. This was the method that helped me: https://wiki.documentfoundation.org/QA/Bibisect#Bisect_skip_hell Contrary to comment 3, I was able to see the bug with a PDF printer (Microsoft PDF printer). Also, the bug is still in the latest master.
This commit was developed for another code base, and not merged by me. For complex changes like this, side-effects are to be expected; sadly I dont't have the cycles to deal with all the fallout. Un-Ccing myself for the while.
*** Bug 146639 has been marked as a duplicate of this bug. ***
*** Bug 158654 has been marked as a duplicate of this bug. ***
*** Bug 158249 has been marked as a duplicate of this bug. ***
Increasing priority as it's a regression that Armin can't take, with 3 duplicates.
Just for the record, if I use this patch to revert print part in old Armin's patch: diff --git a/vcl/source/gdi/print.cxx b/vcl/source/gdi/print.cxx index 06625a4227bd..dbdf8c9bafe2 100644 --- a/vcl/source/gdi/print.cxx +++ b/vcl/source/gdi/print.cxx @@ -1307,23 +1307,10 @@ bool Printer::SetPaperSizeUser( const Size& rSize ) const Size aPixSize = LogicToPixel( rSize ); const Size aPageSize = PixelToLogic(aPixSize, MapMode(MapUnit::Map100thMM)); - bool bNeedToChange(maJobSetup.ImplGetConstData().GetPaperWidth() != aPageSize.Width() || - maJobSetup.ImplGetConstData().GetPaperHeight() != aPageSize.Height()); - - if(!bNeedToChange) - { - // #i122984# only need to change when Paper is different from PAPER_USER and - // the mapped Paper which will created below in the call to ImplFindPaperFormatForUserSize - // and will replace maJobSetup.ImplGetConstData()->GetPaperFormat(). This leads to - // unnecessary JobSetups, e.g. when printing a multi-page fax, but also with - // normal print - const Paper aPaper = ImplGetPaperFormat(aPageSize.Width(), aPageSize.Height()); - - bNeedToChange = maJobSetup.ImplGetConstData().GetPaperFormat() != PAPER_USER && - maJobSetup.ImplGetConstData().GetPaperFormat() != aPaper; - } - - if(bNeedToChange) + if ( (maJobSetup.ImplGetConstData().GetPaperFormat() != PAPER_USER) || + (maJobSetup.ImplGetConstData().GetPaperWidth() != aPageSize.Width()) || + (maJobSetup.ImplGetConstData().GetPaperHeight() != aPageSize.Height()) + ) { JobSetup aJobSetup = maJobSetup; ImplJobSetup& rData = aJobSetup.ImplGetData(); preview in print dialog works well (first page in portrait, second in landscape, third in portrait) Also we've been using libtiff since 2022-05 so perhaps the whole patch is obsolete. "itiff.cxx" is now in vcl/source/filter/itiff and only contains 360 lines "ccidecom.hxx" and "ccidecom.cxx" don't exist anymore in LO codebase. To be sure, we'd need someone who has a fax and able to test a build with the above patch, not simple I suppose...
I can reproduce this bug on macOS. Unfortunately, the debug patch in comment #18 does not change anything on macOS so macOS likely needs some fix in LibreOffice's native print code.
(In reply to Patrick Luby (volunteer) from comment #19) > I can reproduce this bug on macOS. Unfortunately, the debug patch in comment > #18 does not change anything on macOS so macOS likely needs some fix in > LibreOffice's native print code. I remember implementing a macOS fix for this "page size and/or orientation changes during a print job" bug in NeoOffice. When I get some time I will see if I can splice my native fix into LibreOffice.
(In reply to Patrick Luby (volunteer) from comment #20) > I remember implementing a macOS fix for this "page size and/or orientation > changes during a print job" bug in NeoOffice. When I get some time I will > see if I can splice my native fix into LibreOffice. I haven't really had any spare time to look at this and my spare time for LibreOffice work is very limited lately so not sure when or if I will be able to fix this bug on macOS.