Bug 49437 - Writer/Calc: Use XML for serializing table autoformats instead of the current brittle binary format
Summary: Writer/Calc: Use XML for serializing table autoformats instead of the current...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: high enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 107560 (view as bug list)
Depends on:
Blocks: 39548 Table-Styles 104389 Table-AutoFormat 133430 143349 152711 160074
  Show dependency treegraph
 
Reported: 2012-05-03 10:11 UTC by Muhammad Haggag
Modified: 2024-03-07 16:10 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Muhammad Haggag 2012-05-03 10:11:43 UTC
Table AutoFormats are currently stored in a binary file, "autotbl.fmt", that is pretty messy:
* It's not backwards compatible (old versions of Writer/Calc cannot open newer versions)
* It serializes a lot of implementation details, making it quite brittle
* It's harder to debug

This issue came up during the review thread for fdo#31005. Thread: http://nabble.documentfoundation.org/PATCH-fdo-31005-Table-Autoformats-does-not-save-apply-all-properties-td3936451.html

If someone's interested in doing this, I can provide help on the AutoFormat side of things (i.e. how the current format works).
Comment 1 Jean-Baptiste Faure 2012-05-06 08:10:58 UTC
Set to enhancement.
Comment 2 Regina Henschel 2016-08-30 15:02:58 UTC
This has become more important as with LO5.3 the table template parts of ODF are supported.

My suggestion is, to use document fragments like those, which you get, if you create an Autotext for a table. Such fragment can contain all information to design a table and in addition it can contain all information for column and row width and height settings, for the structure of the table, and for the needed numberformats, and it would allow to carry the definitions needed for gradient, hatch or pattern background.

There exists no backward compatibility problems, because the file "autotbl.fmt" only works as stencil to calculate the direct formating. The generated document has no back-reference to the file "autotbl.fmt".
Comment 3 Heiko Tietze 2017-10-13 15:44:39 UTC
@Gökhan: We talked during LibOCon about this topic. I guess the autotbl.fmt is read in https://opengrok.libreoffice.org/xref/core/sw/source/core/doc/tblafmt.cxx (but please check this first). Goal is to have an XML format that can be easily modifies. Background of the task is described in this blog post https://design.blog.documentfoundation.org/2015/12/13/style-your-tables/ Previous work was done in this GSoC project https://gist.github.com/ubap/55d22ef9b2e00347a2dc58ca4cb8b0ea

Don't hesitate to ask me or anyone else for help.
Comment 4 Heiko Tietze 2017-11-02 15:47:09 UTC
*** Bug 107560 has been marked as a duplicate of this bug. ***
Comment 5 Eike Rathke 2017-12-18 14:33:54 UTC
Note that both Writer and Calc use the table styles but have different detailed needs and need to be able to read, remember and write the others' details. See
for Writer the already mentioned
https://opengrok.libreoffice.org/xref/core/sw/source/core/doc/tblafmt.cxx
for Calc
https://opengrok.libreoffice.org/xref/core/sc/source/core/tool/autoform.cxx
Comment 6 Xisco Faulí 2018-03-19 15:24:48 UTC
Dear Gökhan Gurbetoğlu,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
Comment 7 Timur 2022-04-21 13:34:49 UTC
I set High as it blocks other bugs.
Comment 8 Eyal Rozenberg 2023-12-04 15:07:11 UTC
This problem would go away if we had actual table styles:

https://bugs.documentfoundation.org/show_bug.cgi?id=152711

If we could style a table, we would not need custom serializations, nor the very notion of table "autoformats", which are basically applications of DF for lack of something better.

Obviously I'm not against a localized solution of this issue, but I wonder if the emphasis should not be moved from pseudo-styles/auto-formats, which will probably be scrapped anyway, eventually, to taking the more fundamental approach.