Created attachment 175966 [details] Sample ODP The attached presentation has slide dimension 25.40 cm / 14.29 cm, landscape. Open it, and open File -> Print. => In Windows there are the following issues: - Slide is added in landscape orientation to portrait page, despite Automatic orientation in the picker (switching orientation shows incorrect result, too), - Paper size in preview is 143 mm / 216 mm, - Paper size in dropdown is 210 mm / 296 mm. There are issues in Linux as well: - Paper size in preview is 229 mm / 152 mm, - Paper size in dropdown is 216 mm / 341 mm. At least the orientation is correct. The sizes seem very random, not sure how much it depends on printer settings. Observed using LO Version: 7.3.0.0.alpha0+ (d80547c7f4ddf599cce52e5c52269cb07a677466), 6.1.0.3 / Windows & Linux. In LO 6.0.0.3 the page size is A4, the layout is landscape, and by default the slide is put on the paper in its original size, but there is also a "Fit to printable page" option on the LibreOffice Impress tab of the dialog (a new Print dialog has been implemented since). The regression is from the following commit, bibisected using repo bibisect-win32-6.1 / bibisect-linux-64-6.1, both leading to the same change. https://cgit.freedesktop.org/libreoffice/core/commit/?id=57991f885e60d04e93bf5004d4fdceee7d29f3d8 author Vasily Melenchuk <Vasily.Melenchuk@cib.de> 2017-12-12 11:32:06 +0300 committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2018-01-23 17:01:31 +0100 "tdf#91362: Use document paper size for printing slides." Not sure what the correct solution should be for presentations, my first instinct is that the size of the slide is irrelevant, it has no relation to common page sizes, and by default the slide should be acaled to fit.
Created attachment 175967 [details] Print preview in Windows
Created attachment 175968 [details] Print preview in Linux
Repro Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 93115d2c54d645bcf2f80fde325e3ede39dee4d5 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
The same issue as reported here - as dedicated report - is actually also mentioned in: bug 99183
Looking at this now. First need to make myself a Windows build for the first time in a long while.
Created attachment 176074 [details] Screenshot For me the Print dialog looks like this. (In a fresh master build.) Quite different from Aron's.
Note that in my Print dialog, there is one more size not yet mentioned in this: 215 x 345 mm... This is crazy.
Created attachment 176075 [details] Improved test document. To be able to check how successfully the slide actually is printed, I added squares at the very corners of the paper (as defined in the document itself). (I also changed the slide background to white to not waste toner/ink...)
Created attachment 176076 [details] How it got printed. Not surprisingly, there is one more problem: The slide upper and left sides get cut off when actually printed onto paper. At least on Windows 10, using my Brother laser printer.
(But sure, by going into the more detailed settings, one can get it to be printed centered, so that all of the slide is visible. This should IMHO obviously be the default, though.)
(In reply to Tor Lillqvist from comment #6) > For me the Print dialog looks like this. (In a fresh master build.) Quite > different from Aron's. Can you try with the same (or a similar) printer installed, as in the screenshot? (and making it the default, as switching from one to another and back doesn't show the same result)
Aron, what is the exact thing that the customer has complained about for this bug? Just that the various sizes listed here and there on the print dialog seem arbitrary? Or that part of the slide gets cut off? Or what? If the user has set the slide size to some arbitrary size and aspect ratio, should we refuse to print unless the printer has that size paper? (Joke.) More seriously, if the user has set the slide size to some smalling absolute size (as expressed in actual length units, millimetres or inches), does that mean that we should print it at exactly that size? Or should the size be ignored and the slide always scaled (uniformly in both directions) and centered on the paper? Also, no common paper size is either 4:3 or 16:9 aspect ratio, while those are the aspect ratios typically used for slides nowadays, when slides are displayed electronically and not printed on transparencies.
> Can you try with the same (or a similar) printer installed, as in the screenshot? No idea how to add a specific model of printer without actually having such a printer connected. But I will try...
I installed the Canon printer driver for the model in Aron's screenshot and added a printer connected to LPT1: of that model. When I attempt to print to that I get the same dialog as in Aron's screenshot. Interesting. Aron, is in your opinion the dialog as it shows up for my (real) Brother printer more correct and this bug is not present in that? Does this mean that this bug is NOTOURBUG but something caused by the printer driver?
(In reply to Tor Lillqvist from comment #12) > Aron, what is the exact thing that the customer has complained about for > this bug? Just that the various sizes listed here and there on the print > dialog seem arbitrary? Or that part of the slide gets cut off? Or what? 1. Wrong dimensions, both for the page itself (not A4), and discrepancy between preview dimensions and Paper size in the dropdown, 2. The preview orientation is obviously wrong (perhaps also printed wrong, I haven't checked that). > More seriously, if the user has set the slide size to some smalling absolute > size (as expressed in actual length units, millimetres or inches), does that > mean that we should print it at exactly that size? Or should the size be > ignored and the slide always scaled (uniformly in both directions) and > centered on the paper? This has a setting in the dialog, under LibreOffice Impress tab, I'd support switching the default to "Fit to printable page" in case of Impress (currently, and in the past it's been "Original size"). Not much can be done about the paper having different aspect ratio. > Aron, is in your opinion the dialog as it shows up for my (real) Brother > printer more correct and this bug is not present in that? Does this mean > that this bug is NOTOURBUG but something caused by the printer driver? I think we should only claim this isn't a bug in LO if we can argue specifically what data provided by the printer driver/OS is wrong. And even then, a reasonable workaround should be considered if possible, as the problem won't go away by claiming NOTOURBUG. When looking at the original bug report, bug 91362, the expectation there is that printer settings in LO's Print dialog and the printer driver's own dialog should be in sync, which I can completely agree with. No idea what kind of interface we have, I presume we should be able to tell the driver the orientation (and some other parameters), while the paper size should be coming from the printer. I find the argument in bug 91362 comment 14 unusual, and would consider the fix introduced for that for reverting on the basis that the paper size in the printer is a given. Vasily, Christoph, do you have further thoughts?
Code pointer: The "297 mm (User Defined)" type strings in the Print dialog are constructed in PrintDialog::PrintPreviewWindow::setPreview() function in vcl/source/window/printdlg.cxx.
The change https://gerrit.libreoffice.org/c/core/+/124612 should at least fix one problem apparent in the (non-public) customer screenshot, where the set above the preview image displayed "143 mm (A4)" which makes no sense at all. With that patch we display a paper size name there only if the dimensions that we display there match a defined paper size. But that is just one part of this mess.
The 215x345 mm I mentioned in Comment #7 is not some random junk, but apparently a real paper size called "India Legal". Probably the driver for my Brother printer includes that. No idea why it shows up as if it was the default at that time, though.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/65081542d2dabdf17820d62abdc5a22d3734e52d tdf#145354: Ensure displayed paper name matches displayed paper dimensions It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Now investigating why that weird 215x345 even shows up. If it is LO that gets the list of paper sizes from the system, I think we should simply drop sizes that we don't know of and not bother displaying them and claim they are "User Defined" when the *user* has done nothing.
Now I think I understand why for me it claimed that the 215 x 345 mm was the selected paper size. The code selects that size from the list that matches the document's selected paper size. But it bases that on the Paper enumeration, not actual dimensions. Thus it treats all "user defined" sizes the same, and if the document paper size is some random one that doesn't match any standard paper size known to LO, the last random paper size listed by the system gets selected, because that is also "user defined". In my case, apparently the system lists just one such random size, the above mentioned 215 x 345, so that is what gets selected to match the document's 25.40 cm x 14.29 cm. Haha.
Or actually, the above might be a misunderstanding. Anyway, continuing investigation.
And then there is the can of worms that is the binary PrinterSetup blob in ODF. I quote a comment in an old OO.o bug from 2009, https://bz.apache.org/ooo/show_bug.cgi?id=80835: The current text is quite right: the binary blob is mostly what comes out of a printer driver; it's a DEVMODE structure on Windows. On other systems its is also some blob known only to the printer implementation. Garnished around that are a few vcl internal enums caching parts of the driver blob as they come out of system dependent print API accessing that blob. On top of that this is data that can be used only on the same system and the same printer, a method to store driver settings you can access through the native print driver dialogs. That it is stored in the actual document stream is more of a historical accident IMHO, this would have belonged into meta data (if we had had them at the time ;-) ) The original sample document here is set up to print on a printer called "Canon Inkjet MX7600 series" so if one has installed a printer driver for that model then it will behave differently than otherwise, I assume. (Who thought it was a good idea to store printer selection, which inherently is specific to each installation of the software, in a portable document format?)
Created attachment 176091 [details] Screenshot Oh this just keeps getting better. Now I see a print dialog like this. Note how the paper size is claimed to be 210mm x 296mm, one millimetre off from A4, 210mm x 297mm.And the preview image again shows a portrait orientation 143mm x 216mm.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5f8b834eef1565a0523aabd6dd8af5f1b0fd4c75 tdf#145354: Don't claim random paper sizes from the system are "User Defined" It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
By the way, the randomly looking 25.40 x 14.29 cm is not that random after all, it is be what LO itself specifies, for some unknown reason, as the "On-Screen Show (16:9)" paper size: { IN2MM100( 5.625 ), IN2MM100( 10 ), nullptr, nullptr }, //PowerPoint On-screen Show (16:9) 5.625 in == 14.2875 cm, 10 in == 2.540 cm.
The full name is "PowerPoint On-screen Show (16:9)". Was added in the master branch only this year in 6d4a1716624a8a045ff4e90bd221b563be44be11, "Add PowerPoint compatible screen size for Impress" . Is not present in 7.0. So perhaps this document originates from PowerPoint?
Added a fair amount of debugging printout, and now I see even this: doSloppyFit: 10470x24130 => 10478x24130 (#10 Envelope) Somehow even the "#10 Envelope" size gets invoked at some stage. (That output is not from some loop that would contain all sizes.)
A wrote some code to PrintDialog::setPaperSizes() that would make it set as active (in the combo box) the paper size offered by the printer that most closely matches the paper size in the document, but yeah, that is not good. Better would be to prioritise that the paper size has an aspect ratio that is close to that requested. But that is not good either, because printer drivers seems to claim they "support" a long list of obscure paper sizes, while in fact, in a large majority of the cases, printers will have just one size of paper, either A4 or Letter depending on locale. So maybe the pragmatic approach should simply be to always select as active in the combo box A4 or Letter, regardless what the document wants?
I tested now in the latest Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community Build ID: c7500945fc5d5bd2130a2d38be0bd4b15445cd90 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ro-RO (ro_RO); UI: en-US Calc: threaded The size is not appearing correct. We get only the dimenssion, not the type of paper (A4, A3, etc)
Bogdan, what size do you mean? Screenshots please.
Created attachment 176127 [details] screenshot On windows 7.3 here where is my mouse the term A4 doesnt appear before the dimenssion. I se only dimensions, not the A4 term. (In the image is from my linux computer. I don't have acces now to Windows.)
Bogdan, did you attach the wrong screenshot? The text that the mouse pointer is at does say "A4 210 mm x 297 mm".
Created attachment 176152 [details] Screenshot with various printers * Paper size of the preview is always the same * Orientation differs * Paper size dimensions one big mess Printer paper size is being A4 for all printer Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 73334560b2dd2d60ac58d2cc2b1a5295490b03e1 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
FWIW: bug 93244 made the issue surely more apparent. And there where already some attempts to improve the situation. I added some see also's.
Created attachment 176158 [details] screenshot See now Paper Size. There is NO A4
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9a8dcf797dd277079e5b58947d7281645aa0389e tdf#145354: Don't let an arbitrary paper size match any other arbitrary size It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
> See now Paper Size. There is NO A4 Well, if you have chosen a paper size for the document that is not A4, why would there be? That is exactly one problem (as I understand it) with how these things work; printer drivers claim to have a bunch of random paper sizes available even if in the vast majority of cases the only paper the user will want to use is A4 or Letter. And in your screenshot you are using some PDFCreator as the printer; why should A4, a physical paper size, be the default when creating a PDF? We can't know whether the PDF is intended for mainly viewing electronically or for printing.
The next aspect I am working on is to make sure that the print dialog never by default chooses a paper orientation that doesn't match the document orientation. Possibly I will also make it always suggest A4 or Letter (depending on locale). But then there is a risk that users that do have some other paper size installer in their printer, and intentionally have lots of document for specifically that paper size, will be annoyed.
Created attachment 176177 [details] PDFCreator print > And in your screenshot you are using some PDFCreator as the printer; why > should A4, a physical paper size, be the default when creating a PDF? We > can't know whether the PDF is intended for mainly viewing electronically or > for printing. Well somewhere in the advanced printer settings of the PDFCreator printer driver you will find the default page size is set print to A4 (Europe). And it actually will print to A4 even if the page size is set to 677 x 381 mm in Print dialog. See exported PDF attached So the paper size shown at Print dialog only affects scaling in my perception; not on which paper the printer actually will print it. [Help is page does suggest the same thing, IMHO] However clue if there should be some advanced logic to picking a paper size in LibreOffice which interacts with on which type paper it gets printed. Something like 'matching' supported papers. And picking the best match paper size of the available; which would cause a minimum of scaling I normally define the paper size at printer level: clicking the properties button below the printer selection. Or I would to try to add the same printer multiple times with different default pages sizes. So you get something like printer A: Canon4600 A4/ Canon4600 A3 (which is same printer with different paper tray). The paper size should by default be the default of the printer driver, IMHO. But this only my view; not an expert on the matter
It seems that simply reverting the commit 57991f885e60d04e93bf5004d4fdceee7d29f3d8 has a beneficial effect, at least for the customer document that is the reason I am looking at this mess. That document has a paper size of 25.40 x 14.29 cm, i.e. the "PowerPoint On-screen Show (16:9)". Without the revert, the print dialog (on Windows, with a Canon MX7600 printer driver) shows the preview image on a portrait orientation 143 x 216 mm paper. Which is totally wrong and weird. With the revert, it shows it on landscape orientation A4. Which is much saner. So I would think that reverting 57991f885e60d04e93bf5004d4fdceee7d29f3d8 might indeed be a good idea. But yeah, I need to read carefully what problems it solved and try to reproduce...
By the way, in many comments here and in other bugs, it seems that people think that a printer driver (on Windows) is able to tell LibreOffice what the "default" or "current" selected paper size is. As far as I see from https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-devicecapabilitiesw that is not the case. You can only ask what the "supported" paper sizes are. Nothing tells you what paper sizes actually are present. Or am I missing something? Or wait, there is DC_MEDIAREADY. The description of that sounds like it could be useful. Our code does not use it. Will have to experiment.
But DC_MEDIAREADY returns a list of textual "names of paper forms". Does not necessarily sound like what we want. But I will check.
I checked what calling DeviceCapabilitiesW () forDC_MEDIAREADY returns. At first against the Canon MX7600 driver that the customer error report mentions. Hooray, it indeed returns "A4" and nothing else. Sounds promising. Then I check against the driver for my actual physical printer, a Brother laser printer. It returns "Letter". I have never owned any Letter paper. So DC_MEDIAREADY is useless.
I checked whether some locale or region setting makes the Brother printer claim to have Letter paper, and made sure to change all settings I could find and easily change to "English (United Kingdom)" and "Finland". Did not help. There might be some more low-level legacy setting that the printer driver looks at and thinks "this user is clearly in the US", though.
(In reply to Tor Lillqvist from comment #42) > By the way, in many comments here and in other bugs, it seems that people > think that a printer driver (on Windows) is able to tell LibreOffice what > the "default" or "current" selected paper size is. As far as I see from > https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi- > devicecapabilitiesw that is not the case. You can only ask what the > "supported" paper sizes are. Nothing tells you what paper sizes actually are > present. > > Or am I missing something? Well there is some interaction between printer driver and dialog 1. Open Writer 2. Type some text 3. Press Print button (print dialog appears) 4. Press Properties button (for printer) 5. Change orientation from portrait to landscape and paper size to B5 6. Press OK 7. Notice that orientation & paper size adapts (in dialog) 8. Press Print -> Get a print which is orientated portrait (so not WYSIWYG) and at A4); 9. Try the same with MSO; notice that it's also portrait 10. Now visa versa.. Change orientation in Print Dialog with default (portrait for printer) 11. The preview adapts 12. Now press Print.. Result still portrait 13. Change the document layout to landscape 14. Press Print button 15. Change orientation to portrait in print dialog 16. Press Print -> Get a page in landscape Conclusion.. A) There is interaction between 'Printer settings' and LibreOffice dialog B) Print dialog (settings + preview) doesn't match the actual result. You can change orientation at printer level or in the print dialog, but end result will be the in document defined orientation. So looking at the print preview or print settings in the dialog is surely confusing. It doesn't matter for the final print.. On Windows... Linux obviously different beast, didn't check... Another indication that interaction between printer and software being possible is given by the fact that I can choose 'Duplex' in Chrome print preview, while the default it single page; it still prints duplex. So this might suggest that the document size/orientation is overruling the print dialog settings?
(In reply to Tor Lillqvist from comment #41) > So I would think that reverting 57991f885e60d04e93bf5004d4fdceee7d29f3d8 > might indeed be a good idea. But yeah, I need to read carefully what > problems it solved and try to reproduce... Slightly out of scope because you're mission is Impress. However the initial report was about Writer. Extended to Impress. It's based on wrong assumptions, IMHO LibreOffice doesn't care about page orientation of the printer driver. The orientation of the actual document is what matters. The commits of Katerina cause an "Optical illusion". Say you have a landscape document. Press Print.. You select Properties of the printer and set the orientation to 'Portrait'. The preview changes.. But if you actually print it's still Landscape layout. The "problem" described at bug 91362 comment 0 actually nothing new. It also is present in when printing with Word. So I personally inclined to revert all commits for bug 91362 (so Impress & Writer) Reason: * Its an optical illusion (main point); it doesn't actually work; it doesn't solve anything. Except being confusing * There only was a single user complaining (while CC filled with QA/dev members) * Word behaves the same * We are already reverting the Impress part (inconstancy) However no clue if the follow up commits of the years have build upon the wrong assumptions; and meddled with original logic (like bug 123076).
> There is interaction between 'Printer settings' and LibreOffice dialog Sure, but my point is that a printer and its driver are apparently not capable of telling an application, through Windows, what paper is *truly* available at the printer. That the user can pretend there for instance is Letter paper in the printer even if the actual paper tray contains A4 is another matter.
(In reply to Tor Lillqvist from comment #48) > > There is interaction between 'Printer settings' and LibreOffice dialog > > Sure, but my point is that a printer and its driver are apparently not > capable of telling an application, through Windows, what paper is *truly* > available at the printer. That the user can pretend there for instance is > Letter paper in the printer even if the actual paper tray contains A4 is > another matter. You're right. Took a while to realize ;-). I think the revert is right course of action. I would even propose to revert everything done in bug 91362 (see comment 47) The same issue is present in Writer. Configure the page size to A3 and press Print.. Same madness as with Impress
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3a6b9e3bc1a2854783811f1cfa86db6592685930 tdf#145354: Revert "tdf#91362: Use document paper size for printing slides" It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 119470 has been marked as a duplicate of this bug. ***
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d2ca15952de167b6236139d53f6757a7c0d22d0a Revert "tdf#145354: Ensure displayed paper name matches displayed paper ..." It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/85fb61fbbf3ee5b786e73a66ec1e1ce06500bbcc Revert "tdf#145354: Ensure displayed paper name matches displayed paper ..." It will be available in 7.3.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dear Collabora Productivity Ltd, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assign it back to yourself if you're still working on this.