Description: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ TABLE TEMPLATE IS NOT HONORED (IN LO 24.2 DAILY BUILDS) (In other words, non-compliance with ODF-v1.2 standard, when it comes to applying "Table Templates") Jambunathan K ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents ───────────────── 1. Description of files attached 2. LO version used Table Template is not honored (in LO 24.2 daily builds) (In other words, non-compliance with ODF-v1.2 standard, when it comes to applying "Table Templates") See the screenshots and annotation therein for the bug description. 1 Description of files attached ═══════════════════════════════ boxlistred-new.odt This ODT file has a table which "applies" a ODT Table Template called 'BoxListRed'. ('BoxListRed' is a verbatim copy of the "Box List Red" auto-format style that LO ships with; only the template, style and display name are changed.) I expect the Table to have Red Rows, because the table template, and the table definition explicitly request for "BoxListRed" style. (See notes below for details). Unfortunately, the Table appears "plain" with NO style at all applied. This unexpected behaviour is a bug. boxlistred-new.pdf The PDF version of above file, created with LO export styles.xml.png This file shows that XML definition of "BoxListRed" style, and the associated table cell styles – first/last row/col, even/odd row/col content.xml.png This shows the XML definition of a writer Table which uses "BoxListRed" as its template. It also says it wants to use the "first row", and "banding row" styles. boxlistred.org This is the Emacs Orgmode markup file used for creating the above "boxlistred-new.odt". What this means is that the ODT file is created by the Emacs Orgmode ODT exporter—think, markdown-to-ODT converter, if you aren't familiar with Emacs or Org-mode markup. This file is for submitter's reference. LO team can ignore it. scratch.org & scratch.txt Text of this bug report 2 LO version used ═════════════════ LO Version is 24.2 (Daily Builds).png ┌──── │ Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community │ Build ID: 5fecd865303b3f0a2eeb0b9466d2bcf23cfce068 │ CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3 │ Locale: de-AT (en_IN); UI: en-US │ Calc: threaded └──── ┌──── │ ~$ uname -a │ Linux debian 6.4.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.11-1 (2023-08-17) x86_64 GNU/Linux └──── ┌──── │ ~$ dpkg -l | grep libreofficedev | grep writer | grep 24.2 │ ii libreofficedev24.2-writer 24.2.0.0.alpha0-1 amd64 Writer brand module for LibreOfficeDev 24.2.0.0.alpha0 └──── Steps to Reproduce: Just open the ODT file. ODT file is created outside of LIbreOffice using Emacs Orgmode converter. See https://github.com/kjambunathan/org-mode-ox-odt. I am the author of the converter btw. Actual Results: Table uses "BoxListRed" style. I expect some Red colored rows. Unfortunately, LO fails to apply the BoxListRed template, and table appears "plain" Expected Results: I expect some RedColored Rows. Reproducible: Always User Profile Reset: No Additional Info: This is not only a bug, but a non-ODF-compliant behaviour.
Created attachment 189716 [details] ODF Table Template is not honored.zip: Contains all the files needed to work on this bug
Created attachment 189717 [details] styles.xml.png: BoxListRed table template is defined here
Created attachment 189718 [details] content.xml.png: Writer table wants to use "BoxListRed"
Comment on attachment 189718 [details] content.xml.png: Writer table wants to use "BoxListRed" This screenshot not only shows `content.xml' but also shows how the Table is rendered by LO 24.2
Created attachment 189719 [details] boxlistred-new.odt: The unit test file
Created attachment 189720 [details] boxlistred-new.pdf: The PDF file created LO from boxlistred-new.odt
https://github.com/kjambunathan/org-mode-ox-odt/issues/199#issuecomment-1727594279 Above link is for my (=submitter's) reference.
Created attachment 189818 [details] Bug is present in 7.5.5.2 Demo of problem on LO 7.5.5.x ``` ~/tmp000$ dpkg -l | grep writer | grep 7.5 ii libreoffice-writer 4:7.5.5-4 amd64 office productivity suite -- word processor ```
Created attachment 189819 [details] Bug is present in LibreOffice Dev 7.6.0 ``` ~/tmp000$ dpkg -l | grep writer | grep 7.6 ii libreofficedev7.6-writer 7.6.0.0.alpha0-1 amd64 Writer brand module for LibreOfficeDev 7.6.0.0.alpha0 ```
I have confirmed the bug in three different versions of LO - 7.5.5.2 - 7.6.0.0 - 24.2.0.0 See the screenshots. The bug was originally filed against 24.2, and now I am "revising" the version all the way down to "7.5.5.x" (the version that comes with Debian Unstable ca Sept 26, 2023) Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Debian package version: 4:7.5.5-4 Calc: threaded Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4bcf6d9c905e7b5558ee8d9f7f616ce61eadb8f8 CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: de-AT (en_IN); UI: en-US Calc: threaded Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5fecd865303b3f0a2eeb0b9466d2bcf23cfce068 CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: de-AT (en_IN); UI: en-US Calc: threaded
(In reply to Jambunathan K from comment #0) > boxlistred-new.odt > This ODT file has a table which "applies" a ODT Table Template > called 'BoxListRed'. ('BoxListRed' is a verbatim copy of the > "Box List Red" auto-format style that LO ships with; only the > template, style and display name are changed.) > > I expect the Table to have Red Rows, because the table template, > and the table definition explicitly request for "BoxListRed" > style. (See notes below for details). > > Unfortunately, the Table appears "plain" with NO style at all > applied. This unexpected behaviour is a bug. Do you mean you have manually changed the .xml files? If so, it would be good, if you provided diff files of the changes. Maybe you already use it, but you can make the XML in your documents be saved pretty printed by going to Tools - Options - Advanced - Open Expert Configuration, search: pretty. Set PrettyPrinting to true. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
Created attachment 190147 [details] lo-bug-157350-table-template-not-working.zip This attachment was produced in response to https://bugs.documentfoundation.org/show_bug.cgi?id=157350#c11 - lo-bug-157350-table-template-not-working.zip :: Contains all the details needed for this bug report - boxlist-red-yet-again-1.odt :: An empty 5x5 table with Box List Red applied. The table is rendered with color - boxlist-red-yet-again-1.pdf :: PDF version of the above ~odt~ file - boxlist-red-yet-again-2.odt :: Copy ~boxlist-red-yet-again-1.odt~ and do renamings as below. The renamings are done with a text editor. In ~styles.xml~, do the following re-namings. #+begin_src emacs-lisp (("Box List Red" "BoxListRed") ("Box_20_List_20_Red.10" "BoxListRedTableBackgroundCell") ("Box_20_List_20_Red.8" "BoxListRedTableOddColumnsCell") ("Box_20_List_20_Red.7" "BoxListRedTableEvenColumnsCell") ("Box_20_List_20_Red.6" "BoxListRedTableOddRowsCell") ("Box_20_List_20_Red.5" "BoxListRedTableEvenRowsCell") ("Box_20_List_20_Red.9" "BoxListRedTableBodyCell") ("Box_20_List_20_Red.4" "BoxListRedTableLastColumnCell") ("Box_20_List_20_Red.3" "BoxListRedTableFirstColumnCell") ("Box_20_List_20_Red.2" "BoxListRedTableLastRowCell") ("Box_20_List_20_Red.1" "BoxListRedTableFirstRowCell")) #+end_src In ~content.xml~, do the following re-naming. #+begin_src emacs-lisp (("Box List Red" "BoxListRed")) #+end_src Also, strip the ~table:style-name~ attribute from all the ~table:table-cell~ elements of the table. Confirm that above XML files are well-formed according to the ODF rng schema. - boxlist-red-yet-again-1-to-2.diff :: This diff file shows what renamings have been done. - boxlist-red-yet-again-2.pdf :: PDF export of the above ~odt~ file. - boxlist-red-yet-again-2 :: Unzipped version of ~boxlist-red-yet-again-2.odt~ * Bug description - Open ~boxlist-red-yet-again-2.odt~ - Note that the table has no colors The expected behaviour is that table in ~boxlist-red-yet-again-2~ should be rendered just the same way as ~boxlist-red-yet-again-1~.
(In reply to Buovjaga from comment #11) > (In reply to Jambunathan K from comment #0) > > boxlistred-new.odt > > This ODT file has a table which "applies" a ODT Table Template > > called 'BoxListRed'. ('BoxListRed' is a verbatim copy of the > > "Box List Red" auto-format style that LO ships with; only the > > template, style and display name are changed.) > > > > I expect the Table to have Red Rows, because the table template, > > and the table definition explicitly request for "BoxListRed" > > style. (See notes below for details). > > > > Unfortunately, the Table appears "plain" with NO style at all > > applied. This unexpected behaviour is a bug. > > Do you mean you have manually changed the .xml files? If so, it would be > good, if you provided diff files of the changes. Maybe you already use it, > but you can make the XML in your documents be saved pretty printed by going > to Tools - Options - Advanced - Open Expert Configuration, search: pretty. > Set PrettyPrinting to true. > > Set to NEEDINFO. > Change back to UNCONFIRMED after you have provided the information. See https://bugs.documentfoundation.org/attachment.cgi?id=190147
(In reply to Jambunathan K from comment #12) > Created attachment 190147 [details] > lo-bug-157350-table-template-not-working.zip I have tested that the hand-modified ODF table is NOT colored in ALL 3 version of LO you see below Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2a217a80bf383ddab0a5e0959ab2fd907dfd3406 CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4bcf6d9c905e7b5558ee8d9f7f616ce61eadb8f8 CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Debian package version: 4:7.5.5-4 Calc: threaded
Not sure what is going on here. The style itself is not correct, as applying it to a table won't use the expected red style. If I edit the modified file, save it again and extract it, the styles.xml will have all elements renamed using the "styleName.digit" structure. (And the table cell styles have no custom attributes whatsoever, hence the vanilla table.) So does one have to stick to the "styleName.digit" naming? Regina, any idea? Is that numbering thing an ODF thing or imposed only by LO?
You need to remove direct formatting from the table. Otherwise the styles from the template will not become active.
(In reply to Regina Henschel from comment #16) > You need to remove direct formatting from the table. Otherwise the styles > from the template will not become active. Thank you Regina for pointing what should have been my obvious first try, before digging into the XML... Jambunathan, if you clear the table's direct formatting in both the before and after ODTs, you'll end up with the same formatting. Can you please check that your script also deals with (removing) direct formatting, so your custom table style is actually visible? If there is a remaining issue, maybe better to start fresh with a new report. So closing as "not a bug".
(In reply to Stéphane Guillou (stragu) from comment #17) > (In reply to Regina Henschel from comment #16) > > You need to remove direct formatting from the table. Otherwise the styles > > from the template will not become active. > > Thank you Regina for pointing what should have been my obvious first try, > before digging into the XML... > > Jambunathan, if you clear the table's direct formatting in both the before > and after ODTs, you'll end up with the same formatting. There is NO direct formatting in the second table ... There are really no style names attached to any of the table row entities -- table, col, row, or cell --- apart from the template name. ```xml <table:table table:name="Table1" table:template-name="BoxListRed"> <table:table-column table:number-columns-repeated="5"/> <table:table-row> <table:table-cell office:value-type="string"> <text:p text:style-name="P1"/> </table:table-cell> <table:table-cell office:value-type="string"> <text:p text:style-name="P1"/> </table:table-cell> <table:table-cell office:value-type="string"> <text:p text:style-name="P1"/> </table:table-cell> <table:table-cell office:value-type="string"> <text:p text:style-name="P1"/> </table:table-cell> <table:table-cell office:value-type="string"> <text:p text:style-name="P1"/> </table:table-cell> </table:table-row> <table:table-row> <table:table-cell office:value-type="string"> <text:p text:style-name="P2"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P2"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P2"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P2"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P2"/> </table:table-cell> </table:table-row> <table:table-row> <table:table-cell office:value-type="string"> <text:p text:style-name="P2"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P2"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P2"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P2"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P2"/> </table:table-cell> </table:table-row> <table:table-row> <table:table-cell office:value-type="string"> <text:p text:style-name="P2"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P2"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P2"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P2"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P2"/> </table:table-cell> </table:table-row> <table:table-row> <table:table-cell office:value-type="string"> <text:p text:style-name="P3"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P3"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P3"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P3"/> </table:table-cell> <table:table-cell> <text:p text:style-name="P3"/> </table:table-cell> </table:table-row> </table:table> ``` Just to be sure, I nuked the paragraph styles with following regexp replacement text:style-name=".*?" → When I load the ODT file, I see plain vanilla table. I also opened the hand-modified ODT file in LO, did Table->Select->Table and did Format->Clear Direct Formatting. The table continues to remain vanilla ... > > Can you please check that your script also deals with (removing) direct > formatting, so your custom table style is actually visible? I think we have different notions of what "direct formatting" means. To me, if an element is LEAVES OUT the style name attribute, it has NO formatting whatsoever (including direct formatting / content.xml-specific automatic styles) May I know how you "removed direct formatting" from the ODT file I shared. > If there is a remaining issue, maybe better to start fresh with a new > report. So closing as "not a bug". May be there is no bug LO ... I think you can help me with clearing the bug in my understanding. Could you please share the recipe on how you hand-fixed the ODT xml. If you have a diff, I will be happy to take a look at it.
(In reply to Stéphane Guillou (stragu) from comment #17) > (In reply to Regina Henschel from comment #16) > > You need to remove direct formatting from the table. Otherwise the styles > > from the template will not become active. > > Thank you Regina for pointing what should have been my obvious first try, > before digging into the XML... > > Jambunathan, if you clear the table's direct formatting in both the before > and after ODTs, you'll end up with the same formatting. When you say "clear direct formatting" did you attach the table cells to the table styles from styles.xml ... My assumption was that when the table style names are left out-----that is, NO direct formatting (with names from content.xml-local automatic styles), or NO custom formatting (with names from styles.xml-local custom styles)----- then LO should look at the table template name to infer the cell styles, and attach the respective style (with same names as style that appears in styles.xml or an automatic name whose XML definition is same as what appears in styles.xml) I really would like to see your hand-edited XML file. (If you re-save LO rewrites XML, and it gets difficult track with automatically generated numbers) I will be happy if Regina or you could clarify what you tried at your end. If you share an artefacts that you created as part of investigating this bug, please share it, before you throw it away.
I can reproduce the problem. The wish here is to have true table styles. Currently it works only as template when generating a table or re-applying a template. When the template is assigned, this generates direct formatting of table, column, row and cells. An intermediate solution could perhaps be to generate these direct formatting from the template when opening a file and overwrite its settings in case there exists already direct formatting in the file. I thought we have already a report about true table styles, but cannot find it.
(In reply to Regina Henschel from comment #20) > I can reproduce the problem. Thanks for re-opening the issue. The examples I have given are the simplest, in the sense that their hand-rolled, and has very bare essentials. Futhermore, my use-case is unique. The converter I am using--rather the one I am authoring and maintaining--doesn't use SDKs and relies on what XML LO already generates and improvises on it for simplicity. From the "Standard Compliance" case perspective, the independently rolled converter tests the LO in unique ways. Having the issue open, ensures that my test case is available for someone to validate against. (Closing the issue means that my test case would remain lost in the haystack) IOW, keep the issue open not for the FR its making but for supplying a unique test case. Also I have been working on my Emacs-lisp based converter close to a decade, and I have personally felt that the Writer was seriously lacking in table cell style department, and ... I sensed that there is some momentum in getting Table Template and Table Cell styles formally blessed, and I wanted to make hay while the sun was shining. > The wish here is to have true table styles. Currently it works only as > template when generating a table or re-applying a template. When the > template is assigned, this generates direct formatting of table, column, row > and cells. > > An intermediate solution could perhaps be to generate these direct > formatting from the template when opening a file and overwrite its settings > in case there exists already direct formatting in the file. > > I thought we have already a report about true table styles, but cannot find > it. Are you thinking of [Bug 34391 - FORMATTING: Introduce table cell styles (edit) ](https://bugs.documentfoundation.org/show_bug.cgi?id=34391) which has the following remark [Changing enhancement priority to 'high' since the number of people in CC is higher than 20](https://bugs.documentfoundation.org/show_bug.cgi?id=34391#c28) May be that bug will help you dig in to better reports.
> [Changing enhancement priority to 'high' since the number of people in CC is > higher than > 20](https://bugs.documentfoundation.org/show_bug.cgi?id=34391#c28) > > > May be that bug will help you dig in to better reports. You may at your discretion want to tag this bug with [Table Autoformat](https://bugs.documentfoundation.org/show_bug.cgi?id=113208) bucket
(In reply to Regina Henschel from comment #20) > I can reproduce the problem. > > The wish here is to have true table styles. > > I thought we have already a report about true table styles, but cannot find > it. This is perhaps bug 152711.
(In reply to Regina Henschel from comment #20) > I can reproduce the problem. I think the bug should move away from the current `UNCONFIRMED` state .
(In reply to Jambunathan K from comment #24) > (In reply to Regina Henschel from comment #20) > > I can reproduce the problem. > > I think the bug should move away from the current `UNCONFIRMED` state . I've changed status to NEW. But following Regina in comment 20 this report is a wish for true table styles. And this is already bug 152711. So can we mark it as aduplicate?
(In reply to Dieter from comment #25) > (In reply to Jambunathan K from comment #24) > > (In reply to Regina Henschel from comment #20) > > > I can reproduce the problem. > > > > I think the bug should move away from the current `UNCONFIRMED` state . > > I've changed status to NEW. Thanks > But following Regina in comment 20 this report > is a wish for true table styles. And this is already bug 152711. My use case is unique. I don't understand what "true table styles" mean ... but I am willing to play along, and pretend that this bug will be addressed as part of 152711. For now, I have added myself to the cc list of bug 152711, > So can we mark it as a duplicate? No issues.
Considering how much of a bigger task implementing table styles is, and seeing Regina's idea for an intermediate solution: (In reply to Regina Henschel from comment #20) > An intermediate solution could perhaps be to generate these direct > formatting from the template when opening a file and overwrite its settings > in case there exists already direct formatting in the file. ... let's keep as "new".