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.
Build ID: 902b28a39528b6c92602e9b521a1d0861be1caf9
CPU Threads: 4; Versie besturingssysteem:Windows 6.19; UI Render: standaard;
Locale: nl-BE (nl_BE)
I have Windows 10.
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: 18.104.22.168
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.
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.
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.
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]
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.