[odf-discuss] A story of TIFF

[Peter Vandenabeele]

On 2/5/07, Alex Hudson <alex at stratagia.co.uk> wrote:
> If every application wrote ODF like that, interoperability would be
> limited to the proper subset of all ODF subsets: the Least Common
> Denominator. The danger of this is that if the LCD is not a large enough
> set (it could, in fact, be empty) then ODF becomes *useless* as an
> interoperable format.

I see the problem differently. Even if "pure ODF" and "ODFX" have
the full "pure ODF" as Common Denominator, there is still the
most difficult user problem that we need to be sure the sender
and recipient are looking at the same document.

The use case:

  "if I, as user A, send an "ODF" document to recipient B, how do I
   know for sure, and how does B know for sure that we are effectively
   looking at the _same_ thing. Obviously A and B could be using
   different application software, since we don't want to mandate to
   any user which _software_ to use."

We have considered forcing user A to accompagny the "ODF"
document with a PDF export, so that user B can check for himself,
but that is rather clumsy ....

At least one workable solution would be that if A and B only use
"pure ODF", we can assume that applications that implement the
ODF spec decently (OO.o, Koffice, MS Office + plug-in, ...) will
render the document in nearly identical shape and hopefully
exactly identical content. Maye to allow reliable MS Office
processing of ODF documents, we need to use the subset.

That is the main user problem I see with incompatible subclasses
of the "ODF" formats. Even if their Common Denominator is 99%
overlapping, there is a small chance that user A sends a feature
that is in the 1% non-overlapping and A and B can never be sure
they are looking at the same document.

If we can use the .odt extension for ODF (without "black matter")
and use a different extension for ODFX (with "black matter"), at least
users can be confident that the recipient of their ODF document will
see the same.

And yes, this will require the sender of the document, when sending
from e.g. MS Office or other applications that are not natively supporting
the ODF format, to:

* save the document in .odt/.odp/.ods
* read back ("Open") the document from the saved .odt/.odp/.ods
* check if any important elements of his document where lost

I would hope that in this scenario, the document is fully in the Common
Denominator between "ODF" and "capabilities of MS Office" ? It is
created by MS Office, so it does not contain features MS Office does
not understand. And it is saved in "pure ODF", so it does not
contain features that are not in ODF..

The price to pay in this self check (and thus de facto manual conversion
to a fully specified "pure ODF") is lower than the price of uncertainty
over what the recipient will actually get to see. And eventually, MS
Office will have to support native "ODF" to avoid this nuisance for
it's users.

If any plug-in can solve the following problem, very interested. That is:
  "changing the behaviour of MS Office so that it operates in ODF
   compatible mode and it can only generate features that can be
   represented faithfully in ODF."

By coincidence, exactly today, I am being called from a multitude of
user cases (4 at least) in the Belgian context that will decide on how
to approach ODF migration in the coming days ... most users just
simply believe that installing OO.o is the obvious and only solution.

Well, I explain them that MS Office can also do this, when a plug-in
is installed, but that they need to be careful about the interoperability
of documents with OO.o etc. I don't get the question for fidelity with
old MS formats, since for all these users, these are either new
documents that they will start writing (based on templates) or new
documents they will start receiving (and they need to be able to
process) them. The full and guaranteed interoperability between
different users (with unpredictable applications) is what they ask,
as I understand it.

This afternoon, I have the pleasure of migrating an old project
management template (actually designed on Word for Macintosh)
to ODF format. Curious how that will turn out. Beside using OO.o
2.1 , I will also try to import the result into Office 2003 with the
tools that I have available. Than I can advise if it makes sense
to try to use the template in MS Office too. If all else fails, well,
OO.o will be the fallback, until better plug-in support is available.
Too bad for MS Office ...

To be continued,

Peter