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 <ubap.dev@gmail.com> 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. <table:table-template>.
For example: currently It is possible to define a SwTableAutoFormat which looks like this: http://i.imgur.com/aCopnkQ.png However, according to OASIS 1.2 http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1. 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. :-) Thanks, Miklos
Attachment:
signature.asc
Description: Digital signature
