TableStyles - more complications

Miklos Vajna vmiklos at
Tue Jun 14 07:04:54 UTC 2016

Hi Jakub,

Let me CC the dev list, others might have an opinion on this.

On Mon, Jun 13, 2016 at 08:53:44PM +0200, Jakub Trzebiatowski < at> wrote:
> Thats because currently SwTableAutoFormat stores more information
> about the formatting that would be saved. When loading that might lead to a
> different looking style.

You could came up with a markup that can save our table autoformat in
ODF without loosing data, it's allowed to put additional attributes on
e.g. <table:table-template> in an extension namespace; i.e. in our case
loext:foo="bar" is still valid ODF.

The same is true for additional elements inside e.g.

> For example: currently It is possible to define a SwTableAutoFormat which
> looks
> like this:
> However, according to OASIS 1.2
> html#__RefHeading__1416308_253892949.
> First-row style is more important (Applied before column styles. So no
> column
> styles could alter first-row style.). Screenshot shows current behaviour,
> column styles being more important than first-row style.

This could be solved by a new optional
loext:first-row-start-column-priority="..." attribute, which would be
"row" by default, but when we export a table autoformat, we would set it
to "column".

> Next problem comes with
> first-row-end-column, first-row-start-column, last-row-end-column,
> last-row-start-column attributes. They do state what style (current row or
> current column) should be applied to top most left, most right, botom most
> left,
> most right cell. In SwTableAutoFormat there is no logic, decisions for that.
> Styles for these cells are sampled and stored.

So do I understand correctly that in ODF e.g. the format of the A1 cell
is always the format of the first row or the start column, but our
autoformat allows an entirely different format as well?

> My thoughts how it could be fixed:
> 1) Modify SwTableAutoFormat to be more like table-template. Add attributes
> for
>    table:first-row-end-column, table:first-row-start-column,
>    table:last-row-end-column, table:last-row-start-column attributes. Which
>    would be determined upon creating a SwTableAutoFormat (and later might be
>    modified when the UI part comes).

This sounds good to me, though you have to be careful about table
autoformat modifications, as the table autoformats are saved in the user
profile in binary form (I think it works by overriding
SfxPoolItem::Store() in the given pool item subclasses).

> 2) Hardcode pre-defined values for these properties. Thats how its done in
>    Impress. (Technically there is no export for these attribues, but the
>    behaviour of style is like the attributes were hardcoded). But that
> wouldn't
>    fix in any way problem with column styles applied before first-row style.

If possible, I would avoid hardcoding anything, that will lead to
trouble with other ODF implementations.

> Anyway I'll have to implement a PropertySet for UNO SwXTextTableStyle
> describing these attributes.

I think it would be good to keep the UNO API close to ODF, so that
xmloff can simply map UNO object properties to XML attributes.

> What do you think about it, how should I proceed?

I think the best would be to try to extend SwTableAutoFormat to be more
temple-template-like, by adding new attributes for your needs. Search
for VersionMap in sw/ and see how the saving and loading of the table
autoformat definitions works; once you understand how you can change the
binary format without breaking existing definitions, it should be
possible to add your new properties there.

Second-best is to extend ODF to suit our needs, though that'll later
need paperwork to turn loext:foo into an official ODF attribute.

In case you don't find the place where this binary load/saving of table
autoformats happen, ask and I'll look up the exact code. :-)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <>

More information about the LibreOffice mailing list