Bug 125371 - Calculation in table destroys left alignment
Summary: Calculation in table destroys left alignment
Status: RESOLVED DUPLICATE of bug 124860
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.3.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks:
 
Reported: 2019-05-19 14:23 UTC by Wolfgang Denk
Modified: 2019-05-19 18:45 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Example Table to show the problem. (9.04 KB, application/vnd.oasis.opendocument.text)
2019-05-19 14:23 UTC, Wolfgang Denk
Details
Initial state and formatting of the table. (7.10 KB, application/pdf)
2019-05-19 14:24 UTC, Wolfgang Denk
Details
State after changing content of <A1> : <C1> alignment corrupted (7.32 KB, application/pdf)
2019-05-19 14:25 UTC, Wolfgang Denk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Denk 2019-05-19 14:23:18 UTC
Created attachment 151513 [details]
Example Table to show the problem.

If a table contains cells which are left-aligned, and which contain formula, there lose alignment and get automatically right-aligned after the displayed value changes due to data changed elsewhere.

The example table contains a trivial calculation, the intreresting cell is left bottom (<C1>) - it is intentionally left-aligned and formatted as currency.

When changing any value anywhere in the table - say, changing the upper left cell (<A1>) from '5' to '6', the content of the table will be re-calculated, and cell <C1> gets right-aligned.

Note that this cannot even be restored by using "undo" - this will change the values back, but not fix the alignment.
Comment 1 Wolfgang Denk 2019-05-19 14:24:26 UTC
Created attachment 151514 [details]
Initial state and formatting of the table.
Comment 2 Wolfgang Denk 2019-05-19 14:25:52 UTC
Created attachment 151515 [details]
State after changing content of <A1> : <C1> alignment corrupted
Comment 3 Drew Jensen 2019-05-19 14:54:40 UTC
Confirmed with Ubuntu 18.04.1 and LO 6.3 Alpha1 and 6.2.4 RC1
Test also with LO 6.0.7 and the behavior is not there.

As for fixing the display, if you place the cursor in the effected cell and then select 'Clear direct formatting' it fixes the display problem. 

