[odf-discuss] plug-in and ODF 1.2 (was: Miguel on OXML)
soren.roug at eea.europa.eu
Sat Feb 3 03:15:08 EST 2007
On Saturday 03 February 2007 01:50, Peter Vandenabeele wrote:
> On 2/2/07, Thomas Zander <zander at kde.org> wrote:
> > The roundtrip is what is important here. And it is the same as when a
> > KOffice application saves out a document with information that OpenOffice
> > does not parse.
> Could you give an example of this for my understanding ? What would be
> the "specification" of such information [that OO.o does not parse]? Is it
> e.g. the KOffice source code and/or another form of specification ?
Yes, Koffice sometimes put a koffice:frame-behavior-on-new-page="followup"
attribute on a <style:graphic-properties> element. Worse, <draw:page> can
contain a koffice:name attribute.
OpenOffice.org has a few tricks of its own: I can put an attribute called
style:writing-mode in element <style:table-cell-properties>. That is not
legal, it has to go in <style:table-properties>. Attribute style:editable in
element <style:section-properties> and attribute xlink:role in element
<meta:template> are also OpenOffice.org extensions.
According to section 1.5 in the ODF specification, The various
<style:*-properties> elements may have arbitrary attributes attached and may
have arbitrary element content, so most of the examples above are allowed,
but it doesn't change the fact that you will have slightly different look in
different software applications.
> > Saving the information out to the file, even if the app did not _use_
> > that information is essential to a good roundtripping experience.
> But then every user gets into the ethernal question of "how can I be sure
> that I have a high fidelity view of the document. Maybe there are
> unprocessed elements that I do not see and another reader of the document
> did see".
> I have the impression that "enterprise" level applications should
> stick to standard
> ODF to be fully interoperable and should fiercly warn the user if they
> receive documents that have extensions that they cannot parse.
> > In fact, the current ODF spec already allows you to do this. Its all in
> > the implementation. So OOo fails to be nice in that respect.
> Could you elaborate on this please.
More information about the odf-discuss