Download it now!
Bug 100018 - FORMATTING: copying/pasting text to the first character of footnote changes paragraph style to the copied text's style instead of 'footnote' paragraph style
Summary: FORMATTING: copying/pasting text to the first character of footnote changes p...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Footnote-Endnote Formatting-Text-Diverse
  Show dependency treegraph
 
Reported: 2016-05-23 20:56 UTC by f5d505f9
Modified: 2020-01-27 01:11 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Footnote Style (18.35 KB, application/vnd.oasis.opendocument.text)
2020-01-26 20:42 UTC, Dave Barton
Details

Note You need to log in before you can comment on or make changes to this bug.
Description f5d505f9 2016-05-23 20:56:05 UTC
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.
Comment 1 Cor Nouws 2016-05-24 07:13:17 UTC
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
Comment 2 Cor Nouws 2016-05-24 07:14:22 UTC
Wow, seems not to be filed before..
Comment 3 f5d505f9 2016-05-25 11:10:43 UTC
(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.
Comment 4 Niall.Cavanagh 2017-02-02 11:51:34 UTC
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".
Comment 5 Cor Nouws 2017-02-02 13:54:31 UTC
(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.
Comment 6 Cor Nouws 2017-02-18 11:36:23 UTC
@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?
Comment 7 Heiko Tietze 2017-02-18 12:04:23 UTC
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
Comment 8 Regina Henschel 2017-05-26 10:54:46 UTC
This is a special case of bug 98381.
Comment 9 sdc.blanco 2020-01-26 18:45:18 UTC
(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)
Comment 10 Dave Barton 2020-01-26 19:29:14 UTC
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.
Comment 11 William Friedman 2020-01-26 20:18:23 UTC
(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.
Comment 12 Dave Barton 2020-01-26 20:42:39 UTC
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.
Comment 13 V Stuart Foote 2020-01-27 01:11:52 UTC
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.