I'll try a copy of 6.1 and either bibisect from there (if there) or against 6.2.
Comment 4 Oliver Brinzing 2019-05-19 16:16:22 UTC
(In reply to Wolfgang Denk from comment #0)

> If a table contains cells which are left-aligned, and which contain formula,
> there lose alignment and get automatically right-aligned after the displayed
> value changes due to data changed elsewhere.

this issue is maybe related to/a duplicate of:

> FileOpen: Formula result has different alignment than regular values
> https://bugs.documentfoundation.org/show_bug.cgi?id=124860

Could you please check settings in Menu Tools/Options.../LibreOffice Writer/Table

Input in Tables
[ ] Number recognition
  [ ] Number format recognition
  [ ] Alignment
Comment 5 Drew Jensen 2019-05-19 16:44:41 UTC
(In reply to Oliver Brinzing from comment #4)
> (In reply to Wolfgang Denk from comment #0)
> 
> > If a table contains cells which are left-aligned, and which contain formula,
> > there lose alignment and get automatically right-aligned after the displayed
> > value changes due to data changed elsewhere.
> 
> this issue is maybe related to/a duplicate of:
> 
> > FileOpen: Formula result has different alignment than regular values
> > https://bugs.documentfoundation.org/show_bug.cgi?id=124860
> 
> Could you please check settings in Menu Tools/Options.../LibreOffice
> Writer/Table
> 
> Input in Tables
> [ ] Number recognition
>   [ ] Number format recognition
>   [ ] Alignment


I did try setting number recognition in at least on of the test runs and didn't notice a difference - still waiting on the bibisect repos to finish updating, when that finishes and I start the run I'll make a point to try it again.

BTW - checking against 6.1 didn't show the error either.
Comment 6 Oliver Brinzing 2019-05-19 16:59:19 UTC
(In reply to Drew Jensen from comment #5)

if i change options (Version: 6.3.0.0.alpha0+ (x64)):

Input in Tables
 [ ] Number recognition
   [ ] Number format recognition
   [ ] Alignment

i cannot reproduce an alignment change after changing cell value in <A1> 

but with default settings:

Input in Tables
 [ ] Number recognition
   [x] Number format recognition
   [x] Alignment

alignment changes
Comment 7 Drew Jensen 2019-05-19 17:02:51 UTC
(In reply to Oliver Brinzing from comment #6)
> (In reply to Drew Jensen from comment #5)
> 
> if i change options (Version: 6.3.0.0.alpha0+ (x64)):
> 
> Input in Tables
>  [ ] Number recognition
>    [ ] Number format recognition
>    [ ] Alignment
> 
> i cannot reproduce an alignment change after changing cell value in <A1> 
> 
> but with default settings:
> 
> Input in Tables
>  [ ] Number recognition
>    [x] Number format recognition
>    [x] Alignment
> 
> alignment changes

I guess I should of checked that more deeply. 

So - by way of keeping some notes here. 

Using the first instance of the bibsect run: 
Version: 6.2.5.0.0+
Build ID: 6c3ceaf3e4d59c658d0f9e4e1b22204be25f74e2
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 

If Number recognition is not enabled then the error manifests.
If Number recognition w/Number format recognition only selected, it does not.
If Number recognition w/both Format and Alignment selected, error does manifest.
Comment 8 Drew Jensen 2019-05-19 17:13:43 UTC
(In reply to Drew Jensen from comment #7)
> (In reply to Oliver Brinzing from comment #6)
> > (In reply to Drew Jensen from comment #5)
> > 
> > if i change options (Version: 6.3.0.0.alpha0+ (x64)):
> > 
> > Input in Tables
> >  [ ] Number recognition
> >    [ ] Number format recognition
> >    [ ] Alignment
> > 
> > i cannot reproduce an alignment change after changing cell value in <A1> 
> > 
> > but with default settings:
> > 
> > Input in Tables
> >  [ ] Number recognition
> >    [x] Number format recognition
> >    [x] Alignment
> > 
> > alignment changes
> 
> I guess I should of checked that more deeply. 
> 
> So - by way of keeping some notes here. 
> 
> Using the first instance of the bibsect run: 
> Version: 6.2.5.0.0+
> Build ID: 6c3ceaf3e4d59c658d0f9e4e1b22204be25f74e2
> CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
> 
> If Number recognition is not enabled then the error manifests.
> If Number recognition w/Number format recognition only selected, it does not.
> If Number recognition w/both Format and Alignment selected, error does
> manifest.

Alright in the second pass: Version: 6.2.0.0.alpha1+
Build ID: 129d1fe9fdb448a764f6c181705a61d4db321904
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 

If Number recognition is not enabled then the error does not manifest.
If Number recognition w/Number format recognition only selected, it does not.
If Number recognition w/both Format and Alignment selected, the 'error' does manifest.

I'm going to treat any time it shows up as a bad run, for the purposes of this bibisect run. Will come back when all the runs are finished.
Comment 9 Drew Jensen 2019-05-19 17:23:47 UTC
well, actually, after reading all the comments on issue 124860 I'm a bit confused as to how to proceed. I can to find when the change was introduced with respect to the alignment change even when Number Recognition being disabled overall.

I also guess that this issue should be marked as a duplicate of 124860 and the results of the bibisect added as a comment there. 

Sound right to you?
Comment 10 Drew Jensen 2019-05-19 18:45:37 UTC
(In reply to Drew Jensen from comment #9)
> well, actually, after reading all the comments on issue 124860 I'm a bit
> confused as to how to proceed. I can to find when the change was introduced
> with respect to the alignment change even when Number Recognition being
> disabled overall.
> 
> I also guess that this issue should be marked as a duplicate of 124860 and
> the results of the bibisect added as a comment there. 
> 
> Sound right to you?

Alright well bibisect was no help, but then yet another read of that other issue and I suppose it wasn't really needed anyway. 

Simply closing this as a dupe of 124860

*** This bug has been marked as a duplicate of bug 124860 ***