Bug 85094 - When printing ODT with mixed portrait and landscape, last page has incorrect orientation
Summary: When printing ODT with mixed portrait and landscape, last page has incorrect ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 146639 158249 158654 (view as bug list)
Depends on:
Blocks: Print
  Show dependency treegraph
 
Reported: 2014-10-16 14:23 UTC by Allan Macdonald
Modified: 2024-08-10 20:08 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
Document exhibiting bug. (12.87 KB, application/vnd.oasis.opendocument.text)
2014-10-16 14:23 UTC, Allan Macdonald
Details
Source doc and sample output from xps printer (193.31 KB, application/x-zip-compressed)
2018-10-06 03:46 UTC, twisterddfsl83823
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Allan Macdonald 2014-10-16 14:23:25 UTC
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.
Comment 1 tommy27 2014-10-17 13:02:47 UTC
bug confirmed under Win7x64 using LO 4.3.2.2 
status NEW
Comment 2 Victor 2015-02-22 03:02:33 UTC
I have the same problem. This error does not occur in version 4.2.3 and 4.2.8
Comment 3 denis.st-onge 2015-04-10 19:22:07 UTC
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.
Comment 4 Aaron Wilcox 2016-08-04 21:29:28 UTC
This issue is still present in version 5.1.4.2 (Windows 7 Professional x64)
Comment 5 QA Administrators 2017-09-01 11:16:21 UTC Comment hidden (obsolete)
Comment 6 Allan Macdonald 2017-09-09 16:33:22 UTC
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.
Comment 7 QA Administrators 2018-09-10 02:36:54 UTC Comment hidden (obsolete)
Comment 8 Timur 2018-09-12 15:34:56 UTC
Repro 6.2+. Worked fine with 4.2.8.2.
Comment 9 twisterddfsl83823 2018-10-06 03:29:51 UTC
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.)
Comment 10 twisterddfsl83823 2018-10-06 03:46:42 UTC
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.
Comment 11 twisterddfsl83823 2018-10-06 16:00:40 UTC
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.
Comment 12 Buovjaga 2019-04-14 21:04:40 UTC
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.
Comment 13 Armin Le Grand 2022-01-04 14:41:01 UTC
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.
Comment 14 Buovjaga 2022-12-02 16:41:43 UTC
*** Bug 146639 has been marked as a duplicate of this bug. ***
Comment 15 m_a_riosv 2023-12-12 13:57:53 UTC
*** Bug 158654 has been marked as a duplicate of this bug. ***
Comment 16 Stéphane Guillou (stragu) 2024-04-29 06:16:40 UTC
*** Bug 158249 has been marked as a duplicate of this bug. ***
Comment 17 Stéphane Guillou (stragu) 2024-04-29 10:09:05 UTC
Increasing priority as it's a regression that Armin can't take, with 3 duplicates.
Comment 18 Julien Nabet 2024-04-30 21:19:14 UTC
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...
Comment 19 Patrick (volunteer) 2024-05-01 14:42:18 UTC
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.
Comment 20 Patrick (volunteer) 2024-05-01 17:41:58 UTC
(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.
Comment 21 Patrick (volunteer) 2024-08-10 20:08:12 UTC
(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.