Writer has styles for tables - which are a useful feature. But such styles are a _critical_ feature in Impress, where styling - colors, borders, etc. - see even more use than in Writer. So, please add table style support to Impress(/Draw). I should also mention that trying to apply general "drawing styles" to tables or to table cells doesn't seem to do anything. PS - I needed these for my LOCon 2022 presentations - and they were missing. You got uglier presentations because of this...
The inability to assign a "drawing style" to a table may or may not be bug 99852; but we should have table styles, proper.
Just to clarify - this feature would mostly replace the "Table Design" functionality we have right now, although maybe the existing UI for showcasing table designs/styles could stay.
I don't understand how a "proper table styles" feature would differ from the existing table design feature. Maybe instead of replacing the existing feature with something else (whatever it is), we should just invest in finishing it - e.g. provide a UI for editing the designs, creating new ones, etc. ?
(In reply to Maxim Monastirsky from comment #3) > I don't understand how a "proper table styles" feature would differ from the > existing table design feature. Maybe instead of replacing the existing > feature with something else (whatever it is), we should just invest in > finishing it - e.g. provide a UI for editing the designs, creating new ones, > etc. ? We're actually in agreement, I think. "Table designs"... * Are not named * Cannot be edited * Changes to a single design don't apply to tables already set to have that design (this is trivially true since they can't be changed) * Don't have default paragraph styles * Aren't hierarchical * Can't get embedded in the document (IAANM) ... in other words - what they're missing are the features of proper styles.
(In reply to Eyal Rozenberg from comment #4) > "Table designs"... > > * Are not named They are named internally, although we don't expose their names in the UI. > * Don't have default paragraph styles This is problematic for two reasons: First, there is no support for paragraph styles in Impress right now, not just in the context of tables. Second, even if there were paragraph styles, it's unclear how to integrate them with table designs. Currently table designs are implemented using the ODF <table:table-template> feature (much like table styles in Writer), which is basically a set of cell styles describing different parts of the table (e.g. the style of the first row, the last row etc.). And cell styles can't reference paragraph styles (AFAIK), but they can have text and paragraph properties on their own via <style:text-properties> and <style:paragraph-properties>. So while I'm unsure you can expect paragraph styles to work here, you can certainly expect to be able to define text properties as part of a table design itself. In fact, it seems to already work to some extent: Manually adding a <style:text-properties> element to a cell style of a table design seems to be picked by Impress and work happily (and even survive export). So the biggest problem seems to be the lack of a UI for modifying it. > * Aren't hierarchical That's also problematic, as ODF table templates don't seem to support inheritance. One way around it might be to implement support for cell styles (that's it, styles applicable to single cells), which can be hierarchical, and let table templates reference these styles. But I'm not sure if such complexity actually worth it. > * Can't get embedded in the document (IAANM) That's not the case. If you create a document with a table, and then look into its XML, you can see the table design exported under <office:styles>. We don't export other unused designs into each document, but that should change once we allow creating custom designs, and mark them as "user defined". That way table designs could be defined inside templates, much like other styles.
(In reply to Maxim Monastirsky from comment #5) > They are named internally, although we don't expose their names in the UI. Fair enough. I was talking about the feature as users experience it - I don't know what happens in the code. > First, there is no support for paragraph styles in Impress right now, not > just in the context of tables. Yeah, that's bug 40871. Until it's resolved, a table style will not have a default paragraph style, which is too bad, but that bug _should_ be resolved and then we're good :-) > Second, even if there were paragraph styles, it's unclear how to integrate > them with table designs. Currently table designs are implemented using the > ODF <table:table-template> feature (much like table styles in Writer), Yeah, I should properly file a bug against Writer then. Styles are powerful and important, and we should use them. > which > is basically a set of cell styles describing different parts of the table > (e.g. the style of the first row, the last row etc.). And cell styles can't > reference paragraph styles (AFAIK), but they can have text and paragraph > properties on their own via <style:text-properties> and > <style:paragraph-properties>. This sounds to me like conceptual duplication. Why should we not drop this mechanism, and use styles consistently? > > * Aren't hierarchical > That's also problematic, as ODF table templates don't seem to support > inheritance. Well, if we get rid of table templates in favor of styles, then the problem goes away. From what you describe, they sound rather redundant. Is there a good reason to have a second styling mechanism of "crippled styles" for tables? > One way around it might be to implement support for cell styles > (that's it, styles applicable to single cells), which can be hierarchical, > and let table templates reference these styles. But I'm not sure if such > complexity actually worth it. 1. I meant hierarchy in the sense of one table style being able to inherit another, parent, table style. 2. That's an even better idea, i.e. a table style has default cell styles for various kinds of cells, and a cell style includes a default paragraph style. > That's not the case. If you create a document with a table, and then look > into its XML, you can see the table design exported under <office:styles>. I see. Well, ok, but - it strengthens my perception of table templates being > We don't export other unused designs into each document, but that should > change once we allow creating custom designs, and mark them as "user > defined". That way table designs could be defined inside templates, much > like other styles. So, again, suggest we not invest work in doing that, but rather fold the table designs mechanism into yet another kind of style, and that way we get all of the functionality + hopefully less code and conceptual clutter.
Hi Eyal. Wouldn't this be a duplicate of bug 149360 ? I also use Impress tables very frequently and the current "Table Design" feature is both unimpressive and not very useful since we cannot add / edit table styles. To help overcome this issue I started working on an extension that helps auto format Impress tables. It's still on alpha stage, but it already works. If you would like to check it out, it's here: https://github.com/rafaelhlima/impress_table_formatter I have been using it to quickly apply styles to tables in Impress. It's also possible to create styles from the selected table. For a complete fix of this issue I think we need to have a better table styles UI in LibreOffice as a whole, integrating what we have for Writer / Impress / Draw. Calc is a totally different problem which requires the implementation of the long awaited bug 66377.
(In reply to Rafael Lima from comment #7) > Hi Eyal. Wouldn't this be a duplicate of bug 149360 ? No... that is about the ability to set alternating row backgrounds of the rows or the table you selected - not to create a style/design which would apply to other tables. > To help overcome this issue I started working on an extension that helps > auto format Impress tables. It's still on alpha stage, but it already works. > If you would like to check it out, it's here: > > https://github.com/rafaelhlima/impress_table_formatter I'll give it a look. > > I have been using it to quickly apply styles to tables in Impress. It's also > possible to create styles from the selected table. > > For a complete fix of this issue I think we need to have a better table > styles UI in LibreOffice as a whole, integrating what we have for Writer / > Impress / Draw. Suppose you live in a wooden shack. It's rickety and it's not insulated... what is the right thing to do about it? Patch it up, add support beams, and cook up some paste to apply between the beams to improve insulation? Or - build a house instead? Same thing for these "table designs". Why try to fix a mechanism that is deficient and redundant to begin with rather than do the straightforward thing and have table styles? I argue we should not invest effort in working on the shack. > Calc is a totally different problem which requires the implementation of the > long awaited bug 66377. This bug is about Impress/Draw only.
(In reply to Eyal Rozenberg from comment #6) > > And cell styles can't > > reference paragraph styles (AFAIK), but they can have text and paragraph > > properties on their own via <style:text-properties> and > > <style:paragraph-properties>. > > This sounds to me like conceptual duplication. Why should we not drop this > mechanism, and use styles consistently? We can't drop this, because it's part of the ODF spec, and used in existing documents and by other ODF clients. It's also exposed to users in cell styles in Calc, so dropping this will require a workflow change in Calc also. At most, we can discuss an _additional_ way to specify text properties, by referencing paragraph styles (which I personally find redundant). > > > * Aren't hierarchical > > That's also problematic, as ODF table templates don't seem to support > > inheritance. > > Well, if we get rid of table templates in favor of styles, then the problem > goes away. From what you describe, they sound rather redundant. They're anything but redundant, as there is no other way in the ODF spec for specifying a table design. There is currently no other "tables styles" that we can implement. (And just to clarify - styles with family "table" describe properties related to a table as a whole, e.g. shadow or page break, and can't express design aspects of a table, like alternate rows. In fact, table template can reference a style from that family in its <table:background> element. So basically table templates are a higher level construct, that reference cell and table styles in order to describe a design of a table.) > Is there a > good reason to have a second styling mechanism of "crippled styles" for > tables? Sorry, but I don't follow. In which way they are "crippled"? Just because they don't support inheritance? This would be only a matter of supporting the <style:parent-style-name> attribute in them. I'm sure we can discuss such proposal.
(In reply to Rafael Lima from comment #7) > Wouldn't this be a duplicate of bug 149360 ? In many ways it is. The Table Properties dialog formats individual cells, and has no idea of the table design as a whole. That's the role of a table design to apply the correct formatting to alternate rows. > To help overcome this issue I started working on an extension that helps > auto format Impress tables. It's still on alpha stage, but it already works. > If you would like to check it out, it's here: > > https://github.com/rafaelhlima/impress_table_formatter FYI, I believe table designs are accessible via the regular UNO style API. I didn't try myself, but it seems plausible that you can actually create real table designs from your code. That way you won't need to manually reapply the formatting each time you add a row etc. > For a complete fix of this issue I think we need to have a better table > styles UI in LibreOffice as a whole, integrating what we have for Writer / > Impress / Draw. Yes. But as a first step we can provide simple context menu actions to format alternate rows, header rows etc, and wire those actions to the existing Table Properties dialog, to specify the format for the given cell role. I actually played with the code a bit, and was able to successfully change parts of a design using the dialog. I'll keep playing with it; maybe it will end up with something useful.
(In reply to Maxim Monastirsky from comment #9) > We can't drop this, because it's part of the ODF spec, and used in existing > documents and by other ODF clients. ... > They're anything but redundant, as there is no other way in the ODF spec for > specifying a table design. > There is currently no other "tables styles" that we can implement. When I suggest supporting proper table styles, I mean in ODF too. Will edit bug fields accordingly. About dropping table designs - I meant "When ODF support full-fledged table styles, drop table-designs/templates it modulo backwards compatibility, where we would import table templates/design from older-ODF-version files as proper table styles". > It's also exposed to users in cell styles in Calc Are you sure? I don't think I see the relation between Calc cell styles and table designs/templates. Could you elaborate on this a little? > (And just to clarify - styles with family "table" describe > properties related to a table as a whole, e.g. shadow or page break, and > can't express design aspects of a table, like alternate rows. > In fact, table > template can reference a style from that family in its <table:background> > element. So basically table templates are a higher level construct, that > reference cell and table styles in order to describe a design of a table.) So, let's expand the semantics of "table styles" as existing in ODF to encompass what "table templates" or "table designs" have now, and get rid of the latter.
(In reply to Eyal Rozenberg from comment #11) > About dropping table designs .... OK, there seems to be some confusion here. My comment was actually about dropping text properties from *cell* styles. In comment 5 I explained that table templates use cell styles to store their formatting, and that cell styles can't reference paragraph styles, but instead have their own text format settings (which is btw the case also with graphic styles). On which you replied that "This sounds to me like conceptual duplication" and that it should be dropped. My understanding was that you propose to drop text properties from cell styles, in favor of using paragraph styles. > > It's also exposed to users in cell styles in Calc > > Are you sure? I don't think I see the relation between Calc cell styles and > table designs/templates. Could you elaborate on this a little? I was talking about *cell* styles, see above. > So, let's expand the semantics of "table styles" as existing in ODF to > encompass what "table templates" or "table designs" have now, and get rid of > the latter. I really don't get what you're trying to achieve with this. The end user doesn't care if the style is stored as <table:table-template> or as <style:style>, as long as it works as expected and keeps the table formatted. What's the point in removing one thing, in order to introduce the exact same thing elsewhere. I also believe you underestimate the amount of work needed for such incompatible changes, and the amount of pain this will cause to people whose documents won't open correctly in different software. Why any missing features can't be just considered as part of the current solution?
(In reply to Maxim Monastirsky from comment #10) > FYI, I believe table designs are accessible via the regular UNO style API. I > didn't try myself, but it seems plausible that you can actually create real > table designs from your code. That way you won't need to manually reapply > the formatting each time you add a row etc. Yes you're right, they're accessible via UNO API. I'll look into it and test if it might work in this extension. If it does, it can be a temporary "fix" while we wait for a definitive implementation in master. (In reply to Maxim Monastirsky from comment #10) > Yes. But as a first step we can provide simple context menu actions to > format alternate rows, header rows etc, and wire those actions to the > existing Table Properties dialog, to specify the format for the given cell > role. I actually played with the code a bit, and was able to successfully > change parts of a design using the dialog. I'll keep playing with it; maybe > it will end up with something useful. This would be a great achievement. Let me know if you need help with testing an eventual patch about this.
Turns out I was mistaken, and table templates actually allow setting a paragraph style (in addition to the paragraph settings specified in the cell style), see: https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#attribute-table_paragraph-style-name
(In reply to Maxim Monastirsky from comment #14) > Turns out I was mistaken, and table templates actually allow setting a > paragraph style (in addition to the paragraph settings specified in the cell > style), see: > https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/ > OpenDocument-v1.3-os-part3-schema.html#attribute-table_paragraph-style-name This is good to know... At least it is supported in ODF. It seems ODF allows to define cell styles and paragraph styles, both at the table level and at the cell level. I just don't know how much is actually implemented in LibreOffice. There's no UI to create paragraph styles in Impress. However, I don't know if we could create styles using the API and assign them to tables.
Just a note that table designs can now be edited and created in Impress and Draw 7.5 / master builds, which you can test here: https://dev-builds.libreoffice.org/daily/master/current.html Relevant commit on gerrit: https://gerrit.libreoffice.org/c/core/+/140943/10
I'll mention that I've filed a "sister" bug about having proper table styles in Writer. Even though I mentioned Writer "Table Styles", they're not proper styles like I asked for here, so my request really regards both modules.
Disagree with characterizing this as an enhancement. The need for styling tables is recognized, and there is some kind of "styles" (table "designs") already implemented. The bug is that these styles are not proper styles, and therefore don't function properly - see comment #4.