---------------------------------------- > From: [email protected] > Date: Wed, 29 Apr 2015 20:52:00 +0200 > To: [email protected] > 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 [mailto:[email protected]] >> Sent: Sunday, April 26, 2015 21:56 >> To: [email protected] >> Subject: Re: Git revert difficulty >> >>> On 27 Apr 2015, at 11:27 am, Franz de Copenhague <[email protected]> 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 > http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#property-fo_background-color > ). > 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 > <http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-style_text-properties> > 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. -Franz
