Format Comparison Between ODF and MS XML (Groklaw) [LWN.net]

Format Comparison Between ODF and MS XML (Groklaw)

Posted Nov 28, 2005 14:46 UTC (Mon) by drag (subscriber, #31333)
In reply to: Format Comparison Between ODF and MS XML (Groklaw) by danielc
Parent article: Format Comparison Between ODF and MS XML (Groklaw)

That's why most programs 'working formats' are not the same as the file formats.

At least when it comes to graphics. Especially when it comes to graphics.

Take a look at photoshop or gimp. Both programs have their own special 'working' format.. with Photoshop it's the psd format, with Gimp it's XCF.

They do not just save the image files, they save much of the session information. How layers are arranged, how they filter thru each other.. masks, paths, etc etc. These files are huge compared to the final format.

But nobody in their right mind would expect these formats to be portable from one program to another or even portable between program versions beyond simple import-to-latest-version type things.

All image programs are like this.. Blender (3d app), inkscape has it's own 'native' svg format varient. Cinelerra has it's own "native" quicktime format, etc...

Then when your finished with the project you export the image in a format that you'd actually expect other programs to deal with in a rational manner, weither it's OpenEXR, Jpeg, tiff, Png, Cal3d, mpeg4, or whatever makes sense.

In each of these cases the end format is much simplier, much smaller, and much more portable format based around some sort of well established standard that many other programs can use.

When things like Word were created originally the end result was always going to be Paper.. so there wasn't any sort of 'presentation' format.

Eventually we have had standardized 'presentation' format in the form of PDFs.. which originate from postscript format intended for printer proccessing.

However the tradition for 'Wysiwyg' style word proccessors has continued. Your sending the working formats from one person to another and storing the working formats as archival stuff.. which is stupid. It's hard to deal with, it makes it difficult to future proof stuff, and it makes it difficult to keep things backward compatable with older programs, but still be able to utilize newer features of newer programs.

It's very silly. But that's why Microsoft's XML format is so very complicated.

They have the same program with their HTML generator with MS Office.. they shove so much gibberish into the html code that it's pretty much unusable once it's generated. It's nearly impossible to edit, yet they do this so that when you open the file back up in Office that it saves a lot of the information that a word document would save.

Thats why they say they can't use ODF, because ODF can't provide all the functionality that is nessicary for their program's new features..

What is needed for Office things like Koffice, OpenOffice.org, MS Office, etc is to have seperate working 'native' formats and then easily portable formats for archival (because they would be much smaller and retain the important/relevent data) and presentation purposes (because it would work with the widest amount programs and be future proof)

(Log in to post comments)

Format Comparison Between ODF and MS XML (Groklaw)

Posted Nov 28, 2005 16:25 UTC (Mon) by MathFox (guest, #6104) [Link]

Computer typography (Nowadays document processors are actually typesetting programs) is well studied and well understood. One essentially has "text" and typesetting instructions (font use, paragraph/page breaks, reserve space for illustrations, etc.). A computer program then lays out the text on the pages according to the typographic instructions. There haven't been fundamental changes since the early 1980s.
To portably transfer documents between different computers you only need to come to an agreement on how to represent the typesetting instructions and how to add them to the text. SGML and XML offer nice frameworks for creating a vendor independent interchange format. Archivists love to have well documented formats for the documents they archive.
It apparently even is possible to find a group of software vendors that agree that the interchange format "OpenDocument" is good enough to use as _native_ document format. It is a sure sign that office document processing has become mature.

The biggest question I have is why Microsoft refuses to support the OpenDocument format, even with just import and export filters.

Format Comparison Between ODF and MS XML (Groklaw)

Posted Nov 28, 2005 22:36 UTC (Mon) by mikec (guest, #30884) [Link]

> The biggest question I have is why Microsoft refuses to support the OpenDocument format, even with just import and export filters.

Very simple, MS is quite aware of the begrudging upgrade cycle they have repeatedly introduced...

That is, you stick with the version that you have and works until you start having trouble opening and exporting to other people (or it stops working on the OS you get without any choice on the next batch of desktops you buy).

They know they sell crap - Gates has said it himself (para - "we did not set out to build the _best_ operating system, we set out to create a cost-efective solution......"

So, when you sell crap, you have to provide some other incentive to purchase... aggrivation appears to be the weopon of choice...

They know that there are an awful lot of people who hate their products but use them anyway because they have to... If they interoperate too well, even with prior versions of their own software, noone uses theirs or upgrades.

Format Comparison Between ODF and MS XML (Groklaw)

Posted Nov 29, 2005 2:39 UTC (Tue) by Baylink (subscriber, #755) [Link]

> (Nowadays document processors are actually typesetting programs)

Good.

I can still make a living.

:-)

Format Comparison Between ODF and MS XML (Groklaw)

Posted Nov 28, 2005 17:57 UTC (Mon) by iabervon (subscriber, #722) [Link]

I don't generally think of layers and such as session information; I tend to think of them are parts of a richer image format, sort of like how recent PDF versions allow for a table of contents that appears outside of the displayed pages when shown on a computer. There's no reason this stuff couldn't be part of a standard image format. (For that matter, SVG supports that kind of stuff, so Gimp could use an SVG file containing bitmaps and no other drawing operations, which would be a bit silly, but would be portable).

Format Comparison Between ODF and MS XML (Groklaw)

Posted Nov 28, 2005 18:36 UTC (Mon) by Blaisorblade (guest, #25465) [Link]

> However the tradition for 'Wysiwyg' style word proccessors has continued. Your sending the working formats from one person to another and storing the working formats as archival stuff.. which is stupid.

It isn't so stupid if you remember that one big reason people use a computer rather than a typewriter is that you can change what you wrote time ago.

Sure, for archives it can make sense to have a "presentation format". But only when "archive" means "external archive", i.e. an archive of published papers from different people. I would never save anything in PDF, I'd only "export" in that format. Better yet, I would almost never read the content in PDF format (except maybe if acroread starts faster than *Office*, but that's a different thing).

While I would never open an image in .xcf rather than .jpeg.

Format Comparison Between ODF and MS XML (Groklaw)

Posted Nov 29, 2005 2:39 UTC (Tue) by Baylink (subscriber, #755) [Link]

> What is needed for Office things like Koffice, OpenOffice.org, MS Office, etc is to have seperate working 'native' formats and then easily portable formats for archival (because they would be much smaller and retain the important/relevent data) and presentation purposes (because it would work with the widest amount programs and be future proof)

Ah... that's exactly what They *want* you to think (much less say). :-)

Look up "second-class citizen".

Your *native* file format needs to be sufficiently capable to store everything you need. And it shouldn't be that hard. Rough consensus, and working code, folks.