Download it now!
Bug 108559 - Pasting direct formatted text in cell edit mode doesn't always retain the original direct formatting
Summary: Pasting direct formatted text in cell edit mode doesn't always retain the ori...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Paste Cell-Direct-Formatting-Parts
  Show dependency treegraph
 
Reported: 2017-06-15 23:27 UTC by Kevin
Modified: 2020-01-09 14:55 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
steps included in spreadsheet for 108559 (12.83 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-06-15 23:44 UTC, Kevin
Details
alternate steps and demo to shed light on the core problem (13.86 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-06-18 21:57 UTC, Kevin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin 2017-06-15 23:27:51 UTC
Description:
Calc makes changes to one attribute when asked to make changes to another attribute (which it doesn't change! But that's in a different report.)

Steps to Reproduce:
1. load the attached spreadsheet
2. try to change the font SIZE of the specified cells



Actual Results:  
it changes characters that were regular to bold without being asked

Expected Results:
1. make a selection
2. apply a command - it should do what you asked it to do and nothing more


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Comment 1 Kevin 2017-06-15 23:44:36 UTC
Created attachment 134055 [details]
steps included in spreadsheet for 108559
Comment 2 Xisco Faulí 2017-06-16 09:06:23 UTC
Confirmed in

- Version: 5.5.0.0.alpha0+
Build ID: 6ab249ea6aecef5d3f35d624622a368061cad9c3
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

- Version: 4.3.0.0.alpha1+
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e

- Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

- LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 3 Kevin 2017-06-18 21:57:08 UTC
Created attachment 134117 [details]
alternate steps and demo to shed light on the core problem
Comment 4 Yousuf Philips (jay) (retired) 2017-06-20 23:13:37 UTC
As attachment 134117 [details] tackles the core issue, lets focus this bug on it. So lets look at the code.

 <style:style style:name="ce1" style:family="table-cell" ...>
   <style:table-cell-properties ... />
   <style:paragraph-properties ... />
   <style:text-properties fo:color="#ffffff" ... fo:font-weight="bold" ... />
 </style:style>
 <style:style style:name="T1" style:family="text">
   <style:text-properties fo:font-weight="normal" ... />
 </style:style>
 <style:style style:name="T2" style:family="text">
   <style:text-properties fo:font-weight="bold" ... />
 </style:style>

 <table:table-cell table:style-name="ce1" ...>
   <text:p>DD D
   <text:span text:style-name="T1">o</text:span>
   <text:span text:style-name="T2">D</text:span>
   <text:span text:style-name="T1">o</text:span></text:p>
 </table:table-cell>

What can be seen is that 'DD D' is set to bold at the cell level and not at the span level, so from this view, it is understandable that when you paste the beginning 'DD D' that it wouldnt be set to bold, as it would look like so.

 <table:table-cell table:style-name="ce1" ...>
   <text:p>DD D
   <text:span text:style-name="T1">o</text:span>
   <text:span text:style-name="T2">D</text:span>
   <text:span text:style-name="T1">o DD Do</text:span>
   <text:span text:style-name="T2">D</text:span>
   <text:span text:style-name="T1">o</text:span></text:p>
 </table:table-cell>

So not sure what could be done differently to make this work as expected, when the cell contents wasnt fully created with direct formatting in cell edit mode.

@Eike: Any thoughts?
Comment 5 Kevin 2017-06-21 08:25:53 UTC
>So not sure what could be done differently to make this work as expected, when the cell contents wasn't fully created with direct formatting in cell edit mode.

I'm thrilled to see that you're finally looking at the code. Can't you now just look at the corresponding code for Excel to understand why it works properly in that program?

Also, why does the code you cite contain this:

<text:span text:style-name="T1">   ?

I never applied any styles in the creation of the spreadsheet.
Comment 6 Yousuf Philips (jay) (retired) 2017-06-24 15:52:36 UTC
(In reply to Kevin from comment #5)
> I'm thrilled to see that you're finally looking at the code. Can't you now
> just look at the corresponding code for Excel to understand why it works
> properly in that program?

Not likely as its a coding issue and not a xml issue. Was the document originally created in excel?

> Also, why does the code you cite contain this:
> 
> <text:span text:style-name="T1">   ?
> 
> I never applied any styles in the creation of the spreadsheet.

Direct formatting applied at the cell level or within a cell is stored as styles.
Comment 7 Kevin 2017-06-24 22:37:30 UTC
(In reply to Yousuf Philips (jay) from comment #6)

>  Was the document
> originally created in excel?

No - in fact, you can create this bug like this:

1. type: control+B, B, spacebar, control+B, R (this gives you a bold B and a regular R

2. copy everything you just typed, hit spacebar and paste

voilà - the bold B is now regular - this is not "trivial" and it's not an enhancement - it's an appalling embarrassment - an absolute contradiction of decades of collective wisdom on how user interfaces should work - and something that should be fixed immediately so as not to further tarnish the reputation of your project.

> Direct formatting applied at the cell level or within a cell is stored as
> styles.

As I've made abundantly clear, I think the implementation of "styles" in LibreOffice is an absolute travesty - if any of that code (and I use the term advisedly) is at work in the direct formatting bugs that seems like the first place to look for the root cause.
Comment 8 Yousuf Philips (jay) (retired) 2017-06-25 22:42:32 UTC
(In reply to Kevin from comment #7)
> 1. type: control+B, B, spacebar, control+B, R (this gives you a bold B and a
> regular R

Yes your initial control+B applies bold to the cell and not to the 'B', but if you press F2, then followed your sequence, it would work correctly.

I tested your sequence in excel 2010 and it did result with the same behaviour.

There isnt much left to discuss here until a dev looks at the issue and give his/her input, so lets see what happens.

Bubli: Any thoughts on this issue?
Comment 9 Kevin 2017-06-26 05:07:03 UTC
> Yes your initial control+B applies bold to the cell and not to the 'B', but
> if you press F2, then followed your sequence, it would work correctly.
> 
> I tested your sequence in excel 2010 and it did result with the same
> behaviour.


Oh God - you're right. So instead of something that's right in Excel and wrong in Calc, it's something that's wrong in both. This is a painful reminder of why I switched to Libre Calc in the first place. 


I tried the same sequence in both Word and Writer, in both tables and in normal paragraphs, and it worked logically in all cases. What you copy should be what you paste. Am I wrong? Can you describe any logical reason why you would want a hidden attribute of a cell to override what you've copied onto the clipboard? 

In any case, thanks for showing the workaround. I'll try to adapt my work flow to hit F2 before typing anything.

NOTE: This doesn't invalidate the initial report as represented by 108559.ods. If you open that in Excel, the bug doesn't occur.
Comment 10 Yousuf Philips (jay) (retired) 2017-06-27 02:18:54 UTC
(In reply to Kevin from comment #9)
> I tried the same sequence in both Word and Writer, in both tables and in
> normal paragraphs, and it worked logically in all cases. What you copy
> should be what you paste. Am I wrong? Can you describe any logical reason
> why you would want a hidden attribute of a cell to override what you've
> copied onto the clipboard? 

Well when you copied the 'B' it didnt have bold applied to it, as it was applied at the cell level, it just appears bold as there was no non-bold applied to it. Same concept can be seen in Writer with these steps.

1. Open Writer
2. Set Heading 1 (Ctrl + 1)
3. Type 'B '
4. Disable bold
5. Type 'R '
6. Copy 'B R '
7. Paste

> In any case, thanks for showing the workaround. I'll try to adapt my work
> flow to hit F2 before typing anything.

Yep F2 is the only way to make sure direct formatting is applied on the paragraph/text level and not the cell level.

> NOTE: This doesn't invalidate the initial report as represented by
> 108559.ods. If you open that in Excel, the bug doesn't occur.

Lets see what the calc dev says. :D
Comment 11 QA Administrators 2018-06-28 02:47:40 UTC Comment hidden (obsolete)
Comment 12 Timur 2020-01-09 14:55:48 UTC
(In reply to Kevin from comment #0)
> observe: Cells B4, C3, C4 and C5 are drawn as Courier New 8pt
>1. hold down control and select Cells B4, C3, C4 and C5
>observe: Calc's Formatting toolbar indicates that these cells are already >at 9pt – this is a different bug

Not bug, just you may not differentiate direct, cell and character format. 

> 2. To workaround the above bug, set the font size to 6pt and then 9pt – >this seems to clear whatever corruption is preventing the cells from being >editable

No need. 

> NEW BUG: Note that the o's in Cell B4 have been changed to bold – no >apparent rhyme or reason – this kind of this happens ALL the time in ALL >manner of ways. This program in a disgraceful state.

There was cell direct format to bold and it's back now. 

(In reply to Kevin from comment #3)
> Created attachment 134117 [details]
> alternate steps and demo to shed light on the core problem

Also no repro with 6.3 and 6.5+.