Bug 85094

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)

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.

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.