When we right mouse click on table in Writer, there is option "Number recognition". It has some problem: Currently "Number recognition" works globally. And when disabled, number format of cell resets to "Text" when we delete content of cell and type another. Expected: "Number recognition" can set individually for each table (otherwise it should be "Global number recognition"). And when disabled it not changes format of cells, just not recognize content. Actually: "Number recognition" enables/disables globally. And changes format of newly changed cells to "Text" Reproduced in 3.3.4 and 3.5.2 on Fedora 64 bit
Hi Sasha, as far as I tested the function, disabling of "Number recognition" does not change the number format of existing cells. Only if you change the content of a cell the number format is changed to "Text". And afterwords you can still assign new number formats to all cells. The help text of the option "Number recognition" says: "If *Number recognition* is not marked, numbers are saved in text format and are automatically left-aligned." The behaviour is not very transparent, but according to the description I think it is OK. So, to my opinion an individual "Number Recognition" is an enhancement, but not a bug. Harald
Currently (parallel installation of Master "LOdev 3.6.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 52348aa]" (tinderbox: Win-x86@6-fast, pull time 2012-04-27 21:25:23)) context menu shows and changes setting in menu 'Tools -> Options -> LibO WRITER -> Table - Input in Table - Number Recognition'. Indeed, it would be nice to have that for each individual cell. But IMHO we need some more definitions for such an enhancement (What setting with priority to what other one, how can we recognize cells with individual setting, ...). Without that additional research this request can not be fulfilled. May be ux-advise knows more? I will ask. The current limitation has been inherited from OOo.
It is a valid request - marking as NEW - also requesting input from ux. @UX team - once you guys come up with a plan here (or close as wontfix) please set component back to writer. Thanks!
Astron - sorry I added you instead of mailing list - you mind registering mailing list on FDO so I can make it default cc?
Joel: go ahead :)
I couldn't reproduce it in 4.3.3, to me everything works as expected. Is this still a problem?
Hi mahfiaz, (In reply to mahfiaz from comment #6) > I couldn't reproduce it in 4.3.3, to me everything works as expected. Is > this still a problem? Can you please explain what you tested? As fas as I can see, number recognition is a global setting for Writer. SO not per document, not per table, not per cell. See Tools > Options > Writer > Table ..
Cor, I made a table, set the number type for a few cells, inserted a number, deleted contents and wrote another number back. The cell preserved it's properties. It loses the properties if you enter text (e.g end your number with enter which creates a newline, make a mistake and enter a number and a space or something similar), so it can only contain a number or be blank for the properties to be preserved. It is picky, but it somewhat works. So I think improvement to make the cell preserve its numeric properties over containing some text (as it happens in Calc) would help (especially annoying with typing accidents like 0,3 vs 0.3 or "23,4 ", note the space). As for LO to also store the properties as global, it's mostly useful feature, but IMO not a bug and works as expected.
@mahfiaz, thanks for your explanation. But isn't that more at place for e.g. tdf#49419
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
(In reply to mahfiaz from comment #8) > So I think improvement to make the cell preserve its numeric properties over > containing some text (as it happens in Calc) would help (especially annoying > with typing accidents like 0,3 vs 0.3 or "23,4 ", note the space). I agree to that. Would make the issue of sacha.libreoffice mostly disappear? Mind to make a new issue for that?
(In reply to Cor Nouws from comment #11) > (In reply to mahfiaz from comment #8) > > > So I think improvement to make the cell preserve its numeric properties over > > containing some text (as it happens in Calc) would help (especially annoying > > with typing accidents like 0,3 vs 0.3 or "23,4 ", note the space). > > I agree to that. > Would make the issue of sacha.libreoffice mostly disappear? > Mind to make a new issue for that? Or it may even solve this issue..
(In reply to Cor Nouws from comment #12) > Or it may even solve this issue.. Proposed solution: manually set format could be kept / block the number recognition (Heiko) So reading the Help: https://help.libreoffice.org/7.0/en-US/text/shared/optionen/01040500.html?System=UNIX&DbPAR=WRITER&HID=modules/swriter/ui/opttablepage/OptTablePage#bm_id3148685 " ... When an input cannot be recognized as a number, the number category changes to Text and the input is not changed. If Number recognition is not marked, numbers are saved in text format and are automatically left-aligned. " the proposed solution should change the first paragraph here. And also a part of the Help section thereafter ("Number format recognition") would be affected. --- I wonder why the behavior: change back to Text when the input is not recognized, is chosen so consequently.. It may be interesting to ask a Calc/table hacker... @erack, Eike: would doing the proposed change cause any troubles maybe that you know?
We discussed the topic in the design meeting. First of all, setting number recognition per cell sounds like a bad plan. It's implemented as global feature with Tools > Options to enable and Table > Recognition to temporarily disable. The first idea was to keep the user-defined format so no recognition is done on cells where Text is set. But this might be a bit tricky since Text is the default. Since enabling number recognition means the user wants in most cases numbers to be formatted correctly and only in a few cases to not, the current workflow with reverting the automatically applied format is more effective than the other way. So we recommend to not change the feature.
(In reply to Heiko Tietze from comment #14) > .. But this might be a bit tricky since Text is the default. > .. > So we recommend to not change the feature. IMO an assumption is a weak grounds for decisions ..