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
Created attachment 150896 [details] number recognition
> 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
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.
Btw: I don't know why Oliver brings number-recognition into the topic, but Number-recognition is off by default in both versions.
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.
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?
(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.
The request to improve number recognition in bug 113241 has been done with https://gerrit.libreoffice.org/#/c/61065/ by Cor.
(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.
(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.
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.
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?
Created attachment 151159 [details] test file from 6142
Created attachment 151160 [details] test file from 6221
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.
(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,
Created attachment 151232 [details] table demostration alignment malfunction
Created attachment 151238 [details] file bugreportalignment_OpenedWith-OLD-Settings
Created attachment 151239 [details] file bugreportalignment_OpenedWith-NEW-Settings
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.
(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.
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...
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.
(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?
Created attachment 151242 [details] screen shot of LibO_Alignment-Bug-Demo_CHANGED_NEW-settings
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.
(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.
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.
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).
(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.
(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?
(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?
*** Bug 125371 has been marked as a duplicate of this bug. ***
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.
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!
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?
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.
(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.
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.