Bug Hunting Session
Bug 124860 - FileOpen: Formula result has different alignment than regular values
Summary: FileOpen: Formula result has different alignment than regular values
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, needsDevEval, regression
: 125371 (view as bug list)
Depends on:
Blocks: Writer-Tables-Number-Recognition Options-Dialog-Writer
  Show dependency treegraph
 
Reported: 2019-04-20 13:35 UTC by bugzilla2
Modified: 2019-05-28 08:20 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
number recognition (18.68 KB, image/png)
2019-04-20 14:46 UTC, Oliver Brinzing
Details
comparison of table-formatting in 6.1.5 and 6.2.3 (38.61 KB, image/png)
2019-04-20 15:08 UTC, bugzilla2
Details
number recognition alignment disabled (20.19 KB, image/png)
2019-04-20 16:28 UTC, Oliver Brinzing
Details
Demonstration of unwanted format change with alignment ON (38.63 KB, image/png)
2019-05-02 17:30 UTC, bugzilla2
Details
test result in PDF (153.64 KB, application/pdf)
2019-05-03 14:35 UTC, Cor Nouws
Details
test file from 6142 (40.32 KB, application/vnd.oasis.opendocument.text)
2019-05-03 14:36 UTC, Cor Nouws
Details
test file from 6221 (49.52 KB, application/vnd.oasis.opendocument.text)
2019-05-03 14:36 UTC, Cor Nouws
Details
table demostration alignment malfunction (53.62 KB, application/vnd.oasis.opendocument.text)
2019-05-08 05:42 UTC, D.F.
Details
file bugreportalignment_OpenedWith-OLD-Settings (94.89 KB, image/png)
2019-05-08 10:45 UTC, Cor Nouws
Details
file bugreportalignment_OpenedWith-NEW-Settings (95.23 KB, image/png)
2019-05-08 10:45 UTC, Cor Nouws
Details
Demo File and Screenshots for easy reproduction of alignment-issue (82.99 KB, application/zip)
2019-05-08 11:26 UTC, bugzilla2
Details
screen shot of LibO_Alignment-Bug-Demo_CHANGED_NEW-settings (44.25 KB, image/png)
2019-05-08 11:51 UTC, Cor Nouws
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bugzilla2 2019-04-20 13:35:53 UTC
Description:
Since LibO 6.2 the table-formatting in Writer behaves different than in previous versions. The result of a formula is placed at the bottom of a cell, opposite to regular values that are placed on the top of the cell

Steps to Reproduce:
1. Start Writer and create a 3x3 cell table
2. write 10:00 in first (a1) and 11:00 in second (b1) cell
3. place formula "=<B1>-<A1>" in third cell (c1)
4. make height of first row bigger

Actual Results:
The Result value (cell C1) is at the bottom of the cell. A1 and B1 are at the top.

Expected Results:
The content of all three cells should be at the top of the cells (behavior up to version 6.1.5)


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.2.3.2
Build-ID: aecc05fe267cc68dde00352a451aa867b3b546ac
CPU-Threads: 12; BS: Windows 10.0; UI-Render: GL; VCL: win; 
Gebietsschema: de-AT (de_AT); UI-Sprache: de-DE
Calc: CL
Comment 1 Oliver Brinzing 2019-04-20 14:46:09 UTC
Created attachment 150896 [details]
number recognition
Comment 2 Oliver Brinzing 2019-04-20 14:47:56 UTC
> The Result value (cell C1) is at the bottom of the cell. A1 and B1
> are at the top.
> The content of all three cells should be at the top 
> of the cells (behavior up to version 6.1.5)

I can't see a difference, attached picture shows behaviour with LO 6.1.4.2.

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

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

I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the issue is still present
Comment 3 bugzilla2 2019-04-20 15:08:05 UTC
Created attachment 150897 [details]
comparison of table-formatting in 6.1.5 and 6.2.3

> I can't see a difference, attached picture shows behaviour with LO 6.1.4.2.
> 
> Could you please check settings in Menu Tools/Options.../LibreOffice
> Writer/Table

Don't know why it looks "wrong" at your screenshot. Sure, that this is the default config (profile reset?). Look at my comparison, you can clearly see the difference between 6.1.5 and 6.2.3. For the screenshot, both profiles were reset.
Comment 4 bugzilla2 2019-04-20 15:14:20 UTC
Btw: I don't know why Oliver brings number-recognition into the topic, but Number-recognition is off by default in both versions.
Comment 5 Oliver Brinzing 2019-04-20 16:28:28 UTC
Created attachment 150898 [details]
number recognition alignment disabled

