Created attachment 102451 [details]
Simple example document
When printing in brochure mode, the first attempt at printing sends the wrong paper size. In my example, I have letter sized pages that I print on tabloid sized paper. The first attempt at printing this way shows an incorrect paper size and actually sends that incorrect paper size when it creates the job. The second time pulling up the print dialog and pressing print works properly.
This is a bug that only really bites us while using brochure printing, since that seems to be one of the few times setting "page size" in the print dialog actually changes behavior. Typically the print dialog's paper size is completely ignored and the page size is completely determined by the document's page format.
I only run into this bug in Writer, but I can confirm that it also affects other components that allow brochure printing, including Draw and Impress.
I'll attach a simple example document with the following properties:
* 4 pages
* half-inch borders (to make page boundaries obvious)
* letter sized page format
Steps to reproduce:
01. Open Example document (or create your own based on criteria above)
02. File -> Print
03. Click "Page Layout" Tab
04. Click "Brochure" radio button
05. Click "General" Tab to return to the first page
06. Click "Properties..."
07. Change "Paper size" to "Tabloid"
08. Change "Orientation" to "Landscape"
09. Click "OK" to close Properties dialog
10. Note that the print preview still shows brochure on letter paper, not tabloid
11. Click "OK" to print and note resulting print job
12. File -> Print
13. Note that the print preview now shows the correct 17x11 page size we expected
14. Click "OK" to print and note the resulting print job
* If your printer isn't capable of printing Tabloid, choose any other paper size.
I would expect that both times printing this letter page-formatted document in brochure mode and specifying tabloid sized paper would result in the document being printed on tabloid.
In step 10, we note that the paper size of the preview is still set to Letter, not the Tabloid that we specified. This is exactly what is passed to the printer the first time, as we can confirm in step 12. When we revisit the print dialog again in step 13, the paper size correctly shows Tabloid sized paper and prints that way.
To print one of our common brochure jobs, we specify tabloid size to a dedicated tabloid tray. This bug causes LO to instead request letter to the dedicated tabloid tray, which triggers the printer's page-size mismatch policy to upscale the letter sized page to tabloid. This results in an abomination--the letter aspect ratio, scaled up to fit on tabloid. Printing a second time with the same settings sends the job correctly. Another work around is to change the settings in File -> "Printer Settings" first.
To prove that the job is actually passing letter sized paper, I changed my print mode to postscript and enabled print to file.
$ grep PageSize try1.ps
%%IncludeFeature: *PageSize Letter
$ grep PageSize try2.ps
%%IncludeFeature: *PageSize Tabloid
I also tried using "Print to File" using the now-default PDF Print Mode and observed the same page-size error. You can view the generated pdf and check the page properties to verify that the first job specifies Letter sized paper.
My tests were initially performed using the following LO versions/environments:
LibreOffice 18.104.22.168 under 64bit RHEL6
LibreOffice 22.214.171.124 using 32bit Fedora17
LibreOffice 126.96.36.199RC using 32bit Fedora17
LibreOffice 188.8.131.52 using 64bit Arch Linux
Then I went ahead and bibisected the bug:
315d45609b25edb26f80e4164c6bc9c948143bfc is the first bad commit
Author: Bjoern Michaelsen <email@example.com>
Date: Thu Oct 17 06:49:39 2013 +0000
Author: Tor Lillqvist <firstname.lastname@example.org>
AuthorDate: Mon May 20 14:23:54 2013 +0300
Commit: Tor Lillqvist <email@example.com>
CommitDate: Mon May 20 14:30:50 2013 +0300
WaE: unused function 'GetAutomaticColor'
:100644 100644 bd3ca519fa54a6fe9bdc5c57f9c4d152c1caebc9 0d0cabe76fa1ad7715a96887420426b1ebc018d4 M ccache.log
:100644 100644 b8e5174ba64f21b3eed701d429c3936e36800bf4 071bdf72b6f793c8634784540032563005c4117d M commitmsg
:100644 100644 0694ee4d2663349a74dc0c368699203742e46004 8a5795825f81e7357636cf5c3633b692a37dc1e9 M dev-install.log
:100644 100644 3dee2057c0d1784243699d3e4d8f0af2413e5298 f0e9717218f5f1eeb0d14da99d0b591c298d72b7 M make.log
:040000 040000 65913d0ac6b1cc964184af567dec2fa039fd3b7f
412f8401b81a5a2a42918f8d46df8dc06b71ef24 M opt
# bad: [793dbf6f80f497dfe587d560d6257f42a24273f6] source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [8092559c5013969ebda017d79200463b9b975038] source-hash-fd84daf696a368c2c7561b5253b32a63ecdeca4a
git bisect good 8092559c5013969ebda017d79200463b9b975038
# bad: [0270ef1b76a6de423b30f7927362cc01c1a0fc38] source-hash-b1f7dd66b898b03cb4bd8d434b6370310ea95946
git bisect bad 0270ef1b76a6de423b30f7927362cc01c1a0fc38
# good: [aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1] source-hash-358b60b3b172968a7605b428af01df456d7669b2
git bisect good aedcb9e93c73792e6d4f6bc5d74050efbe5af7c1
# bad: [63ac4ab9665db60fac1e1813c9c80da52b2e87c6] source-hash-66e39940d763586060c4bcc8c3cd213495c40b79
git bisect bad 63ac4ab9665db60fac1e1813c9c80da52b2e87c6
# good: [ec9e268ce152176463e07e09901e4a99d65d86ee] source-hash-1b14676b5f95dd51d6266a6ab7bd713a5ddcff2f
git bisect good ec9e268ce152176463e07e09901e4a99d65d86ee
# good: [bf5d7e3794ac23c52e833b6822032f5f11272d0e] source-hash-a2c34b3d9ac2d7e43e52846308cc63447fd51f23
git bisect good bf5d7e3794ac23c52e833b6822032f5f11272d0e
# good: [5aaaa56b691a456d6c40a20ceca4574681f49634] source-hash-3fb33e3e04c7f339e1e15d24529e8ea1d4dbe321
git bisect good 5aaaa56b691a456d6c40a20ceca4574681f49634
# good: [5d26e0a77ed0f2b5803dfbd75d9f5eed5ca5cca4] source-hash-e8ad612bf813579f7a3bd4ed32c719ee01c6ce2e
git bisect good 5d26e0a77ed0f2b5803dfbd75d9f5eed5ca5cca4
# bad: [315d45609b25edb26f80e4164c6bc9c948143bfc] source-hash-f160e4935c474a5293b3d3c11b3d538efb4767a0
git bisect bad 315d45609b25edb26f80e4164c6bc9c948143bfc
# good: [88f650e02a29e4e7656f1c132f7b47a912a5b8f2] source-hash-0c45b5548537cffddc3fbdd6b1c2b9a8a1bdbc4a
git bisect good 88f650e02a29e4e7656f1c132f7b47a912a5b8f2
# first bad commit: [315d45609b25edb26f80e4164c6bc9c948143bfc] source-hash-f160e4935c474a5293b3d3c11b3d538efb4767a0
Created attachment 103126 [details]
Documents with pages 4.25 x 5.5
This is a skeketon document that I could print with Libreoffice 3.5.7 on ubuntu 12.04. However this same document will not print correctly on Libreoffice 184.108.40.206 (Ubuntu 14.04)
I am trying to print it as a small booklet (brochure) that will fit into a purse (4.25 wide x 5.5 tall).
In Libreoffice 3.5.7 it printed 2 pages on one 8.5 x 11 portrait page (letter size), which could then have the top and bottom portion of the page cut off to make a half tall sheet. It then folded into a nice little booklet.
I can confirm that the "print preview" area does not change to the right page size (orientation). In my case it shows it as letter in landscape mode regardless of the selected orientation in the printer properties.
Also, the orientation does not change after the first print as tmacalp said in the description.
In addition, having the page in landscape mode scales the print size, thus creating a bigger print than would be expected than if it were in protrait mode.
Added developer Caolán McNamara due to his comment on bug 61186.
This bug is similar, but not the same bug. It is for printing in brochure mode. I can not get the paper to change to portrait as it shows up in the preview window and also when I print.
'File' then 'Page preview' shows fine. But when printing, in the print dialog box the preview diagram always shows landscape. I want to fit 2 pages in portrait, 1 page on the left and the other on the right. Selecting the printer, then clicking on 'properties' allows me to change the orientation to portrait. however it does not print potrait. clicking on 'prperties' shows it back to landscape.
I have tried page sizes of both 4.25 x 5.5 inches, as well as 4.25 x 11 pages. Neither works. Rather the 2 pages are printed with the paper in landscape mode and each page on 1 half of the paper.
A sample document is attached.
Same results with printers
*** Bug 83250 has been marked as a duplicate of this bug. ***
Setting platform to ALL as it's been confirmed on OSX.
LibreOffice 5.0 introduced a new behavior that causes a handful of bugs, one of which is keeping this bug from being testable.
Way back in LibreOffice 3.3ish, the print dialog was revamped to simplify things. It now will ignore the print dialog's paper size/orientation in favor of the document's page size. To get this setting to be used, you had to check the (unintuitively located) "Use only paper size from printer preferences," which is located as the last option under the Options tab. IMO, this check-box should be moved to the "Properties" dialog, next to the options it affects, but that is another report. As of 5.0, LO no longer just ignores your paper size settings. Instead, it greys the settings out so you at least know they're not being used.
The bug that is keeping this from being testable, is that switching to brochure mode doesn't currently enable "Use only paper size from printer preferences" to let us choose larger paper. Also, changing the page layout to more than one page per sheet should also allow us to change paper size. I'll report this as another bug, if it's not already reported.
The good news is that once we jump through the unintuitive hoop of checking "Use only paper size from printer preferences" and we specify tabloid paper, this bug is not triggered and it prints correctly the first time.
Of course, after we print and revisit the print dialog, we're hit by bug 79077, so our "Use only paper size from printer preferences" option was forgotten as soon as we clicked print. If we look under properties, the page size box is greyed out, but we still have tabloid paper selected and are unable to change it.
please retest with 220.127.116.11 or 18.104.22.168 and tell if anything changed
Adding keywords regression and bibisected
(In reply to tommy27 from comment #7)
> please retest with 22.214.171.124 or 126.96.36.199 and tell if anything changed
Sorry for the delay. I tested it again with 5.3.0 and can confirm that not much has changed since my reply in comment 6. You still need to check "Use only paper size from printer preferences" in order to select a different paper size because of bug 94342. So, this bug is still currently untestable.
That said, there is yet another bug that occurs immediately after enabling "Use only paper size from printer preferences" and before selecting a different paper size that causes a miscalculation of image position. The image is shifted to the bottom left off of the page. Selecting a different paper size recalculates the image in the correct location. Also, future printing causes the image to be recalculated in the correct location.
What I'm trying to say by describing this other bug is that even though the originally reported bug is no longer reproducible because of bug 94342, there is still some jenky behavior that only affects the first time you print a document. So, it feels more like the bug is just being masked by another bug.
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=0c45b5548537cffddc3fbdd6b1c2b9a8a1bdbc4a..f160e4935c474a5293b3d3c11b3d538efb4767a0
** 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!
Thanks for your extensive reporting and so.
(In reply to tmacalp from comment #6)
> The good news is that once we jump through the unintuitive hoop of checking
> "Use only paper size from printer preferences" and we specify tabloid paper,
> this bug is not triggered and it prints correctly the first time.
That I read that this very bug, no longer exists (only the others you mentioned)?