-- 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. 

[ ... ]

<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>

Reply via email to