Description: The current paste operation disfigures the formatting either of the source string or of the target paragraph. Steps to Reproduce: 1. Mark a substring of some paragraph formatted one way. 2. Copy it. 3. Paste it into a paragraph formatted a different way. Actual Results: The target paragraph assumes the formatting of the source paragraph. Expected Results: The formatting of the target paragraph should remain intact. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: The document attached describes it in full and suggests a repair.
Created attachment 151009 [details] Full description of bug, justification of complaint, suggestion Current functioning of the paste operation is based on the failure to distinguish between block-level formatting and inline-element formatting. It is suggested to observe this distinction.
did you try to use "Paste Special->Unformatted text"?
This is described extensively in the document appended to the report.
Design team: please inspect the attached design document
If you work with styles the copy/paste operation will not override in Writer. Workflow: * Insert some dummy text, apply a style and change it to something else (eg font color red) * Create another document, do the same as before but don't change the style * Copy/paste from one into the other document => the document style is preserved (meaning the red font color is lost in one way or adopted in the other), and that's good, at least for Writer. There is a similar request for Impress in bug 112697 (and the duplicate bug 79928) where the situation is not so clear. What template (slide background color/image, indentation of bullets etc.) should be used for copy/paste operations? The source means you add another master or the target and you change the copied objects. Ideally we get a Paste Special option. Back to the topic, when you paste special in Writer per "Without Style" it's the same as "Unformatted Text" and the opposite "Adopt Style" (or whatever we call this option) it changes all your document as the inserted style is taken. Don't think it's useful this way. Could you provide a use case like "I copy <foo> from <bar> and paste at <baz> expecting <qux>?
At the moment, I can do nothing about this, since on my current installation (LO 6.1.4.2 on Windows 7), the bug does not show. I.e., when I copy a string from paragraph source to paragraph target, the formatting of the target is not touched, no matter whether it uses a predefined or a user-defined template. It thus appears that this bug is a feature of the Linux version. I will be back when I can use my Linux version.
[Automated Action] NeedInfo-To-Unconfirmed
I have now checked this for LO 6.3.2.2 on Kubuntu 18.04. Result: I confirm (comment 5) that if the source paragraph has a style applied, copying part of this paragraph into another one does not transfer that style. Moreover, what I observed for the Windows version now holds for the Linux version, too: Paragraph properties are generally not transferred if only part of a paragraph is copied and pasted. I.o.w.: For properties applying to an entire paragraph, it does not matter for the copy/paste operation whether they have been stipulated specifically for the source paragraph or they are properties of a style applied to it. So far, so good; problem partly solved. However, a difference appears for character properties: - If a certain character property (say font size 10 pt) is set in the style applied to the source paragraph, it is not transferred by copy/paste of part of it. - If the same property is assigned specifically to the source paragraph, then it is inherited by all of its parts and, therefore, transferred to the paste target. This is still inconsistent. Properties applied to entire paragraphs should _never_ be copied if only part of them is copied. Moreover, see Bug 113605, comment 6.
If you modify the paragraph style in document A and copy text into document B, the style of B is preserved, which makes sense. If the copied text has a character style or direct formatting applied, wouldn't expect anything else. I don't see an issue.
We are talking about an attribute - a character style - applied to an entire paragraph (not to parts of it). Why is it treated differently depending on whether it is a component of a paragraph style or stipulated by direct formating of the given paragraph?
(In reply to Christian Lehmann from comment #10) > character style - applied to an entire paragraph The character style (CS) is not meant to format paragraphs, it applies on single words or phrases and comes on top of the paragraph style (PS). For example, you can define the PS "Citation" in italic and a CS "InnerCitation" in normal weight. Example: <i>He heard quiet steps behind him.</i> That didn't bode well. From start to end of the CS formatted part it will adopt the copied text. Example: <i>He heard quiet [didn't bode] steps behind him.</i> That didn't bode well. And of course it also takes what your copy from Example: <i>He heard quiet steps behind him.</i> That didn't <i>heard quiet</i>bode well. The same happens with directly formatted text.
Maybe we have a terminological problem here. For reasons not transparent to me, recent editions of LO offer attributes like font size, italics and so on in two submenus of the Format menu, viz. in Text and Character [this should be undone, by the way]. I called this kind of attribute "Character" attribute just to comply with recent terminology. I was not referring to the rubric "Character Styles" of the Styles panel. Now if that is settled, then your statement that this kind of attribute "is not meant to format paragraphs" does not hold. Of course I can apply such attributes to an entire paragraph. And it does make sense: Of course, we have paragraphs formated with a certain Text (or "Character") attribute, like quotations to be set in a smaller font size etc. Now as said before, there are (at least) two ways of assigning such an attribute to a paragraph: Either in a Paragraph Style (this time, yes, using the rubric "Paragraph Styles" of that panel). Or else by marking the entire paragraph in question and assigning it the attribute in question (by any of the methods available for this operation). If we can agree on this, then I would uphold my complaint about the differential copy/paste treatment of the two paragraph attributes. Which is the treatment of such a text attribute holding for an entire paragraph that you would "expect" (as you say) on a copy/paste operation applied to part of it?
(In reply to Christian Lehmann from comment #12) > Maybe we have a terminological problem here. For reasons not transparent to > me, recent editions of LO offer attributes like font size, italics and so on > in two submenus of the Format menu... The main menu has Format > Text > Bold, Italic... which is direct formatting (it wont change across the document), with the context menu Character > Default, Emphasis... is character style (the appearance changes over the whole document if the style is modified). And the same is available at the main menu under Styles. Paragraph styles do not override the target, character styles and direct formatting is taken into the target. The supposed way to format documents is to use paragraph styles for sections and to highlight only parts with character style. That works perfectly for me and I recommend to resolve the issue respectively. Admittedly it's not really simple, as you may expect, but text processors are complex software and you have to learn concepts. The alleged inconsistency comes from the fact that we not only want to support expert users but also people who just write a short letter with no straight formatting, as an example.
(In reply to Heiko Tietze from comment #13) > (In reply to Christian Lehmann from comment #12) > > Maybe we have a terminological problem here. For reasons not transparent to > > me, recent editions of LO offer attributes like font size, italics and so on > > in two submenus of the Format menu... > > The main menu has Format > Text > Bold, Italic... which is direct formatting > (it wont change across the document), with the context menu Character > > Default, Emphasis... is character style (the appearance changes over the > whole document if the style is modified). And the same is available at the > main menu under Styles. I cannot reproduce this. First, taking stock: a) The main menu Format has (among others) two submenus called Text and Character. b) The context menu (available upon right-click in the document) only offers the Character menu plus a selection of Character Styles as available from #c. c) In the Styles panel, there are (among others) catalogs of paragraph and of character styles. Upon modifying any of these, menus appear which offer features of the options also available from the main Format menu. Now ignoring #c, I observe that the submenu Text of #a offers the very same features as the submenu Character. It is this what I considered redundant; the more so as the same features are, again, available as clickable icons in the Formatting Toolbar. One can also confuse the user by presenting the same features under different names. As for #b, it does the same service as the submenu Character of #a plus the Character Styles list of #c. I observe no difference concerning the appearance changing over the whole document. This is as it should be. > > Paragraph styles do not override the target, character styles and direct > formatting is taken into the target. The supposed way to format documents is > to use paragraph styles for sections and to highlight only parts with > character style. > But please consider the case that I made in comment 12: I can assign a certain Font property like, say, 11 pt, to an entire paragraph by defining and assigning a paragraph style which has this feature. Or else - if I have only one such paragraph in my document - I do not define such a style, but simply mark the paragraph and assign it this font property. I see nothing wrong in this latter procedure, nor do I see an alternate way of doing this which avoids the inconsistency that I mentioned. Sorry if this exchange boils down to removing a misunderstanding. But hopefully it will lead to clearer menus and menu functions.
Could someone please provide *full* description of *every small* step needed to see the problem, and that full description followed by clear description of which result of the steps is considered wrong, and which is the expected result - all that without now-useless description of _why_, which is already tldr here?
For me, problem here is the discussion itself, which repeats from time to time. What I do is convert those bugs to Documentation, like bug 112872 for clone formatting. Documentation should be very clear with all those examples, so that we immediately can point there. But I can't see a good page on copy/paste with direct/style/character...
Created attachment 165067 [details] Test file for copying strings into custom paragraph. Please load it and execute the actions suggested in it.
This is now LO 7.0.0.3. I cannot at the moment tell how much of the problem reported before persists. I will report on remaining bugs in paste operations individually. Here is one of them: Copy a string into the custom-formatted paragraph in the test file attached. Its custom format is destroyed.
Created attachment 165073 [details] The file contains paragraphs in different styles and a table for copying material into it. The 'test_file_paragraph_formatting_in_table' shows another aspect of the general problem: If you copy a word from one of the custom paragraphs in the document into the empty table cell, the entire cell assumes that custom format. This is not what the user wants. As said before, there is a difference between a character style and a block style. If I only paste a string of characters into a different block, I may wish to preserve the character formatting; but I definitely do not wish to impose the formatting of the source paragraph onto the target paragraph.
(In reply to Christian Lehmann from comment #17) > Created attachment 165067 [details] > Test file for copying strings into custom paragraph. > > Please load it and execute the actions suggested in it. I now see that a version of this bug was already reported as bug 105550. Apparently nothing has been done about it.
(In reply to Christian Lehmann from comment #19) > Created attachment 165073 [details] > The file contains paragraphs in different styles and a table for copying > material into it. > > The 'test_file_paragraph_formatting_in_table' shows another aspect of the > general problem: If you copy a word from one of the custom paragraphs in the > document into the empty table cell, the entire cell assumes that custom > format. This is not what the user wants. As said before, there is a > difference between a character style and a block style. If I only paste a > string of characters into a different block, I may wish to preserve the > character formatting; but I definitely do not wish to impose the formatting > of the source paragraph onto the target paragraph. I now see Bug 37873. An aspect of the problem I am reporting here is that if the source paragraph has some indentation, copying part of it into a table cell will preserve the indentation, with the result that the user can no longer see what he copied. It makes a difference whether I deliberately format a table cell in such a way as to render its content invisible or whether I copy something into it in good faith, and it becomes invisible.
This bug report is now over two years old. I have provided documents to prove that the bug exists. It persists into LO 7.1.4.2. Apparently, nobody is willing to take it seriously, let alone do anything about it. Maybe somebody could take the time to tell me what I have to do in order to convince people that it is a serious bug.
If you want it to be fixed, you need to: 1. give most simple sample ODT and steps 2. fix it yourself, find someone who will do it as a volunteer, or pay to a programmer or company to have it done, or just wait (days or decades). Since I don't easily for what exactly this was confirmed, I set Unconfirmed again.
(In reply to Christian Lehmann from comment #22) > Apparently, nobody is willing to take it seriously, let alone do anything > about it. Maybe somebody could take the time to tell me what I have to do > in order to convince people that it is a serious bug. This is a case of wrong expectations. You obviously expect that issues in the bug tracker of this project are put in some kind of queue, with priorities and such. No, this is just a pool of known issues; and there is *no* queue. An interested developer may appear and take any bug, regardless of its "importance" (for someone), just because that developer is hit by it today, or has a customer who paid for fixing specifically this one, or just because they were working on something related. Or a rather high-impact issue may lack an interested developer for years and years. That is normal. Some bugs really prove to be more important than others - not by discussion in the bugs, but rather by the indicators showing their impact, like number of duplicates and CC list. Such bugs get reflected in weekly ESC meetings as "Most pressing bugs". They get there to get more visibility in the hope that this would find them an interested developer, but still no guarantees. A user filing to the bug tracker is doing the project a great thing: even though the bugs are not promised to be fixed in timely fashion, having bugs filed is very helpful, because sometimes it's some small bit that was missing in older reports that makes it possible to fix easily; or some developers searching bug tracker for some interesting task would not fix some bug if it weren't filed... every contribution matters, and good [1] bug reports are one of the most important kind of contribution possible. A user making such a contribution should expect some follow-up clarification requests, but not much more than that: the contribution is not done to get an instant end result. They should not expect someone to "take it seriously", etc. But when a user wants their problem resolved, bug filing is just a first (important) step. The next one is finding someone to fix; and this means you need someone to provide some service to you - this normally implies some payment. There's a number of known certified engineers available [2], or you are welcome to find anyone else to do that (in fact, finding people from outside to fix your bug in LO is very nice, because it might help bring more developers to the project - which could help decrease number of open bugs here). (In reply to Timur from comment #23) > I don't easily for what exactly this was confirmed I concur. [1] [1] comment 15 [2] https://www.libreoffice.org/get-help/professional-support/
Created attachment 173754 [details] document with different custom paragraph styles The attachment shows the same as the earlier attachments.
Thanks for both answers. Let me suggest that Mike's answer be incorporated into the page https://wiki.documentfoundation.org/QA/BugReport perhaps as item 4.2. Now for the simple simple document and the steps to produce the bug: 0. Open the ‘document_with_different_styles_2.odt’. 1. Copy a word out of a paragraph of the list styled ‘list_item_w_bullet_0’. 2. Paste it into table cell C2. 3. The cell changes its paragraph style to the custom bullet list style. 4. Same happens if you paste into C2 a word from the custom numbered list ‘list_item_w_letter’ or a word from either of the two paragraphs with custom indent and custom vertical distance. It does not happen if you copy a word from the pre-defined numbered list.
This is not a bug. (But I agree, that we need a better documentation; yet, to document the million of existing special casing in the code designed for ease of use of some, which sometimes surprise others, is next to impossible :D) If you use LibreOffice 7.1 or newer (which you already have), you may use Style Inspector [1] to easily spot the difference between paragraphs having your custom formatting vs. the one with standard list (I assume it is applied using F12). The difference is that the rest of paragraphs have paragraph styles where those properties are defined, while standard list is applied simply by setting a direct formatting (list style name, list ID...). LibreOffice treats *empty* paragraph specially for the case of pasting into it. Specifically in that case of pasting into an empty paragraph, the paragraph formatting is taken into account. Paragraph styles are applied along with the character formatting. This is specifically for the convenience of users who expect this kind of behavior (and no, I don't have an idea which percentage of users expects that - I only know that it's done on purpose, and to change that, a proposal should be made to UX, which would evaluate pros and contras - and then it's doable). But if your destination is not empty (e.g., contains a single space), this special processing does not happen. And no, I don't think that introducing a configuration is a way forward: it would add complexity to already complex code, adding a condition to an exception - giving another dimension to already infinite number of possible states. Indeed, when a paragraph style contain reference to a list style, applying that paragraph style brings list to the destination. When paragraph style contains spacing settings, they will get applied. Even settings from the paragraph with F12 numbering will get applied - to test, pre-apply a Heading or Title paragraph style to C2, and then paste there something from F12-numbered paragraph - you'll see that the cell looses previous formatting from title/heading styles. [1] https://wiki.documentfoundation.org/ReleaseNotes/7.1#Style_inspector
There are topics at two different levels that I want to take up: I. a communicative procedure for use by LO developers and users II. the particular design decision discussed in the present bug report. In the subsequent post, I make a proposal for #II. In this post, I will only comment on #I. I am sure that Bugzilla is not the right place to do this. But the discussion has been started here, and I cannot see a better place to take it up. (There is currently no discussion forum on https://wiki.documentfoundation.org/Design.) I. There have been occasions on Bugzilla where a user proposes an enhancement or asks for revising a design decision, and such a proposal is rejected by those developers who intervene in the discussion. By definition, this is not a situation of impossibility of implementing the proposal, but rather of divergent opinions or preferences of some users and some developers. In a rational environment, the decision will not depend on who has the power, but instead on the preferences of the majority of users (including, of course, developers who are users). The problem is then to ascertain the majority preference. LO should set up a discussion forum with the following function (possibly among other functions): • Once a proposal for an enhancement or a design feature of LO has been discussed, but not been adopted in Bugzilla, a person authorized for it publishes it on the forum and asks for votes. • Users of LO vote (for, against, indifferent). • Developers consider the outcome of the poll in the further development of LO. The question then is how to engage users in participating in such a poll. We can come up with suggestions once the basic idea has been taken up.
I hereby file a proposal to UX for the revision of a design decision which apparently dates back to the times of OO. If I am not entitled to file such a proposal, I ask someone entitled to file it, or an improved version of it. Preconditions: A Writer document contains 1. a paragraph formatted with a custom style defined by the user, for instance with indentation of the first line or as a numbered list item 2. and a table whose cells are formatted with a. the predefined style Table Contents or a predefined Heading style b. the predefined Numbered List style (F12) or any user-defined paragraph or list style. Action: User copies a substring properly included in paragraph #1 and pastes it into an empty cell of table #2. Current behavior: The target table cell assumes the attributes of paragraph #1, specifically in case 2.a: instead of the style pre-applied to the table cell in case 2.b: in addition to the properties the table cell already had. Desired behavior: The target table cell keeps the style it had intact; i.o.w., the copy operation leaves the paragraph style attributes of the source behind. Arguments: 1) The current behavior is inconsistent in the following respects: a) Attributes of a custom-styled paragraph or list are transferred on copy and paste. Attributes of a predefined paragraph or list style are not so preserved. b) Attributes of one subset of sources replace the target properties, but attributes of another subset of sources are added to the target properties. c) Paragraph properties stemming from the source are pasted into the target cell if this is empty. They are ignored if the cell has any content. There is no basis on which the user could expect this behavior. 2) The current behavior is a hindrance to the editing of a document: a) When the user transfers a substring of a source paragraph into a target paragraph, he expects the character attributes of the substring to be preserved. He does not expect the attributes of the source paragraph to be preserved. For his paste operation, they are of no interest. Instead, he wants to preserve the format properties of the target paragraph. b) In the particular case of a table, the default is for all of its cells to have the same paragraph style. The user does not want them to have different paragraph styles stemming from whatever he copied the cell contents from. The user has to undo, every time, the changes applied by LO to the table cells. Proposal: On copying a proper substring of a paragraph, ignore paragraph attributes. This is both simpler than current behavior and expected by the user.
(In reply to Christian Lehmann from comment #28) No need it that all. It works fine in the bugzilla, and me closing it as NOTABUG is just a mark for *initial* report of something considered a *bug*. I myself described the ways to proceed, and didn't end it all there with the closure; so e.g. you could file a new *enhancement request* based on this, without clutter piled up here in the process of clarifying the matter, and put this to See Also there; or Heiko may prefer to re-open it and make it the enhancement request. Whenever a poll is needed, UX team has a blog where they start and count votes. So the proposed complications are useless.
(In reply to Christian Lehmann from comment #29) > 1) The current behavior is inconsistent in the following respects: > a) Attributes of a custom-styled paragraph or list are transferred on copy > and paste. Attributes of a predefined paragraph or list style are not so > preserved. This is not correct. "Attributes" of paragraph are *always* transferred; those of *list* are never transferred. A list may appear in the target only as result of *paragraph* settings referring to a list style, so only as a part of applying *paragraph* properties. Note that lists may be applied directly, or referenced from paragraph styles. That is the difference here. This is to clarify, and avoid misconceptions, not to oppose.
Okay, accepted; but does that make it any more transparent for the user? In all modesty, I find my proposal simpler and more straightforward.
Since nothing has been changed about the above in LO 7.3, I may add: The document contains - a bullet list, formatted by clicking the 'unordered list' button on the sidebar - a paragraph indented by clicking the 'indent' button on the sidebar - a table whose cells are formatted as 'Table content' by default. I copy a word from the list and paste it into an empty table cell. Table content format is preserved. Fine. I copy a word from the indented paragraph and paste it into an empty table cell. The table content is indented. Unexpected. This is just to back the principle suggested by me before: If a _substring_ of a block element (be it a paragraph, a list element, a table cell or what not) is copied, properties of the source block must _not_ be included with the copy operation; so there is no chance of pasting them into the target. Things are, of course, different if an entire block is copied.