Created attachment 168420 [details] ODT file which demonstrates the bug. I have a series of files for 16-label A4 paper. Each label has a small image and text indicating the contents and the date frozen. When I edit these labels to adjust the text or date, and/or to move them around to finish off a partly used sheet, I find I have to save, close and re-open the file to print the modified layout. This isn't unique to version 7.0.3.1 - it was happening with the previous version I was using. To demonstrate the bug: 1. Open the attached file. 2. Select the image associated with the seventh label on the sheet. 3. Cut and paste it to the (currently blank) first label. 4. <Cmd>-P brings up a print preview with everything blank except for the image in the first label. 5. Save, close and re-open the file and <Cmd>-P behaves normally.
When you pres <Cmd>+P please try in that window that open to move the radio button from Selection to All pages. Everything will be ok. Waiting for your test. ------------------ When you click on a selection the Print Preview window think that you want to print just that, so it change from All to Selection. You just need now to chang back to All.
When I press <Cmd>-P the Print Preview comes up with Pages From 1 to 1 selected. The tick-box for "Print selection only" is blank - see screenshot: https://www.dropbox.com/s/bibnuidj4ojlt7p/Screenshot%202020-12-22%20at%2018.07.40.png?dl=0 If I choose "Pages All" it makes no difference to the preview, and if I switch back to "From 1 to 1" there is no change. If I select "Print Selection only" the preview is completely blanked, and the "Print Selection only" tick-box remains blank. https://www.dropbox.com/s/rxxugwhay3lmowe/Screenshot%202020-12-22%20at%2018.08.37.png?dl=0 I realise now that I should deselect the cut-and-paste selection before trying to print, but the print preview doesn't indicate that the print will be "selection only", and the subsequent behaviour of that tick-box is unexpected, to say the least!
Down there on the last row you have "Selection" checked. Uncheck that and tell the result. Change to "All Pages".
OK, that deals with the immediate problem (of getting the whole page printed), which I now know could be avoided by removing the selection on the pasted-in graphic at the top. I'm left wondering why the "LibreOffice Writer" panel has "Print Selection Only" disabled at the top and then under "Pages" has the "Selection" radio-button active. Is this the intended behaviour?
We need an opinion form UX Team with this question: On the image in comment 2 you can see there is a "Print selection only" - the conclusion is that this will print what I select. But also, on the last raw we have again "Selection". What are the differences between this 2 Selections?
Done by design, see bug 54908. Your print dialog is not the standard (missing your version info). Point is that we have Selection under Ranges and Copies only. Try a TDF build... https://www.libreoffice.org/download/download/
*** Bug 140719 has been marked as a duplicate of this bug. ***
*** Bug 143866 has been marked as a duplicate of this bug. ***
*** Bug 144103 has been marked as a duplicate of this bug. ***
Sorry throwing this back at UX-department.. at minimum for monitoring purposes.. I dislike closing all bugs pointing to the commit individually as NOTABUG (but feature).. where where multiple people struggle with this. The behaviour has a tendency to 'fool people'. If you unintentionally have something selected and press print, you get the selection.. I asking myself the question: A) How often people print a specific image/shape (as the current behaviour doesn't distinct between 'text' or 'image') in a document. I personally see the print selection as the exception, not the rule B) If you want to print a specific selection, you mentally aware of wanting such.. so you're mentally set (the opposite is not the case). If you see one page while intended to print everything you're surprised.. C) There are small inconsistency's. Selecting a image, and pressing print preview, drops the selection. D) Press Export PDF in toolbar drops the selection (only applied when Choosing Export as PDF) E) How common the dialog setting to 'selection'. I didn't do an in depth investigation. Word doesn't do it.. --- Looking at bug 54908 and duplicates again.. This probably an issue of scope. Bug 54908 is about Calc but changed the behaviour across the suite. I think this shouldn't work this way for Writer/Impress/Draw. This might be an acceptable compromise, IMHO
(In reply to Telesto from comment #10) > A) How often people print a specific image/shape (as the current behaviour > doesn't distinct between 'text' or 'image') in a document. Whether you unintentionally select an object or not, either way you make users unhappy with defaulting to selection or not. Both use cases exists, and I don't have good arguments for one. Maybe consistency with Draw where the selection is more likely wanted. What I could imagine is to consider it an intentional selection only in case of a range, meaning more than one object/character has been selected. But what if you want to print a section or a text frame?
(In reply to Michael Hendry from comment #2) > https://www.dropbox.com/s/bibnuidj4ojlt7p/Screenshot%202020-12-22%20at%2018. > 07.40.png?dl=0 > ... > https://www.dropbox.com/s/rxxugwhay3lmowe/Screenshot%202020-12-22%20at%2018. > 08.37.png?dl=0 It is helpful to attach screenshots to the issue directly. It is sad to click in a screenshot link only to see "deleted" message.
Personally my preference would be that unless there is a dedicated UI for "print selection...", the print is by default always for whole document. In all modules. I suppose that marking "current selection" explicitly is more intuitively correct when one wants to print *part*, then the opposite.
(In reply to Mike Kaganski from comment #12) > (In reply to Michael Hendry from comment #2) > > https://www.dropbox.com/s/bibnuidj4ojlt7p/Screenshot%202020-12-22%20at%2018. > > 07.40.png?dl=0 > > ... > > https://www.dropbox.com/s/rxxugwhay3lmowe/Screenshot%202020-12-22%20at%2018. > > 08.37.png?dl=0 > > It is helpful to attach screenshots to the issue directly. It is sad to > click in a screenshot link only to see "deleted" message. :-( I try to remember to copy any "extenals" to Bugzilla, when I first look at a bug. I asked QA to add this as some "first" step to https://wiki.documentfoundation.org/QA/BugTriage. (In reply to Mike Kaganski from comment #13) > Personally my preference would be that unless there is a dedicated UI for > "print selection...", the print is by default always for whole document. In > all modules. I suppose that marking "current selection" explicitly is more > intuitively correct when one wants to print *part*, then the opposite. I second this. I was fooled by this feature in bug 140719; I even did a bibisect, because it felt like a bug. And that the selection happened, because the user changed the font size and therefore he had text selected on print. Maybe to mitigate the impact for affected users we could assign a shortcut like Ctrl+Alt+P. I wouldn't put it in the default toolbar, or just as an alternative drop down to the default print (like for new, open, etc.). I asked, if UX has an idea how to make the "print selection" more obvious in the dialog to the mostly unexpecting user; again my impression. Reading bug 54908 again, it just seems "fixed" in Writer; I didn't confirm that. OTOH I don't know, if we just overreact over some minor problem? But there are a few dups and this feature feels like a rather special case... And I set the bug to NEW ;-)
First, apologies for deleting the screenshots from Dropbox in the process of migrating to a new computer. Second, I've realised that this feature often occurs when I've been deleting unwanted labels - either because I want fewer than 16, or because I'm printing on a partly used sheet of labels; ink printed on the backing isn't absorbed and causes smudges and inky fingers. Because the selection has been deleted, there is nothing for the "Print Selection" feature to print, there is no visibly selected area on the screen, and the print preview comes up blank. Now that I'm aware of this issue, I can work around it, but if "Print Selection" were switched to "Print All" after the deletion of a selection it would remove one source of confusion.
Sounds like a sensible solution.
(In reply to Michael Hendry from comment #15) > Because the selection has been deleted, there is nothing for the "Print > Selection" feature to print, there is no visibly selected area on the > screen, and the print preview comes up blank. > > Now that I'm aware of this issue, I can work around it, but if "Print > Selection" were switched to "Print All" after the deletion of a selection it > would remove one source of confusion. Now that is a whole different story and is really a bug. But I can't repo, at least with a normal document and some text. If I select a text, the print dialog pre-selects this selection. If I delete the selection, it reverts to "All pages". Either with a part of the page or Ctrl+A. That's on current master. I'm using Ctrl+P to open the print dialog. So we need updated STR and probably a new report. Or it's a MacOS specific bug, because you always had <cmd> instead of <ctrl>.
Aha! Strictly speaking, I'm not _deleting_ selection, but _cutting_ it with Cmd-X. My use-case involves moving the contents of a label from one position to another, so it's usually a matter of a Cmd-X/Cmd-V pair, but sometimes I need to delete the contents of a label without putting them back somewhere - for example, if the original file has contents for each of the sixteen labels but only the first two are needed for this job.
*** Bug 151457 has been marked as a duplicate of this bug. ***
The commit of bug 54908 got reverted in the lhm branch... https://gerrit.libreoffice.org/c/core/+/139407 Is it an option to simple revert it in general...
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
*** Bug 152304 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #21) > 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 To clarify this part: Option 3 means for the File > Export submenu to have "Export selection to PDF" and "Export to PDF" (or "Export document to PDF"); and perhaps the same also for printing ("Print..." and "Print Selection..."). Option 3.a means that the context menu of a selection will have "Export to PDF..." and "Print...", which will default to exporting/printing the selection, while the File menu will default to printing/exporting the whole document. Option 3.b means that the File menu will always have exactly one of "Export Selection to PDF" and "Export Document to PDF", depending on whether there's a selection or not (and exactly one of "Print..." and "Print Selection...").
FWIW: the design meeting missed the proposals at bug 54908 comment 26 by Mike Kaganski as far I can tell.. "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." I find it rather attractive (clean), given the other solutions. ---------- The question is also, the necessity of coherence. Print Selection in Impress/Draw don't use automatic switch to selection with object selected. The split button feature makes sense here too. Calc is different. In the case I kind of expect the take the selection. ----------- PS. with menu entry's for selection. Is this only for 'print direct' 'Export PDF directly' or also Export As -> Export as PDF (advanced settings).
(In reply to Telesto from comment #24) > FWIW: the design meeting missed the proposals at bug 54908 comment 26 by > Mike Kaganski as far I can tell.. We didn't miss the ideas, we missed the fact that they'd been proposed already... :-P > I find it rather attractive (clean), given the other solutions. Those are some of the current suggestions. > ---------- > The question is also, the necessity of coherence. Print Selection in > Impress/Draw don't use automatic switch to selection with object selected. > The split button feature makes sense here too. Do you mean coherence, or consistency? Note that File | Save is always document-only, never selection, so we can't have consistency even within Writer, unless we default to the document, always. > ----------- > PS. with menu entry's for selection. Is this only for 'print direct' 'Export > PDF directly' or also Export As -> Export as PDF (advanced settings). I was focused on the latter in the meeting yesterday, but it could also be the former. It's up to what people write here about their preferences.
(In reply to Eyal Rozenberg from comment #25) > Do you mean coherence, or consistency? In should have been coherence in the given context. However I still ask myself. How much demand is there from print selection, when something is selected in Writer. What extend of the issue: The duplicates in bug 54908 are about Calc, not Writer. If you discount those members in CC, and the QA members how much demand is there actually left. I feels basically like a single user request being honored in bug 54908. I can't tell if the demand has grown over time since introduction, obviously. Is it not easier to simply revert the change.. See what happens.. And re-introduce the feature - in a different way - if the angry mob appears complaining about the feature gone missing. Instead of keeping thinking how the preserve the feature in advance. Which evidently comes at a cost (like cluttering the UI) without clarity about user demand...
(In reply to Telesto from comment #26) > What extend of the issue: The duplicates in bug 54908 are about Calc, not > Writer. If you discount those members in CC, and the QA members how much > demand is there actually left. You really can't tell how much demand there is for a change by counting the CC list size. There is some correlation, of course, but CC list membership or dupe count are meaningful signals only for distinguishing between _massive_ demand and almost-no demand. Not to mention how some people just adapt or "live with it" even though they would have preferred things to be different. > Instead of keeping thinking how the preserve the feature in advance. Which > evidently comes at a cost (like cluttering the UI) without clarity about > user demand... That's also a possibility. But then - would you really be against allowing export/print of a selection from its context menu? That's one of the options.
(In reply to Eyal Rozenberg from comment #27) > You really can't tell how much demand there is for a change by counting the > CC list size. There is some correlation, of course, but CC list membership > or dupe count are meaningful signals only for distinguishing between > _massive_ demand and almost-no demand. Not to mention how some people just > adapt or "live with it" even though they would have preferred things to be > different. I'm aware of the issue :-). I'm mostly at the other side of the argument, wanting a UX change, but lacking proof of demand. > > Instead of keeping thinking how the preserve the feature in advance. Which > > evidently comes at a cost (like cluttering the UI) without clarity about > > user demand... > > That's also a possibility. But then - would you really be against allowing > export/print of a selection from its context menu? That's one of the options. I'm not necessary against.. my 2 cents. However I do ask myself, where are the boundary's. There are so many users with so many different desires. It becomes a slippery slope if add a specialized function/menu entry for each and every case diverting from baseline. Each and every request has its merits and makes often sense in the isolated case(aka "corner-case") Another uno command, another entry in the customization dialog :-). Another function that has to be maintained, documented, translated. Something else that can cause bugs. And what should happen if you use a function without anything selected, only a blinking cursor. Should print an empty page? Automatically switching to 'print/ export to selection' feels like "feature creep". I already struggling with 'Export Directly to PDF' because I never know which settings are used. For example: does it "print a selection" or "full page". Personally I prefer to 2 step process. Export as PDF, knowing what it does (or supposed to do accordingly to dialog, probably not always the case)
(In reply to Telesto from comment #24) > FWIW: the design meeting missed the proposals at bug 54908 comment 26... (In reply to Heiko Tietze from comment #21) > 1. Show a confirmation dialog (bug 54908 comment 26)...
(In reply to Heiko Tietze from comment #29) > (In reply to Telesto from comment #24) > > FWIW: the design meeting missed the proposals at bug 54908 comment 26... > > (In reply to Heiko Tietze from comment #21) > > 1. Show a confirmation dialog (bug 54908 comment 26)... I was talking about: the last paragraph of bug 54908 comment 26 "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."
(not sure why Ray is removing relevant See Also bugs...)
One solution that wouldn't require new UI options would be to change the PDF export options dialog to use/save document specific configuration, so that the choice could be content/file specific (I would actually welcome that for print options as well).
(In reply to khagaroth from comment #32) > so that the choice could be content/file specific I don't think that would solve anything... The bug is about the default behavior, not just the behavior the 2nd-and-later time you print, or export, a document. (Plus, in fact, many/most documents are only exported or printed once).
Yes, that would be an issue for completely new files, but there are templates.
*** Bug 156339 has been marked as a duplicate of this bug. ***
*** Bug 138543 has been marked as a duplicate of this bug. ***
*** Bug 156399 has been marked as a duplicate of this bug. ***
Setting priority from "normal" to "high" because there are 8 duplicates.
Since both print and pdf export dialogs have options for “selection only”, I don’t see why we need complicated solutions rather than simply changing the default. It does not need a user survey to know that printing selection only is such a niche use case, and that the current UX is very poor. Unless I’m missing something obvious, I suggest changing the default back to whole document and be done with it. Users who want to print/export selection only can still do that, and the rest get a sane default.
(In reply to خالد حسني from comment #39) > Since both print and pdf export dialogs have options for “selection only”, I > don’t see why we need complicated solutions rather than simply changing the > default. Printing the whole document by mistake has significant negative physical consequences: Many physical pages, possibly with a lot of ink/toner. That's why we have to be extra-careful about this choice.
(In reply to Eyal Rozenberg from comment #40) > (In reply to خالد حسني from comment #39) > > Since both print and pdf export dialogs have options for “selection only”, I > > don’t see why we need complicated solutions rather than simply changing the > > default. > > Printing the whole document by mistake has significant negative physical > consequences: Many physical pages, possibly with a lot of ink/toner. That's > why we have to be extra-careful about this choice. A) The 'whole document' is default in more applications (Word/Chromium). So people are familiar with it B) Printing selection only is a niche use case (I agree with Khaled) C) You can often abort a print-job, if you incidentally printed the whole document) D) The current print selection does cause same issue. If you have something selected, when pressing print, you are actually printing the selection. E) That an object being selected doesn't entail you intend to print that item only. If you're design (say) a form, and you moved a text label, before hitting print, the 'text label' will be selected (and printed). The selection is made in the context of the last edit made, not a selection with the intention print this. There is quite a surprise effect, what happened here.. F) Already 2,5 year has passed, without a solution I personally prefer a simple revert to the old state, and a new bug for deliberation on a different solution (and finding someone who will implement it).
(In reply to Telesto from comment #41) I wasn't arguing against reverting the default, I was explaining the motivation for why this is not a simple matter. > A) The 'whole document' is default in more applications (Word/Chromium). So > people are familiar with it But many may still assume that if they selected something, then printed, their selection would get printed. Plus, I really don't remember what Word or Chromium's behavior in this respect is, and I use them relatively often. > B) Printing selection only is a niche use case (I agree with Khaled) 1. But the damage from printing a whole document instead of a small selection is large - it's not just an unexpected UI effect. Small niche * large damage = not-small expected damage 2. It's somewhat less of a niche when you've selected a part of the document. > C) You can often abort a print-job, if you incidentally printed the whole > document) But you can often _not_ abort a print job. In fact, in our day and age - by the time you abort, even a large print job is likely to have been fully dispatched. > D) The current print selection does cause same issue. If you have something > selected, when pressing print, you are actually printing the selection. ... hence this bug :-) > E) That an object being selected doesn't entail you intend to print that > item only. It doesn't _necessarily_ entail that intention; but it often does - and in those cases you are likely to fail to notice a different default, hence the care to avoid that situation somehow. > F) Already 2,5 year has passed, without a solution There are quite a few solutions, we need to pick one. Although, to be fair - they were discussed in the context of bug 152304, which is about the Export as PDF menu rather than the print dialog. > I personally prefer a simple revert to the old state, and a new bug for > deliberation on a different solution (and finding someone who will implement > it). Are all of the suggestions unacceptable to you?
(In reply to Eyal Rozenberg from comment #42) > (In reply to Telesto from comment #41) > > I wasn't arguing against reverting the default, I was explaining the > motivation for why this is not a simple matter. > > > A) The 'whole document' is default in more applications (Word/Chromium). So > > people are familiar with it > > But many may still assume that if they selected something, then printed, > their selection would get printed. Plus, I really don't remember what Word > or Chromium's behavior in this respect is, and I use them relatively often. > > > B) Printing selection only is a niche use case (I agree with Khaled) > > 1. But the damage from printing a whole document instead of a small > selection is large - it's not just an unexpected UI effect. Small niche * > large damage = not-small expected damage > > 2. It's somewhat less of a niche when you've selected a part of the document. > > > C) You can often abort a print-job, if you incidentally printed the whole > > document) > > But you can often _not_ abort a print job. In fact, in our day and age - by > the time you abort, even a large print job is likely to have been fully > dispatched. > > > D) The current print selection does cause same issue. If you have something > > selected, when pressing print, you are actually printing the selection. > > ... hence this bug :-) > > > E) That an object being selected doesn't entail you intend to print that > > item only. > > It doesn't _necessarily_ entail that intention; but it often does - and in > those cases you are likely to fail to notice a different default, hence the > care to avoid that situation somehow. > > > F) Already 2,5 year has passed, without a solution > > There are quite a few solutions, we need to pick one. Although, to be fair - > they were discussed in the context of bug 152304, which is about the Export > as PDF menu rather than the print dialog. > > > I personally prefer a simple revert to the old state, and a new bug for > > deliberation on a different solution (and finding someone who will implement > > it). > > Are all of the suggestions unacceptable to you? I have lived with this bug for about 2,5 years regularly printing single pages containing only header/footer and no content, before I even noticed that the option to print selection has been added and mysteriously defaulted to form time to time, resulting in empty pages. I know of no user at my workplace, who ever wanted to print selection from a Writer file and by now even if they did, they would just copy-paste selection to new file. The problem will be hard to deal with due to software making phantom selections on its own at the end of many operations, like in case of bug 156399 after using replace all functionality. A fast fix of defaulting to printing whole document regardless of selection seems the fastest and easiest solution.
(In reply to Julian Ragan from comment #43) > I know of no user at my > workplace, who ever wanted to print selection from a Writer file and by now > even if they did, they would just copy-paste selection to new file. 1. I don't know how many people are at your workplace, but that's still an anecdotal impression and a personal impression by you rather than a proper study. At any rate, it has been recognized that when making a selection, there is a reasonable expectation by many to have the selection be what is acted upon, e.g. printed. See bug 54908. The question is how to reasonably satisfy both people who want to print the whole document regardless of the selection and those who only want the selection. 2. No, your colleagues would not just "copy-paste", because the result of copy-pasting is different from the original, as styles differ, plus, the contents gets pasted elsewhere on the page than where it was originally. > The problem will be hard to deal with due to software making phantom > selections on its own at the end of many operations, like in case of bug > 156399 after using replace all functionality. Interesting... perhaps, orthogonally to the different suggested solutions, we should differentiate between behavior on an automatic and a manual selection? I wonder. > A fast fix of defaulting to printing whole document regardless of selection > seems the fastest and easiest solution. It may be the fastest and easiest, but it's not satisfactory to a non-trivial set of users. Please consider the solutions suggested in comment 10. Are none of them acceptable to you? If some are, indicate which of them you prefer (and strongly oppose).
I’m reverting the change made in Bug 54908 and re-opening it, people in favor of the current (soon to be old) behavior can argue there how to re-enable it while keeping the people who submitted the 9 bug reports here happy.
(In reply to خالد حسني from comment #45) > I’m reverting the change made in Bug 54908 and re-opening it, people in > favor of the current (soon to be old) behavior can argue there how to > re-enable it while keeping the people who submitted the 9 bug reports here > happy. I don't mind the reversion, but - would it not be more appropriate to adopt one of the solutions the design meeting suggested and settle this in a way which keeps both groups of people satisfied? Note that bug 54908 also had a number of dupes. I've been trying to nudge people on this bug to write in favor / against the different alternatives, without much success so far. What's to prevent the same thing happening on bug 54908? :-(
(In reply to Eyal Rozenberg from comment #44) > (In reply to Julian Ragan from comment #43) > > I know of no user at my > > workplace, who ever wanted to print selection from a Writer file and by now > > even if they did, they would just copy-paste selection to new file. > > 1. I don't know how many people are at your workplace, but that's still an > anecdotal impression and a personal impression by you rather than a proper > study. 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 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. > At any rate, it has been recognized that when making a selection, > there is a reasonable expectation by many to have the selection be what is > acted upon, e.g. printed. See bug 54908. The question is how to reasonably > satisfy both people who want to print the whole document regardless of the > selection and those who only want the selection. The default is all pages in plenty of programs. In case Word 365 online, if part of the text selected, and go to File -> Print simply exports the whole document. Press Print in Word 2003 doesn't even open the print dialog, but directly starts printing the (full) document. If I want to print a selection I mostly double check if I'm actually checking if (A) I'm actually print selection (B) I got the proper selection. Or copy/paste it into a different document; so actually sure what I'm printing. FWIW: the commit from bug 54908 got reverted in LHM distro: https://cgit.freedesktop.org/libreoffice/core/commit/?h=distro/lhm/libreoffice-6-4%2bbackports&id=bbfca9be383caa53eb182313d35bde2cc9b690ab > 2. No, your colleagues would not just "copy-paste", because the result of > copy-pasting is different from the original, as styles differ, plus, the > contents gets pasted elsewhere on the page than where it was originally. > > > The problem will be hard to deal with due to software making phantom > > selections on its own at the end of many operations, like in case of bug > > 156399 after using replace all functionality. > > Interesting... perhaps, orthogonally to the different suggested solutions, > we should differentiate between behavior on an automatic and a manual > selection? I wonder. > > > > A fast fix of defaulting to printing whole document regardless of selection > > seems the fastest and easiest solution. > > It may be the fastest and easiest, but it's not satisfactory to a > non-trivial set of users. Please consider the solutions suggested in comment > 10. Are none of them acceptable to you? If some are, indicate which of them > you prefer (and strongly oppose). "to a non-trivial set of users": Is this an anecdotal impression, a hypothetical possibility or is there some true measure? Bug 54908 isn't representative, IMHO The current behaviour is defying the de facto default UI standard: defaulting to all pages. [I use other applications as a metric] So if you're workflow is to print selections and do this a lot, you are limited to LibreOffice for this workflow, It can't be generally applied. With a desire to print a selection in each and every application, you must be far more conscious compared to Print All pages. 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. [Note: written before comment 45/46]
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. There is probably nothing more to do here. But if the desire for this behavior is so strong, we should here from affected users in a release or two and we can then think of a proper solution.
(In reply to خالد حسني from 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. There is probably nothing more to do here. But if the desire for > this behavior is so strong, we should here from affected users in a release > or two and we can then think of a proper solution. Since people can get very vocal when a feature is taken away, I would like to propose adding a setting for switching between print/pdf export behaviors while selection is active. It may have values "Whole document", "Selection only", "Ask". I'm not sure if this would be per application or for entire suite. By default user would be asked which workflow variant is preferred with option to remember selected variant, when action is triggered with selection in document. To complete workflow with selection it would then be necessary to add a bug about phantom selections as byproduct of user actions and a bug about inconsistencies in selection behavior when triggering printing or PDF export (as per observations in comment 10) I think this would be the way to satisfy both camps.
No feature is being taken away, we are only resetting the default of a check box, the check box is still there and can be checked. I don’t see the point and yet another UI setting on top of the already existing one. Adding more options is not the solution for every situation. We are really overthinking this whole thing.
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.
(In reply to Telesto from comment #47) With the reversion, let's continue this discussion in bug 54908.
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.