(In reply to bugzilla2 from comment #4)
> Btw: I don't know why Oliver brings number-recognition into the topic, but
> Number-recognition is off by default in both versions.

i noticed that with disabled "Alignment" the behaviour is different, even if number recognition is disabled too.
Comment 6 bugzilla2 2019-04-20 17:36:43 UTC
Ah, ok, I got it now...

So, the problem is, that "alignment" (Options -> Writer -> Table -> Number-Recognition -> Alignment) is checked by default in 6.2 series, where it was unchecked in previous versions.

So, why is it checked by default now? And can we revert this change to restore "compatibility" to existing documents?
Comment 7 Oliver Brinzing 2019-04-21 06:09:41 UTC
(In reply to bugzilla2 from comment #6)
> So, the problem is, that "alignment" (Options -> Writer -> Table ->
> Number-Recognition -> Alignment) is checked by default in 6.2 series, where
> it was unchecked in previous versions.

indeed, setting issue to "NEW".

the question is, if there was a reason to change the setting from:

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

to

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

it's a bit confusing, cause one has to enable "[x] Number recognition" before 
the "[x] Alignment" can be disabled.
Comment 8 Heiko Tietze 2019-04-23 10:12:45 UTC
The request to improve number recognition in bug 113241 has been done with 
https://gerrit.libreoffice.org/#/c/61065/ by Cor.
Comment 9 bugzilla2 2019-04-29 09:51:15 UTC
(In reply to Heiko Tietze from comment #8)
> The request to improve number recognition in bug 113241 has been done with 
> https://gerrit.libreoffice.org/#/c/61065/ by Cor.

The number recognition can be left ON. But disabling the alignment switch by default would restore compatibility to documents that were saved with versions prior to 6.2.x.
Comment 10 Cor Nouws 2019-04-30 17:04:21 UTC
(In reply to bugzilla2 from comment #9)
> The number recognition can be left ON. But disabling the alignment switch by
> default would restore compatibility to documents that were saved with
> versions prior to 6.2.x.

Existing documents are not changed on opening.
But yes, if one edits an existing document, the behavior is changed.
This is then something the user has to fiddle out. And to be honest, as far as I know, not been considered with creating the change.

Of course the choice in bug 113241 was deliberate - allowing the creation of better default tables by default for all users, preventing people to hassle with tabs, outline, spaces .. ;|
So my choice would be to leave it as it is now.
A nice blog to get some attention and for easy reference, would be good of course.
Comment 11 bugzilla2 2019-05-02 17:30:02 UTC
Created attachment 151136 [details]
Demonstration of unwanted format change with alignment ON

(In reply to Cor Nouws from comment #10)
> Existing documents are not changed on opening.

This is simply wrong! As you can see in my new screenshot, the formatting of a existing document (created with alignment OFF) IS changed when opened with alignment ON.
Comment 12 Cor Nouws 2019-05-03 14:35:47 UTC
Created attachment 151158 [details]
test result in PDF

(In reply to bugzilla2 from comment #11)
> (In reply to Cor Nouws from comment #10)
> > Existing documents are not changed on opening.
> 
> This is simply wrong! As you can see in my new screenshot, the formatting of
> a existing document (created with alignment OFF) IS changed when opened with
> alignment ON.

That is odd. I'm sure it does not in my case. See attached.
What do we do in a different way?
Comment 13 Cor Nouws 2019-05-03 14:36:19 UTC
Created attachment 151159 [details]
test file from 6142
Comment 14 Cor Nouws 2019-05-03 14:36:44 UTC
Created attachment 151160 [details]
test file from 6221
Comment 15 D.F. 2019-05-07 13:04:28 UTC
I can confirm, that existing documents get changed when opened.

We do use a certain template that was last edited using libre office 6.1.2 portable.

With LO 6.2.2.2 portable the aligment behaviour does change when opening the document.

With settings like this alignment gets changed:
[ ] Number recognition
  [x] Number format recognition
  [x] Alignment


With settings like this alignment does not get changed.
[ ] Number recognition
  [ ] Number format recognition
  [ ] Alignment

If number recognition is turned off the other two options should be disabled as well as they are greyed out.
Comment 16 Cor Nouws 2019-05-07 19:09:06 UTC
(In reply to D.F. from comment #15)
> I can confirm, that existing documents get changed when opened.

Can you please provide a test file? Thanks,
Comment 17 D.F. 2019-05-08 05:42:40 UTC
Created attachment 151232 [details]
table demostration alignment malfunction
Comment 18 Cor Nouws 2019-05-08 10:45:23 UTC
Created attachment 151238 [details]
file bugreportalignment_OpenedWith-OLD-Settings
Comment 19 Cor Nouws 2019-05-08 10:45:59 UTC
Created attachment 151239 [details]
file bugreportalignment_OpenedWith-NEW-Settings
Comment 20 Cor Nouws 2019-05-08 10:46:58 UTC
two screen prints, made in Version: 6.3.0.0.alpha0+
Build ID: 98630a0bd49bd80652145a21e4e0d0ded792b36b
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-04_04:44:35
Locale: nl-NL (nl_NL.UTF-8); UI-Language: en-US
Calc: threaded


Sorry, but I don't see the difference.
Comment 21 bugzilla2 2019-05-08 10:55:31 UTC
(In reply to Cor Nouws from comment #20)
> Sorry, but I don't see the difference.

You are right, I think he confused the screenshots ;)

The screenshots I have posted already ("comparison of table-formatting in 6.1.5 and 6.2.3" and "Demonstration of unwanted format change with alignment ON") shows the misbehavior well enough I think.
Comment 22 bugzilla2 2019-05-08 11:07:33 UTC
OMG, shame on me. I should have read more carefully before posting. I didn't get the point, that both screenshots and the "Sorry, but I don't see the difference." are from the same person...
Comment 23 bugzilla2 2019-05-08 11:26:42 UTC
Created attachment 151240 [details]
Demo File and Screenshots for easy reproduction of alignment-issue

I think with this file everybody should be able to easily reproduce the bug. Screenshots of old a new behavior is included in the zip.
Comment 24 Cor Nouws 2019-05-08 11:49:57 UTC
(In reply to bugzilla2 from comment #22)
> OMG, shame on me. I should have read more carefully before posting.
NP - I do have that regularly too .. :\

(In reply to bugzilla2 from comment #23)
> Created attachment 151240 [details]
> Demo File and Screenshots for easy reproduction of alignment-issue
Thanks!

It looks like we found some other bug:
If I change one of the 01:00 values to say 21:00, that is unchanged when opening with the new settings.
Can you please check that?
Comment 25 Cor Nouws 2019-05-08 11:51:44 UTC
Created attachment 151242 [details]
screen shot of LibO_Alignment-Bug-Demo_CHANGED_NEW-settings
Comment 26 bugzilla2 2019-05-08 11:55:42 UTC
Thats because you replaced a formula value with a regular value. As noted in my initial report of the issue (and also in the outline), its about regular values and formula results getting different formatting with the new settings.
Comment 27 Cor Nouws 2019-05-09 13:20:40 UTC
(In reply to bugzilla2 from comment #26)
> Thats because you replaced a formula value with a regular value. As noted in
> my initial report of the issue (and also in the outline), its about regular
> values and formula results getting different formatting with the new
> settings.
Got it. (Bit late, to be honest, but I think I've reasons to forgive myself for that ;) ) Thanks for you patience!
I think the reason is clear: formula content of cells has to be evaluated on opening the document.

Test: 
 - create old settings
 - open your file 
   > all as it was
 - change settings
 - File > Reload
   > changes are there.

So I guess this can be achieved: if Number Recognition is off, the other two should not be evaluated. Not sure if it's easy (*). 
  ( @devs: any code pointers of where to look? )

If it won't be picked up (by me - agenda :( - or someone else) to change that, I tend to say that the disadvantage of changing older files puts in more weight than the advantage of a more logic default setting.

*) not to mention another possibility of storing table data on saving, as is done with spreadsheets.
Comment 28 bugzilla2 2019-05-10 09:17:04 UTC
I'd wish we can simply change the default options back to what they were before 6.2, so we can have a good 6.2.4 release. Thats the fast shot.

After that, it can be safely discussed how to make number-recognition on by default, without breaking compatibility to existing documents.
Comment 29 bugzilla2 2019-05-10 09:19:19 UTC
Btw, Number recognition can be left ON, its the "alignment"-switch that causes the troubles (and I don't even know what it shall be good for).
Comment 30 Cor Nouws 2019-05-11 17:34:06 UTC
(In reply to bugzilla2 from comment #29)
> Btw, Number recognition can be left ON, its the "alignment"-switch that
And then have someone with formulas but without number formatting, seeing changes maybe ;)

> causes the troubles (and I don't even know what it shall be good for).
Aligning numbers right is not uncommon.(In reply to bugzilla2 from comment #28)

> I'd wish we can simply change the default options back to what they were
I think that is best. And then later when import is changed, reapply.
Comment 31 bugzilla2 2019-05-14 12:32:35 UTC
(In reply to Cor Nouws from comment #30)
> > I'd wish we can simply change the default options back to what they were
> I think that is best. And then later when import is changed, reapply.

Can we have that in 6.2.4 RC2?
Comment 32 Cor Nouws 2019-05-15 07:34:12 UTC
(In reply to bugzilla2 from comment #31)
> Can we have that in 6.2.4 RC2?
I'm not too familiar with that process and way too busy until Monday. @heiko: can you help here please?
Comment 33 Drew Jensen 2019-05-19 18:45:37 UTC
*** Bug 125371 has been marked as a duplicate of this bug. ***
Comment 34 Drew Jensen 2019-05-19 18:50:27 UTC
I tired running bibisect against this (for the duplicate issue) and couldn't come up with a reasonable commit for where it came in, but I did not run against the gap repo between 6.1 and 6.2, maybe it was during that time frame. Though it looks like that isn't needed actually 

Just to agree with some folks here, it would seem reasonable that when Number Recognition is disabled overall it should not matter if Alignment is selected or null, and that is what I would call an anomaly.
Comment 35 Wolfgang Denk 2019-05-20 06:44:27 UTC
I tried all combinations of of settings for Number recognition / Number format recognition / Alignment and could not find a setting that actually prevented the horizontal alignment issue reported in Bug 125371l; this is in v6.2.3.2 (to be exact: 6.2.3.2-1.fc30 in Fedora).

From a user point of view this is clearly a bug, as you simply don't notice when aligment of one or a few cells changes in a bigger table, eventually even on the next page so you don't actually see it move.

*Please* fix!  Thanks!
Comment 36 Heiko Tietze 2019-05-23 09:44:05 UTC
To summarize, we have these issues:

1. When opening existing documents the table content is realigned depending on Tools > Options > Writer > Table (see c11) (this issue is relevant whether we default to on or off since the user may change it manually but wouldn't expect that just opening a document applies it)

2. The layout of newly inserted tables may differ if the option was changed meanwhile (again, this is independent from the default).

3. Aligning numbers to the bottom just for formulas is bad. I don't see any reason to have some values at top and other at middle or bottom depending on number, date/time, or text and I'm not aware of a norm.

4. The hierarchy of Number Recognition and underlying items is wrong resp. not respected in the code (as commented in c34, the disabled parent applies to the children)


We should definitely solve #1. For #2 we could inherit the default option into a document setting (Format > Page) and store it (wouldn't do that). Or we remove the alignment option completely (#3). By doing this a single "[x] Number Format Recognition" checkbox could be enough (and solves #4). 
The easiest but not the best solution for the regression is to revert the patch, of course.

Any opinion, Regina, Michael?
Comment 37 Cor Nouws 2019-05-23 17:57:36 UTC
Since reapplying the patch, after the issue is solved, is easy, I reverted the patch. https://gerrit.libreoffice.org/#/c/61065/
This also allows to look at the other ideas / topic mentioned by Heiko.
Comment 38 bugzilla2 2019-05-26 11:32:46 UTC
(In reply to Cor Nouws from comment #37)
> I reverted the patch. https://gerrit.libreoffice.org/#/c/61065/

Thanks for restoring the old behavior :) Just a pity we didn't get it in time for 6.2.4 release...


(In reply to Heiko Tietze from comment #36)
> 3. Aligning numbers to the bottom just for formulas is bad.
> I don't see any reason to have some values at top and other at
> middle or bottom depending on number, date/time, or text
> and I'm not aware of a norm.

That  confused me too. Doesn't make any sense to me.


(In reply to Heiko Tietze from comment #36)
> we could inherit the default option into a document setting
> (Format > Page) and store it (wouldn't do that). Or we remove the
> alignment option completely (#3).

I think all options that have impact on formatting of a document should be saved IN the document and not in a application setting. So moving this option into the stylesheet was my first idea too. But, if no one can give a good reason why the alignment option exists at all, removing it would be a lot easier of course.
Comment 39 Heiko Tietze 2019-05-28 08:19:55 UTC
Closing this issue as fixed. I filed bug 125544 as follow-up, please keep an eye on the progress, Cor, so we can change the default later.