Created attachment 83836 [details] Screenshot to help illustrate issue In DRAW ONLY the print dialog preview area is not correctly updating after the user changes the paper size. I am attaching a screenshot that helps to illustrate. Steps to reproduce: * Create a Draw document * Set page size to Tabloid/11x17 * Optionally place a full page object on the page * File->Print * Notice the preview is for Letter/8.5x11 sized, since that is the default paper size for the printer * Go under properties and change the paper size to Tabloid/11x17 * Select "OK" and notice that the preview area is still Letter/8.5x11 sized This problem does not occur in Writer or Calc, which both seem to preview based on the page size, not the paper size. There doesn't appear to be a "correct" way to handle this whole situation, but it should at least be consistent for all modules.
I can confirm this bug in LO 4.1.2.3 on 64 bit RHEL 6.1, so I'll set as "New." It also affects the print preview in Impress. It suffers from the exact same behavior, following the same steps. As crxssi mentioned, it doesn't affect Writer or Calc. Also, I tested and found different (but not right) behavior under LO 3.5.7.2 and LO 4.0.2.2. If you follow the same steps in crxssi's report (in both Draw and Impress), everything is the same except the last two steps: ... * Go under properties and change the paper size to Tabloid/11x17 * Select "OK" and notice that the preview IS NOW CORRECT (11x17) Note that this is still different from the way Writer and Calc handle it. Writer and Calc use the correct behavior, even back in 3.5.7.2 and 4.0.2.2, setting preview size based on formatted page size, before the print page size is specified.
I disagree with the assertion that calc/writer are correct. Between 4.0 and 4.1 the behaviour in calc/writer changed (running on Ubuntu) introducing (what is in my view) a regression. Previously in writer (4.0) the print-dialog-preview showed the page as it would appear on the printed page, with the size of the preview reflecting the paper size in the printer properties form. Now (4.1) it is stuck at showing the page size as set by format->page, regardless of the printer paper size selected. To me this is wrong: it is more useful to preview how it will look on the physically printed page. It is particularly acute for me since I produce A5 documents by printing 2up onto A4 and then guillotining. I would do this by: - format->page: set to A5 - printer->properties: set paper to A4 (matching the physical paper in the printer) - printer dialog set 'pages to sheet' to 2 In 4.0 the print-dialog-preview would then nicely show the two A5 pages tiled on one sheet, matching exactly what would then be printed. In 4.1 the print-dialog-preview just shows me two A5 pages tiled into an A5 sheet. Then when I physically print I then get two 70%-of-A5 (i.e. A6) pages printed on the A4 physical sheet - NOT what I wanted!
I get this too, using 4.1.3.2,and there seems to be no workaround. working to A5 page size, I can't get 2 pages side-by-side on A4 as per Karl Relton's comment, and trying to do a brochure the same thing happens. This is a critical bug! see also 67576
The 2up A5 page onto A4 sheet thing is possible by using the "Use only paper size from printer preferences", as per https://bugs.freedesktop.org/show_bug.cgi?id=67576#c4
(In reply to comment #4) > The 2up A5 page onto A4 sheet thing is possible by using the "Use only paper > size from printer preferences", as per > https://bugs.freedesktop.org/show_bug.cgi?id=67576#c4 Thanks for this! I have been looking for a new workaround for bug 67727 - Printing brochure/multi-up that has been broken since at least LO 3.5. Clicking this option seems to work well for me. Sure wish I could make that a default setting for my templates!
Looks like a duplicate of bug 65205 to me, and seems likely that it is related to others like 67727.
(In reply to comment #6) > Looks like a duplicate of bug 65205 to me, and seems likely that it is > related to others like 67727. As far as I can tell, Bug 67903 (this bug) is not related to Bug 65205, at least not in Linux.
We are also experiencing this problem with LO version 4.1.5 on our Windows 7 machines. We were getting ready to install this version on all our Windows PCs but have decided to wait for a bug fix (right now we are running 3.6.5.2). This problem would impact production too strongly. We also agree with "M Greig": this is a critical bug.
This actually is not a critical bug - at best it's "normal" likely "minor". Not saying it's not critical for you (or those who posted) but in general it is not (compared to crashers, data loss, etc . . .) which affect many more users and can result in really large problems. That being said if you're upgrading "many pc's" then I suspect you are working for a company using LibreOffice - I highly recommend getting paid support (through any of our affiliated companies) to get this bug fixed fast if it's a major problem for you. Or, of course the code is open source and libre so you're free to either (a) commit a patch yourself, or (b) find a developer to fix it. Currently our devs are incredibly busy so no guarantees as to when this bug will be handled. Thanks for understanding
(In reply to comment #9) > This actually is not a critical bug - at best it's "normal" likely "minor". > Not saying it's not critical for you (or those who posted) but in general it > is not (compared to crashers, data loss, etc . . .) which affect many more > users and can result in really large problems. > > That being said if you're upgrading "many pc's" then I suspect you are > working for a company using LibreOffice - I highly recommend getting paid > support (through any of our affiliated companies) to get this bug fixed fast > if it's a major problem for you. Or, of course the code is open source and > libre so you're free to either (a) commit a patch yourself, or (b) find a > developer to fix it. Currently our devs are incredibly busy so no guarantees > as to when this bug will be handled. > > Thanks for understanding I understand the distinction you are making here, but still, a word processor that won't print the way you want (while others can) seems a little like a car that will turn every way except the direction you want to go - kind of useless, even it it doesn't crash.
Wait - the description of the bug says "print dialog preview" not printing itself. Can you clarify if I'm mistaking or if the title is not accurate? Also, is this a regression?
(In reply to comment #11) > Wait - the description of the bug says "print dialog preview" not printing > itself. Can you clarify if I'm mistaking or if the title is not accurate? > Also, is this a regression? He must be thinking of another bug. 1) This doesn't affect Writer, just Draw. Draw is not a word processor. 2) It doesn't affect printing, just the preview I wouldn't classify it as a major bug. I don't think it is quite minor either, since it is not intermittent, and can be quite confusing to the user. "Normal" seems right to me, which is what I originally marked it. Of course, opinions will vary :) I am not aware of a regression that changes the print behavior. I hope there isn't!
It is in fact minor - ie. "does not prevent high quality work but can slow it down" I'll leave it as medium though as it can be a bit confusing
(In reply to comment #11) > Wait - the description of the bug says "print dialog preview" not printing > itself. Can you clarify if I'm mistaking or if the title is not accurate? > Also, is this a regression? It is correct that the description speaks only of the print dialog. But just like Karl Relton, we are experiencing not only a bug on the print dialog preview, but in the printing as well. You ask if this is a regression. It sort of seems that way to us, but we have very little experience with bug reporting... "tmacalp" writes that this bug is also affecting Impress, and Karl confirms the bug on calc/writer. Should we, in that case, create a new bug report, or should this bug report be expanded/modified?
(In reply to comment #14) > It is correct that the description speaks only of the print dialog. But just > like Karl Relton, we are experiencing not only a bug on the print dialog > preview, but in the printing as well. You ask if this is a regression. It > sort of seems that way to us, but we have very little experience with bug > reporting... > > Should we, in that case, create a new bug report, or should this bug report > be expanded/modified? I just tested this in LO 4.2.0.4 Linux and there really is problem like you reported... Indeed the bug I originally reported is still valid. When inside the print dialog and you change paper sizes, it does not update the preview. But it seems it also does NOT change the printed paper size either! Steps to reproduce: 1) Start a Draw document. 2) Draw a square in the upper right corner (just for reference) 3) File-> Print (You should see "Letter" if US is your default) 4) Properties-> Paper size, change to "Legal" 5) After you click on "OK" note it doesn't change the preview 6) Click on OK to print the document and it will print on Letter NOT LEGAL 7) Do File-Print again and note it is NOW showing Legal 8) Click on OK to print and this time it will print on Legal paper. Just verified the problem is the same in LO 4.1.4.2 and LO 4.1.0.4 (Linux). Neither problem exists in LO 4.0.2.2 (I just verified). So it seems I didn't report the full problem originally, it is not a new regression (it is an old regression from 4.0.X to 4.1.0). The bug summary is still correct, but I wish I could edit the original bug report post with this new/additional info because it does change the scope somewhat. I don't see the need for a new bug report at this time.
No need to open many reports for the same bug affecting many components:) No worries about not knowing if it's a regression - just was wondering if you ever noticed that it worked (in an older version) but not knowing is not a big deal as we can attempt to bibisect to find out. Thanks!
Printing in Draw still has many issues, but I believe this bug can safely be closed. I'll close it as "Resolved Worksforme," since we don't know exactly which version fixed it. Please reopen or close as a different category if I'm getting this wrong. Draw's preview window now seems to updates properly based on the page format size. It also does pass this page size correctly when printing. I believe that at least the erroneous printing behavior was cleared up in bug 63905. That bug is still open due to some complications with fit-to-page and distribute on multiple sheets, but at least page size is being passed now for normal jobs. That fix was also backported to 4.2.7, 4.3.2, and 4.4.0, so all current versions should be "fixed." There is also still a bug that affects older cups print stacks/pdf renderers with correctly handling passing on paper size to HP Laserjet printers when using the default pdf mode printing. (bug 61189) Also, somewhere around the time this bug was introduced, LO stopped honoring paper size/orientation explicitly set in the print dialog. It completely relies on page format's paper size/orientation unless you check "Use only paper size from printer preferences" in the Options tab of the print dialog. That option's location/behavior is extremely confusing and unintuitive, so it might also be a complicating factor to some of these comments. Whatever the case, I just tested this bug in LO 4.4.0.1 rc1 and was not able to reproduce the originally reported behavior.