Reproduce it in writer or calc: - select some text/cells - file -> print - you are presented the print dialog, but the print "interval: selection" radio button isn't checked
*** Bug 61629 has been marked as a duplicate of this bug. ***
It is a problem that the "selection" radio button is not selected when a range is selected before "file-> print". But it is even worse with direct printing. If you select a range before using the "direct print" button on the toolbar, it will immediately print the entire sheet. In OpenOffice it will open a dialog and ask the user "Do you want to print the selection or the entire document?". You can see my notes in bug 61629 (marked as a duplicate). So it is actually partially a duplicate and partially a second bug :)
Neither problem is fixed in LO 4.1 If you have a range selected and use direct print, there is still no dialog asking “Do you want to print the selection or the entire document?” it just immediately prints the entire sheet. And if you have a range selected and use file->print the "selected cells" option is still not checked, so it, too, prints the entire sheet. Both are regressions. This should be marked as "confirmed"
@crxssi - NEW is confirmed :) So indeed it's confirmed In terms of a regression - when did it work as expected? Back in AOO days or at some point with LibreOffice? I'll do a bibisect if it worked in LibreOffice 3.5 or later
(In reply to comment #4) > @crxssi - NEW is confirmed :) So indeed it's confirmed Damn, I keep forgetting that :) Sorry about that, on some other bugzillas "NEW" is not confirmed. > In terms of a regression - when did it work as expected? Back in AOO days or > at some point with LibreOffice? I'll do a bibisect if it worked in > LibreOffice 3.5 or later The last system I KNOW it working properly was OpenOffice 3.2.1. It is broken in OpenOffice 3.4.1 (never tested 3.3) and LibreOffice 4.0 & 4.1. I never tested in anything earlier in LibreOffice.
I always hate to call these our regressions as really it seems like a regression in AOO and we just ended up with the broken code .... hm - well no bibisect will be useful if it came from AOO code base unfortunately
Not really familiar with "bibisect" (even after doing a Google search) :) I mean, this is still a valid bug report, even if it originally came from AOO, right? Should I or others be reporting it differently? I see what you mean with the word "regression", I am probably using/overusing that word and in a way not typical by developers. To me (and most) it is really the same as a just a bug, usually a break or poorer behavior in something that used to be stable/functional, where a bug could be in a new feature. Thanks! From: bugzilla-daemon@freedesktop.org To: crxssi@hotmail.com Subject: [Bug 54908] printing when a selection is active should take in account it and activate the "print selection" radio button Date: Fri, 26 Jul 2013 19:47:57 +0000 Comment # 6 on bug 54908 from Joel Madero I always hate to call these our regressions as really it seems like a regression in AOO and we just ended up with the broken code .... hm - well no bibisect will be useful if it came from AOO code base unfortunately You are receiving this mail because: You are on the CC list for the bug.
oh no it was perfectly well reported - I was just talking about internal policy about if this is our regression or not - something we'll talk about during next QA call I suspect :) the bug report is fine
I'm not sure if you can really lump bug 61629 in with this bug, as this bug doesn't address "Print Directly" at all unless it ALSO defines the change in behavior specifically for "Print Directly." I see the following options for "Print Directly": 1. When multiple cells are selected, immediately print the selection without asking any questions. If only one cell is selected, immediately print the entire document. "Print Directly" shouldn't bother you with dialogs. It should just dump the selection or sheet to the printer. 2. When multiple cells are selected, ignore them and immediately print the entire sheet. This is the current crippled behavior. "Print Directly" is unable to print a selection as it could before LibreOffice. 3. When multiple cells are selected, "Print Directly" opens the standard Print dialog with "Print selected cells" selected. This is a reasonable compromise, as it still presents the same number of clicks as OpenOffice did. Print Directly would still immediately print the entire sheet when only one cell is selected. 4. Re-implement the simple dialog removed from "Print Directly" to give users the simple choice to print sheet, selected cells, or cancel. I would guess that LO inadvertently removed functionality from "Print Directly" when they attempted to tidy-up the interface. I loaded version 3.3.0 in a virtual machine and it appears that this change was made some time after OpenOffice 3.2.1 and before LibreOffice 3.3.0. My main complaint with having the "Print Directly" related bugs part of this bug is that this one is really just an enhancement request for a different behavior in the standard Print dialog. I'm also not sure that this proposed behavior change for the standard print dialog is ideal. This seems like quite a substantial UI change. You're saying that if any user leaves 2 or more cells selected, the standard Print dialog should default to "print selected cells"? I'm not saying this change is unreasonable, but how many users will accidentally leave cells selected and still expect to print the entire spreadsheet? At least they will have a preview window and the option to change it. To hopefully make things more clear, here are the various situations: 1. OpenOffice previous behavior (functional) * Print Directly, with one cell selected: Prints entire sheet without asking any questions. * Print Directly, with multiple cells selected: Pops up a dialog to print selection, print sheet, or cancel. * File->Print when you have multiple cells selected: Opens print dialog with "print selected sheets" as the default. 2. LibreOffice current behavior (broken Print Directly) * Print Directly, with one cell selected: Prints entire sheet without asking any questions. * Print Directly, when you have multiple cells selected: Prints entire sheet without asking any questions about selection. * File->Print when you have multiple cells selected: Opens print dialog with "print selected sheets" as the default. 3. Proposed behavior in this bug report * Print Directly, with one cell selected: Prints entire sheet without asking any questions. * Print Directly, when you have multiple cells selected: Not addressed so far in this report, and will continue to print entire sheet without asking any questions about selection. * File->Print when you have multiple cells selected: The change suggested in this report. Opens print dialog with "print selected cells" as the default.
(In reply to comment #9) > I'm not sure if you can really lump bug 61629 in with this bug, as this bug > doesn't address "Print Directly" at all unless it ALSO defines the change in > behavior specifically for "Print Directly." True... of course I said that earlier, too :) Really, I think bug 61629 should be reopened, and marked as a regression, since a perfectly useful feature that addressed the issue suddenly disappeared in the first versions of LO (although it was a long time ago) as it came from AOO (Apache Open Office). > [...] > I'm also not sure that this proposed behavior change for the standard print > dialog is ideal. This seems like quite a substantial UI change. You're > saying that if any user leaves 2 or more cells selected, the standard Print > dialog should default to "print selected cells"? I'm not saying this change > is unreasonable, but how many users will accidentally leave cells selected > and still expect to print the entire spreadsheet? At least they will have a > preview window and the option to change it. I agree that Paolo's proposal may be a different kind of behavior BUT it also makes perfect sense... and I will tell you why. In AOO WRITER (tested in 3.4), if you select nothing and then file-> print, it selects the whole document to print. In AOO WRITER, if you select a range and then file-> print, it automatically checks the "Selection" option and only prints that. In my mind, Calc should behave the same way as AOO Writer. Plus, it makes logical sense. But here is the kicker.... in LO Writer, they removed that functionality that OAA had! In LO Writer, if you block something and then go to the print dialog, it DOES NOT choose the "Selection" option. Why? Was that intentional? I hate to muddy the water with yet another issue, but there you have it. > My main complaint with having the "Print Directly" related bugs part of this > bug is that this one is really just an enhancement request for a different > behavior in the standard Print dialog. That all depends on what you are comparing it to. If you compare the standard print dialog behavior to past AOO behavior, it is a regression. If you compare the standard print dialog to past LO behavior, it is an enhancement request. But the current print directly issue in LO is 100% a regression in LO.
(In reply to crxssi from comment #5) > The last system I KNOW it working properly was OpenOffice 3.2.1. It is > broken in OpenOffice 3.4.1 (never tested 3.3) and LibreOffice 4.0 & 4.1. I > never tested in anything earlier in LibreOffice. Predates bibisect range, so Whiteboard -> notBibisectable
Migrating Whiteboard tags to Keywords: (notBibisectable)
*** Bug 47140 has been marked as a duplicate of this bug. ***
*** Bug 100036 has been marked as a duplicate of this bug. ***
Replacing keyword 'notBibisectable' by 'preBibisect' as this bug is outside the bibisect range
** 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 on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
confirmed in 5.4.1.2 ubuntu
Working properly on Versión: 6.2.0.0.alpha1 (x64)
Patch up to review that resolves this bug for Writer: https://gerrit.libreoffice.org/#/c/64804/
(In reply to Daniel Silva from comment #20) > Patch up to review that resolves this bug for Writer: > https://gerrit.libreoffice.org/#/c/64804/ Patch restored in gerrit
Daniel Silva committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/f50363c7008c239d302944144beb256de6a55f38%5E%21 tdf#54908 Make selection active if there's a selection (Writer) It will be available in 6.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.
Daniel Silva committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/87d5c863109f7991e3f2f3a1eb970c00d5a27bd5%5E%21 tdf#54908 Make selection active if there's a selection (Writer) It will be available in 6.3.1. 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.
It has been fixed in Writer, I guess we have to do the same in the other components, isn't it ?
Almost 2 years on, Calc still shows this wrong behavior: no matter if there is a selection or not, print dialog displays whole document (or active sheet). Even worse, some time ago option to "Print Selected Cells" got hidden away behind a "> More", so there is one more click to do every time. And to "add insult to injury", print dialog settings are not remembered in session (related bug 61607 from 2013, never fixed), so one has to go through same steps time and time again when printing different selections from the same document one after another (yes, I have to to that often, and NO, I cannot just print the whole 10+page document, I just need a few groups of a few rows on separate sheets of paper). This works just fine in Writer (just tested: selected 10 rows from 10 page document, Ctrl-P, preview shows only selection). I am currently on LO 7.1.2.2 (openSUSE 15.3), the same is on 7.1.0.3 on Windows 10.
Created attachment 174924 [details] Confirmation dialog from OOo 3.2.0 (In reply to crxssi from comment #5) > (In reply to comment #4) > > In terms of a regression - when did it work as expected? > The last system I KNOW it working properly was OpenOffice 3.2.1. I have just tested with OOo 3.2.0. When selecting anything, and trying to print, a dialog box popped up, as shown on the screeenshot. Likely it was considered intrusive, and was removed, keeping *absolutely correct* default, which was print entire document - printing selection should always be an explicit action. This issue was marked a regression, and got a fix that either should not had happened, or should had been different - I believe based on the feedback here, rather than on actual UX discussion. The end result is several "regression" bugs ;) - see the "see also" section. Note that the issue raised in comment 25 - that the option is hidden by default now - in fact makes this change absolutely bad for anyone who doesn't use printing selections. They would not even look for such an option in the dialog, while people who need such a non-default thing would definitely want to explore the options and learn how to achieve what they need. I suggest to revert it for now, and create an alternative solution. If at all, a dialog from OOo 3.2 or a dedicated "print selection" command placeable on toolbar (or a split print button with "print selection") could be an acceptable option.
Just noting that this change has been reverted in the distro/lhm branch (version maintained for the City of Munich) because it "causes some confusion": https://gerrit.libreoffice.org/c/core/+/139407
I suggest to resolve this ticket as fixed and have the follow-up discussion on bug 139164.
Agree with Heiko: close this as Resolved - Fixed, given that there's commits, even though it hasn't been done for all components (because we want to find a better solution, discussed in bug 139164).
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fed82c416aba3380b8c8931f7d8e0ec359e52a2c tdf#139164: Revert "tdf#54908 Make selection active if there's a selection It will be available in 24.2.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.
The commit here was reverted to fix bug 139164 and its duplicates. Reopening this in case any further action is needed for the original issue here, though I think the current behavior is sane an allows printing selection only for people who need it without negatively affecting everyone else.
So, now that this has been reopened, I would like to draw everyone's attention to the discussion on bug 139164, which asked for the reversion. Specifically, comment 21 there summarizes suggestions at the design meeting regarding how to possibly satisfy both requests reasonably. Now, let me address the latest comments on the discussion there: (In reply to Telesto from comment #47) > Even more problematic: I doubt bug 54908 actually being about Writer in the > first place. The duplicates are clearly about Calc. And bug 54908 is at > least muddled the waters with mentioning Calc (see bug 54908 comment 10, > 'spreadsheet'). So something got fixed at the Writer end, which wasn't even > supported by the bug report. That's a good point actually. In Calc, the spreadsheet is by default extremely large (even if the empty cells don't count until you edit them). Plus, it's two-dimensional, while pages have a very limited width. That makes it more likely for people to want to mark a range of cells and print just that. Looking at Calc, though, I don't even see the possibility of only printing the selection. > The same can be said about bug 54908. There was no 'proper study' done > before changing the behaviour. Sounds bit like: pot calling the kettle black > to me That's exactly right! There is an unknown, but not tiny, number of people who want "print selection" as the default when selecting, and an unknown, but not tiny, number of people who want "print everything" as the default. So the pot and the kettle are both somewhat black, hence the need to at least consider a compromise to not leave one side 100% unsatisfied. > > The whole discussion about a non-problem or a triviality in my perception. A > phrase I actually dislike to use as can be used to silence the opponent > unfairly. + (In reply to خالد حسني from bug 139164, comment #48) > I don’t see any convincing argument for the behavior introduced in bug in > 54908 and there are already a way to print/export selection, just not by > default. Khaled, Telesto, I respect that opinion. And in fact, I would be just fine with never choosing the selection by default. But - it's our opinions, while: * We know others have the opposite view; and * There are three dupes for this bug (albeit some about PDF Export behavior which can be handled differently); and * We used to have a confirmation dialog in the OpenOffice days; and * We did go through a process recently about this. OTOH, and considering the "muddied waters" about PDF export vs Printing and Calc vs Writer or other modules - I guess the reversion and reopening is probably the right call. Let's see what "the people" have to say...
And please note comment 25. Remember that the actual problem was the removal of the *dialog* asking if the current selection should be printed, or the whole document. I suppose that the reasonably sane solution would be restoring that dialog, and have a "don't show again (remember my choice)" in it. Or a separate command to pring selection.
(In reply to Mike Kaganski from comment #33) > And please note comment 25. Err, I meant comment 26.
From bug 139164 comment 21 We discussed this topic in the design meeting. Printing or exporting a selection is sometimes desired and sometimes accidentally. The preselection is a convenience feature and at least for printing easy to spot. However, the large number of tickets and discussion around this topic contradicts this view. And there are a number of possible solutions: 1. Show a confirmation dialog (bug 54908 comment 26) This might be annoying if users intentionally want to print selections. It might be solved by 1.a a checkbox "[x] Ask for confirmation" that could be missing in the next session when printing a selection is not the goal, and 1.b [x] Ask for confirmation during the session" could solve it by saving this answer for the session only 2. Use a highlighting color for automatically selected options, eg. show "Selection" in red It has some drawbacks on special themes, is not a11y conform, and might not be clear enough 3. Add an extra command for "Export Selection to PDF" Easy to understand and to realize but bloats the menu. 3.a As an improvement it could be on the context menu only (and print/export would always be for the whole document) 3.b Another idea is to rename the command conditionally if a selection is active
Not so font of the suggestions proposed in bug 139164 comment 21 (also posted here under comment 35) I'm more in favor the suggestion in comment 26, more specific: split print/PDF button in toolbar "print selection". The split button might also be a 'swap' 'toggle button'. So if select 'print selection' the button will be defaulted to 'selection', until you switch it back. If you want to export/print selections repeatedly (or wanting it to be the 'default') The same system is already present for the shapes and highlight/character color button in toolbar. You pick a different shape/color, and the shape/color will be default..
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/dbcbe2ad59b5403efab0947e3cc8da5c3f9958b6 tdf#139164: Revert "tdf#54908 Make selection active if there's a selection It will be available in 7.6.1. 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.
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/e319bfb07b3b1f07322434a1f407df4db48ff0ae tdf#139164: Revert "tdf#54908 Make selection active if there's a selection It will be available in 7.5.6. 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.
When text is selected, the print selection radio is till not highlighted by default. Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded