corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Franz de Copenhague <>
Subject RE: ODF mapping (was RE: Git revert difficulty)
Date Wed, 29 Apr 2015 19:17:28 GMT

> From:
> Date: Wed, 29 Apr 2015 20:52:00 +0200
> To:
> Subject: Re: ODF mapping (was RE: Git revert difficulty)
> Am 29.04.2015 um 18:53 schrieb Dennis E. Hamilton:
>> -- commenting inline to --
>> From: Peter Kelly []
>> Sent: Sunday, April 26, 2015 21:56
>> To:
>> Subject: Re: Git revert difficulty
>>> On 27 Apr 2015, at 11:27 am, Franz de Copenhague <> wrote:
>>> I have a question regarding to the ODFTextConverter to HTML. ODF only use span
tags and style names to define text content and formats like bold, italic, strike, etc as
opposite to OOXML that uses run texts tags with separate rPr tags for inline formatting like
bold, italic, strike, etc. For me makes sense how DOCXConverter converts text formatting inline
style like style="font-weight: bold" or style="font-style: italic".
>>> So, considering that ODF only uses style names. What is your text formatting
approach for HTML generation from ODF documents?
>> Excellent question :)
>> [ ... ]
>> I actually think this is a poor design choice in the spec, because it causes confusion.
As far as I’m concerned, “automatic” styles aren’t styles at all, because the whole
point of styles is that they’re explicitly defined by the user (or provided as defaults
by an application), and are distinct from direct formatting. However, this is the terminology
used in the spec.
>> When translating to HTML, I think it would be best to translate all automatic styles
to direct formatting.
> The naming is indeed indeed non intuitive. The automatic styles are
> being created automatically, when a user is applying hard formatting.
> For instance, selects some character an applies bold format.
> Although I dislike the concept in the beginning as Dennis does, the
> design makes a lot of sense for large documents, where often the same
> combination of hard styles are being applied. Especially for
> spreadsheets it made a lot of sense. In the browser office for
> Open-XChange we improved performance for the transfer of change
> operation by referring to automatic style sets.
> I would like to point three further concepts of styles, which are not
> intuitive.
> The style from a table cell might have three different background
> colours (see
> ).
> As a table cell style can hold properties for the cell, paragraph and text.
> One could explain it as the cell background color, the next default
> background color of the paragraph (within a cell) and finally the one
> background-color from the text style (within the paragraph).
> The second interesting example of automatic styles. If there is a
> paragraph with the text "abc", but only the paragraph has an automatic
> style having as single property a text property style
> <>
> with a background color.
> The user is not selecting the middle character "b" and is removing all
> format (or reset to default style) from the b. Only "a" and "c" have a
> remaining format.
> Guess what happens when the document is being saved.
> The automatic paragraph style has been removed and there are two
> text:span around "a" and "c" referring to the same automatic text style.
> Finally one of my favorite style examples is the cross paragraph text
> selection and deletion (of text and inbetween paragraph borders) by the
> user.
> Assume the first paragraph is a heading with red background part of the
> template style and the second an ordinary paragraph with green automatic
> background paragraph style.
> The result is: The first paragraph style win, but any text styles from
> the latter are being applied as span with automatic style to the none
> deleted part of the second paragraph.
> Just check it out if you have any doubts ;)
>> [ ... ]
>> <orcmid>
>> Yes, the handling of the automatic styles in OO.o-lineage software is a problem because
users can't inspect for and resolve problems with things like format changes that simply won't
go away, since they can't find the span and changing the paragraph-level style has no effect!
>> This is an usability problem, and it has not been dealt with properly in the major
ODF implementations.
>> Concerning "flattening" of the style hierarchy and inheritance down to what the character
stream needs, that is very appropriate. It is also important for comparing documents (but
not so great as an update to an existing document).
>> Note however that Microsoft Office ODF support is via translation to and from the
Office internal model so this is demonstrably not insurmountable.
>> </orcmid>
> Dennis, I do not fully understand the problem you are explaining in the
> previous paragraph.
> Is it that we are still using the ancient hard formatting / template
> approach and not having embraced CI/CD into the formats?
> Greetings,
> Svante

Hi Svante,

Thank you for your feedback. 

Will be very helpful if you would create a couple of odt examples with the use cases that
you describe at sample/documents/odf folder.

View raw message