[odf-discuss] A story of TIFF

[Alex Hudson]

marbux wrote:
> On 2/3/07, Daniel Carrera <daniel.carrera at zmsl.com> wrote:
>> Are you saying that the da Vinci plugin does *not* insert unknown binary
>> blogs ("dark objects") into ODF files which cannot be understood by
>> other applications?
>>
>
> Darn few. Most have been cracked.

If that's true, I will be very happy with the Foundation plugin. But I 
don't see how squares with the 65% figure proffered earlier.

Are you saying that if I save a document in Word with Da Vinci, aside 
from a small number of features, the vast majority of it is ODF, not 
foreign data? Say, 90% or something?

> For starters, the Ecma 376 TC's work plan has changed from ensuring
> compatibility with the legacy binary formats to ensuring compatibility
> with MOOXML.

The TC45 charter _never_ specified compatibility with the binary formats 
- where did you get this from?

> That is tantamount to an announcement that EOOXML is only
> a subset of MOOXML. Second, the allowance for wrapping dark objects in
> EOOXML tags testifies that MOOXML is not entirely XML but also
> includes proprietary binary blobs.

Actually, OXML is unlike ODF in that it doesn't allow foreign data 
within the file - it's not allowed in the specification.

Which proprietary binary blobs are you talking about?

> Indeed, the packaging of the new Excel proprietary binary Infoset
> format in MOOXML Zip files is pretty compelling testimony that the
> approach you suggest was already largely obsolete before the public
> release of Office 2007. Want to take any bets on whether the backports
> of the Office 2007 MOOXML native file support to earlier versions of
> Office also support the proprietary Excel binary Infoset format?

It does include it, IIRC.

I'm not sure that's terribly telling though - the new binary format 
isn't the default, and I really don't think many people will switch to 
it - it doesn't give you anything extra over .xlsx. I suspect the only 
reason they've done it is because .xlsx simply isn't fast enough for 
some users, which would be sad indeed.

> A blob is a blob is a blob, whether wrapped with MOOXML tags or ODF
> tags. But targeting the in-memory binary representations and their
> dumps to file is in my mind the only practical approach to the
> problem. I still haven't heard any reason to believe otherwise.

If you work on the assumption that the OXML file is equivalent to the 
RTF file (I'm not sure it is - I don't really see how converting to RTF 
can retain all the information - but I'm willing to assume for the sake 
of this exercise that they are equivalent), then it doesn't really 
matter where the binary comes from in terms of fidelity. So long as the 
round-trip file is more or less identical, you don't care what the 
intermediate format is.

But, personally, I'm not particularly interested in the "how can we 
replace OXML?!" argument (and, actually, rather than prove that OXML is 
unnecessary, extending ODF with proprietary information seems to prove 
rather the opposite - that ODF is, alone, insufficient). Peter made an 
excellent point: the .doc format is also full fidelity, and OOo users 
can read that with 85% fidelity. If the ODF output from da Vinci is only 
65% fidelity, why on earth would we want to use that?

Cheers,

Alex.