When I copy some text into a footnote in the 5.2 alpha1, the footnote reverts to the 'standard' style. Expected behavior: text copied into a footnote should follow the 'footnote' style. Replication: (1) create a new document in 5.2 alpha1. (2) Add a footnote. (3) copy some text into the footnote. Additionnal info: 5.2.0.0.alpha1 (x64) Build ID: 902b28a39528b6c92602e9b521a1d0861be1caf9 CPU Threads: 4; Versie besturingssysteem:Windows 6.19; UI Render: standaard; Locale: nl-BE (nl_BE) I have Windows 10.
Hi f5d505f9, Thanks for filing - I confirm the situation. It is as if each footnote is a container, not aware of the fact that the footnote style should be obeyed. Once you set a space and paste, it works fine. Of course Ctrl+Shift+V > Text only, works too. Already the case in LibreOffice 3.3.0 Ciao - Cor
Wow, seems not to be filed before..
(In reply to Cor Nouws from comment #1) > Hi f5d505f9, > > Thanks for filing - I confirm the situation. > > It is as if each footnote is a container, not aware of the fact that the > footnote style should be obeyed. > Once you set a space and paste, it works fine. > Of course Ctrl+Shift+V > Text only, works too. > > Already the case in LibreOffice 3.3.0 > > Ciao - Cor It may be that there are 2 bugs here: the new one and one already found in 3.3.0. I thought the old bug was just a tendency of LO to conserve the style of the copied text, which often was the standard style. I have a list of references which I put therefore in footnote style, so the original style would be the same as the destination style without having to resort to setting a space. But the new bug resets also those references (which are already in footnote style) to standard style. Setting a space does not make it work fine, at least for me.
Just to confirm that the issue persists in Version: 5.3.0.3 Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 Running on Windows 7 64bi8t. The issue: In Writer, if a footnote (or endnote) is inserted and text is pasted in, the format in that footnote entry changes from Footnote to whatever format was in the copied text (usually Default in my case). This also removes the tab whitespace between the number and the text in the footnote. As noted above, the workaround is to insert a space character before doing CTRL-V, or to use CTRL-SHIFT-V and select "Unformatted text".
(In reply to Niall.Cavanagh from comment #4) > As noted above, the workaround is to insert a space character before doing > CTRL-V, or to use CTRL-SHIFT-V and select "Unformatted text". This is the same behavior as with all other empty paragraphs in your text document, by the way.
@ux-advise: We could change this to an enhancement request that pasting in foot note area is without formatting by default.. One could chose the educating-the-user line. Ideas?
Sounds like a pragmatic solution but I tend to be against it for sake of consistency. Copied text paragraph holds its style and you have to paste special as text. Changing the default behavior on one place spoils it on every other. Tested the issue right now with 5.3 fresh. Dt+F3 for some dummy text, add footnote, copy some text with default style, paste to the footnote -> it changes the style to footnote. If a character style is applied to the text this goes into the footnote, however. Version: 5.3.0.3 Build ID: 5.3.0-2 CPU Threads: 8; OS Version: Linux 4.9; UI Render: default; VCL: kde4; Layout Engine: new; Locale: de-DE (en_US.UTF-8); Calc: group
This is a special case of bug 98381.
(In reply to Heiko Tietze from comment #7) > Sounds like a pragmatic solution but I tend to be against it for sake of > consistency. Copied text paragraph holds its style and you have to paste > special as text. Changing the default behavior on one place spoils it on > every other. From a user perspective: it is not consistent. Consider from standard use perspective: User decides to move text from main body to footnote. Insert footnote. Copy and delete text from main body. Click on footnote. Paste. (disappointment) For years I never understood why it did not work, until I discovered that if I put a single space, then it "behaved" as expected/desired (with the minor irritation of having to go back to delete the space). (And now this bug explains the problem.) As noted in comment 1, a single space is enough to have footnote style "override" the style of the pasted text. From a user perspective it seems inconsistent that it does work with a space, but does not work without a space. Given this is a special and limited context (where text is being copied into a footnote), it seems permissible to allow "footnote" style to "override". (have changed the summary to reflect the fact that this happens with any style copied to footnote (e.g, Heading 1)
Please close this as NOT A BUG. There is no need to fiddle with leading spaces or other similar tricks. Using the software in the way it was designed to be used (ie. Paste as unformatted text) is the solution.
(In reply to Dave Barton from comment #10) > Please close this as NOT A BUG. > There is no need to fiddle with leading spaces or other similar tricks. > Using the software in the way it was designed to be used (ie. Paste as > unformatted text) is the solution. "Paste as unformatted text" loses all other attributes of the text -- bold, italics, etc. The expected behavior should be that the use can paste text with such attributes from one style to another without losing those attributes. At present, the only way to do this is to insert a leading space, which is terrible design. The problem is with the software, which is poorly designed in this case.
Created attachment 157441 [details] Footnote Style Sorry but I absolutely disagree. Right from 2001 this software was developed to be STYLES based. Take a look at my attachment which illustrates the software being bused in the way it was designed to be used. My footnote STYLE has a Liberation Mono 10pt blue font, I copy the Heading 1 paragraph from the first line of the document and paste it as "Unformatted test". What you see in the footnote is EXACTLY the footnote style I chose.
Have to agree with Dave here. Paste Special -> 'Paste Unformatted text' is the correct action for handling of styled or DF text when populating a new paragraph object. Unfortunately, other clipboard formats will trigger a style change in the target when first being created. Affects multiple paragraphs types, not just Footnotes/Endnotes (see also bug 93831). And, working with direct formatting in the source clip/copy the direct formatting correctly gets clobbered with 'Paste Unformatted text' selection. The unexpected/undesired style change is annoying, but as noted is reasonable as the only way to ensure a consistent result is to explicitly paste unformatted text. Doing more than that, including honoring applied direct formatting attributes, requires dev effort and refactoring. IHMO the 'NOT A BUG' is valid as behavior is correct, yet this is a valid enhancement to look at handling of direct formatting and and character style that may be applied when pasting into a newly created paragraph object.
It may very well be that the behavior is "reasonable" or logically consistent with the way the software was designed (but then why does the insertion of a single space change the behavior?), but it is not "correct" from the perspective of the user. It seems highly counterproductive to me to argue that the software be "used in the way it was designed to be used"; software should serve the user's needs, not the other way around. Perhaps this specific problem could be solved by an extension or in some other way that doesn't require major surgery, but it is certainly a "bug" and not merely an "enhancement" from the user's perspective.
If you paste a paragraph into another (for example "Foo" with style <citation> into <text body>"Some text" ... </text body> the target style is kept. If you paste as a new paragraph you take the source formatting. That's why the leading blank has an "unexpected" behavior. This makes sense for all styles except footnotes. Shall we make this a special situation and always use the target style? Is there a scenario where users want to keep the source style?
When the styled source text is pasted into the footnote, automatically converting it into into the default, or a user defined, footnote style, is a reasonable compromise. So +1 from me. No doubt there will be at least one out of millions of users who will want to keep the source style, or expect non-styled (manually formatted) source text to be automatically styled, but we cannot automatically accommodate every whim and fancy.
Changing bug summary in light of comment 15 and comment 16
*** Bug 98381 has been marked as a duplicate of this bug. ***
In response to comments #13 and #16, rather than denigrating any potential user's wishes, could there be a way to incorporate a new "paste special" option that would allow selecting exactly which attributes the user wishes to retain when pasting, and only changing the others to the target style? (And allow configuring the default paste operation to follow a custom set of wishes.) This would solve all the problems noted here and in my original bug 98381.
We discussed the topic in the design meeting. For footnotes and endnotes it makes sense to override the default behavior and to keep the target paragraph style (footnote/endnote) even when the operation is done in a non-empty paragraph. All other aspects should be discussed on bug 98381. (In reply to William Friedman from comment #19) > rather than denigrating any potential user's wishes... Love to learn new English words. Hope it has not the pejorative connotation as it sounds. What we do here is to balance individual wishes with general needs. Ease of use comes with simplicity and consistency but as a product that is used for many years we also have to care about familiarity. Please keep this in mind.
*** Bug 141572 has been marked as a duplicate of this bug. ***
A reasonable expectation by the user IMO would be that by default the paragraph style remains that of the style being pasted into but that the character style remains that of the source text.