Horrible and uncontrollable autoformatting in tables in Writer

I suspect the following issue is related to table styles.

In a table cell, I want to enter the code: 120.026. When moving to another cell (tab or click), this is converted to 120.03. A Ctrl+z will revert, but any movement outside the cell will redo the automatic change.

The styles in the new “Table styles” tab show all greyed out right-click options (except for build-in styles you can “Hide”, but it is not possible to delete custom styles when they are in use in a particular place). Nowhere else can I find possibilities to customize such style or disable any automated formatting at all.

Can somebody shed light on this, or is this indeed a horrendous regression and an example of poor design with no testing? Obviously not even be able to fight all kinds of automatic changes in data renders tables completely useless. I hope I am missing something here.

If you want your cell data to be unaltered by any behind-the-scene wizardry, make sure that Table>Number Recognition is unchecked.

Alternatively, you can assign a specific format to a cell, just like you would do in Calc, with Table>Number Format. Code @ means “text”, i.e. no tampering on what you entered.

These features were introduced to give a very limited spreadsheet capability to Writer table, but they seem to rather confuse users.

##Table styles

First of all, they are not “styles” like paragraph, character, frame, page and list styles. They are in fact a set of macros which are fired when various events occur. This means you can’t reformat simultaneously all tables based on the same “style” by modifying said style, were it possible.

The fact that the macros are implicitly relaunched to reformat the table, e.g. when you add a row or column, conflicts with user formatting of cell. Upon relaunch, the macros reset every cell formatting to its own internal design, wiping out any user modification.

If you accept as a whole the formatting defined by the “style”, you’ll have no problem. But if you use a “style” as a base for a user-modified table and add fancy formatting, be it a number format, you’re in trouble because the macros will work on your back.

IMHO, present macro-based table styles are probably an experimental implementation to ease simple spreadsheet-like cases. But, as they restrict user liberty and creativity, they should be avoided in user-decorated tables. When creating tables, the safe choice is None style. Of course, you’re then faced with a tedious manual formatting task but this formatting is guaranteed to be persistent.

CAVEAT EMPTOR!

Following OP’s request, I add this warning for whoever may be concerned.

A table “style” is “sticky”: once you have created a table with a style or formatted it with Table>Autoformat Styles, you can no longer revert to no style at all. The Default Table Style in Table>Autoformat Styles is just another macro-based “style” which will erase your user-applied additional cell formatting.

The only no-style-at-all possibility is to create a table with Table>Insert Table with a None style. There, you keep all formatting possibilities offered by Table>Properties. And, since no macro is involved, your formatting will be persistent.

The present table “style” behaviour has been frowned upon in bug tdf#138453.

To show the community your question has been answered, click the ✓ next to the correct answer, and “upvote” by clicking on the ^ arrow of any helpful answers. These are the mechanisms for communicating the quality of the Q&A on this site. Thanks!

In case you need clarification, edit your question (not an answer which is reserved for solutions) or comment the relevant answer.

  1. Table - Number Recognition is not a factor here: it was turned off 2) Changing the cell formatting works 3) Thanks for the background - I suppose that, once a “style” is applied to a table, there is no way to remove any style? I use LO since version 0.9. This is a design disaster.

Exactly. Since “table styles” are not common styles, there is no way to change the macros association.

I fully agree with your design disaster opinion. I didn’t want to appear dogmatic, but table styles should be avoided.

I accepted your answer. I would appreciate, however, that you clearly include a warning to the user that currently, once you do apply a Table Style, you cannot undo that anymore, preferably with reference to the existing bug report (tdf#138453)

@Vanadium

I would appreciate, however, that you clearly include a warning

The answer provided is from a user of LibreOffice and not a developer (This site is a Q&A site and users of LibreOffice answer questions of users of LibreOffice). If you want to address this to developers you need to create a feature / enhancement request at https://bugs.documentfoundation.org/

@anon73440385 It is fully justified that a user warns other users about a potential pitfall, and especially if that warning is backed by an existing bug report. For effectuating improvements to the feature, indeed enhancement requests are in place. In the end, I actually realized that life does not change for me: it is just that this feature now is more prominently present in 7.1 with the dedicated “Tab styles” tab.