incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florian Hopf (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ODFTOOLKIT-166) Support of Customized Styles on ODF Component Creation & Style Adaption upon Component Insertion
Date Wed, 19 Dec 2012 05:35:14 GMT

     [ 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

Mime
View raw message