Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
odfdom-0.8.5
-
None
-
None
-
Operating System: All
Platform: All
-
207
Description
Discussion on default values
(see http://odftoolkit.org/projects/odfdom/lists/dev/archive/2010-06/message/24 and following)
We started a discussion based on the mail thread on default styles from the reference above.
In the agenda ODFDOM development meeting we noted the following:
Our shared vision is to prototype a new design concept to our new ODF Document API classes (Table & Slide), so others might follow.
The idea: Instead of using currently only style constants in our convenient Document API classes, we like to support customizable default values early in the design.
To remember: There are different kind of default values. Those specified by ODF 1.2, eg. the attribute value for column repeated is by default 1.
We are interested in default style values. And only those, which are saved in the XML and not being applied by default by the application (E.g. the horizontal alignment of cell content dependent on the datatype (e.g. number in a spreadsheet is right aligned, but the alignment is not written in the XML or a content with number type, which format would change upon the given Locale in the UI. Rob gave the example of the number PI, which would be viewed in the US as 3.14159 in DE as 3,14159).
In our case we need default style values for new created stylable elements, e.g. table.
Our example was the creation of a new table in a text document is done by default with border style and in a spreadsheet without border.
Two further requirements we gave from the beginning:
1) The design of default style handling should be able to be changed during runtime and
2) work on a server, where for instance IBM and ORACLE employees use the corporate colors for their documents.
We had a little brain storm over that topic and realized it might be nice to have some XML configuration file, which might be even a styles.xml file, similar to the default stylesheet of a browser.
Taking this thought on, we might even want to embrace not only the styles.xml, but a complete document to provide for instance default metadata.
We can say, that ODFDOM supports default styles already by using the ODF files from the JAR as templates.
A first step to customize default handling would be to allow in ODFDOM to change the default template to be loaded.
Simply offering a static loadTemplate method with the InputStream of the template would help.
Next step is how default handling should work in ODFDOM.
After the meeting I did some further testing with OOO and discussed the topic with my colleagues Frank Meies and Steffen Grund.
First thing to notice when testing table default style handling in the OOO Writer. It uses no document table styles, only automatic table styles (implementation detail).
Second interesting thing is that if a new table is being created in an existing document, e.g. the ODF 1.2 specification.
Not only the table will be created with border, but other styles will be applied as well.
It became obvious that these style formats are not so much influenced by <style:default-style>, but depend on the style properties of certain named styles.
For instance there is a Paragraph style, called "Table_20_Contents", which is applied to all Paragraphs of a table cell.
Giving this Style a background color let a new table be created with background color.
Therefore a mapping between style names and ODF elements exist and allow additional usability - although not standardized yet, we might work out the details (explicit default values, mappings per application) and follow this approach.
An ODF template could then use these style IDs as indicator for default styles to be set on certain stylable elements.
The mapping might look like the following:
"Table_20_Contents" => "table:table-cell/text
"
If default styles are being provided by a template and the styles within being mapped to new stylable elements via a fixed mapping table (orientated on OOO) I blieve all desired requirements can be covered.
An additional functionality:
Given the above prerequisites:
It might even be possible to load existing documents with different styles, providing in addition to the source document a template.
Attachments
Issue Links
- depends upon
-
-
- Reopened
-