[
https://issues.apache.org/jira/browse/ODFTOOLKIT-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hopf updated ODFTOOLKIT-166:
------------------------------------
Fix Version/s: (was: odfdom-1.0)
> Support of Customized Styles on ODF Component Creation & Style Adaption upon
> Component Insertion
> ------------------------------------------------------------------------------------------------
>
> Key: ODFTOOLKIT-166
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-166
> Project: ODF Toolkit
> Issue Type: Bug
> Components: java
> Affects Versions: odfdom-0.8.6
> Environment: Operating System: All
> Platform: All
> Reporter: Svante Schubert
> Priority: Minor
>
> Currently the styles on ODF components (e.g. table, row, column, cell) are
> hard coded into the document API.
> Recently we received the following customer request:
> A customer desired to have different styles on tables and his first task
> after table creation was the removal of all styles.
> Therefore he desired to have the opportunity to neglect the creation of any
> styles.
> Instead of following his implementation request and polluting our API with a
> boolean flag for optional style creation upon table/row/column/cell (his
> explicit desire), we might want to head into the similar direction as we did
> with customized localization.
> Instead of providing special configuration XML files with styles, which have
> to be maintained, the efficient way to take the desired style settings
> directly from a template.
> The missing piece in ODF is the existence of default styles for certain
> components. While OpenOffice got a set of default named styles for the most
> used components (heading, paragraph, footnote, etc.) the
> naming/identification of those styles is implementation dependent.
> If a default style mechanism is being specified in ODF to rely on a default
> fall-back style for every styleable ODF component, we all over sudden receive
> an immense interoperability of ODF documents:
> For instance, a new paragraph created in ODFDOM would by default apply this
> default style (identified either by name - our first quick solution or later
> as specified in ODF perhaps via an XML annotation like an attribute).
> The exact style properties would be received by the document/template being
> opened, giving the customer opportunity to add his/her cooperate identity.
> The wonderful side-effect aside of the ability to customize default styles on
> all styleable components in an ODF application is whenever a ODF component is
> being copied, at least there is a fall back default style, which might be
> altered by the customer. A green table added to a document with red tables,
> would not be green any longer, but would alter its color schema.
> Which is the default customer expectation, copying for instance slides from
> one presentation to another. Similar behavior on documents. The overall
> target document look & feel should not be disturbed by the look & feel from
> the source document.
> The current state in ODFDOM is that those OOO default styles have been
> already being added to our ODF default templates within our odfdom.jar - used
> as default styles.xml whenever a document is being created from the scratch.
> Our next step is to take switch in ODFDOM from the hardwired of style
> properties to the hard wiring of style names (those used by OpenOffice) and
> document the behavior in our API.
> Note: AFAIK the OOO Writer/Calc do not support common styles in tables.
> Nevertheless we should provide common styles in our templates, giving the
> customer the opportunity to exchange freely the styles.xml.
> Internally, we might try to inherit an automatic style from those and/or do a
> transformation from automatic styles to our table common style for tables as
> we have to deal with reality - but as much as possible behind the scenes,
> invisible for our customer.
> From our first prototyping results we should than come up with a proposal to
> the ODF TC.
> Regards,
> Svante
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
