The cost of ODF and OOXML | Hacker News Reader

The cost of ODF and OOXML

people.skolelinux.org

70 pointsbiehl19 comments

To avoid the pitfalls mentioned in the article, most places I know have stopped sending MS Word or ODFs but instead use PDFs.

Converting documents from Word to ODF or vice-versa is full of issues as no conversion here is 1-to-1 (same applies for conversions of e.g. old MS Word formats to newer ones - don't know for various ODF implementations).

If you don't collaborate on the document writing, IMHO pdf is the best representation for both of the formats and all those offices that require ODFs instead of MS Word do accept pdf files as well.

Creating a pdf from a MS Word / ODF file is a matter of seconds to 1-2 minutes for very large documents.

This might be obvious, but PDF isn't usually reflowable (and if it is, it's not very easy to do so), which makes for a painful reading experience on a smallish widescreen monitor, and isn't editable easily.

I usually just decide between plain-text, HTML, Google Docs and LaTeX/PDF, going up the ladder as the complexity of the document requires, or if it needs to be editable.

I hate it when I'm e-mailed a Word document that could easily have been plain text, in which case it would be searchable and more easily found when looking through e-mails manually.

I had a bad time working with other people's word docs in Open Office, but I found Google Docs does an excellent job in converting them to a usable format.

In the end though I too use pdf and make the other people do the hard work for not using Open Office on their end :P

I could save the Google doc back to Word format, but I have no idea how different it will act and look.

When you do not have any facts to back-up a preposterous claim, you just make up stuff as you go along. This is (somewhat predictable)from Microsoft after their initial efforts to break the standard.

Glyn Moody just makes up facts to fit his own agenda and then when you point them out to him he just says you're missing the overall point. He creates more FUD than the organisations he complains about.

So this is what MS presented to the UK government and the UK government didn't hear a response from an open source representative?

I have always wondered why Open Document standard would not be based around HTML instead of inventing new XML schema? Can someone who has more insight on ODF/OOXML tell me why HTML is not suitable for office document format?

Open Office has a far richer format than HTML allows (e.g. "this is a footnote", "this footer on every page, 2cm from the bottom", ...). Of course, one could extend HTML to handle all that, but just starting with XML is cleaner.

HTML made for continuous display and re-flowing for different sizes.

ODF is for publishing, i.e. where you can have separate pages, with footers, margins, absolute position inside page (versus whole document), corrections tracking, authorship, figures.

HTML _can_ give you close result, but this is not HTML domain, hence separate standard.

Really, what we need to adopt en-mass is Tex.

All sorts of things Tex doesn't handle.

Embedded editable files, for instance.

Or markup for tracking changes.

Tex might make a good starting point for building a system that _did_ do all of that, but nobody seems to be working on that.

> Or markup for tracking changes.

I've often wondered why Microsoft chose to embed a weak implementation of version control into their mutable document format instead of doing something like passing around a signed chain of immutable documents.

The people that made change tracking probably wanted the feature to work and be usable, rather than create another crypto product and have no one figure it out.

Also, if you don't trust the other parties, you can use the compare feature an get a diff of the documents. Keeping your own copy is a easy, simple, way to get a correct view of changes to a document.

Right, so, "signed" in the same sense that a chain of git commits are signed. In other words, resiliency not trust, and full history instead of whatever Track Changes provides.

Sure, and Microsoft provides document signing/rights management, as well, if you can get the supporting infrastructure. Office apps also have built in change revision history. Track Changes is sorta orthogonal here, I think.

Because I don't want a list of separate changes - I want a series of notes _inside_ the document, colour coded for the editors, marked as accepted/rejected, etc.

You can do a mediocre job of inferring the latter from the former, but for 100% support you need to actually put the notes into the file itself.

That seems like a bad idea. TeX doesn't allow separation between markup and presentation very well. Something like DocBook[1] with a presentation engine like XSLT might be better, if it wasn't for the verbosity of the XML source.

[1] http://www.docbook.org/whatis

+1.

Any representation that makes people think "this is a paragraph", "this is a title", "this is a list" and then apply styles to each is an improvement over the current "lets vomit text on a page, then tweak individual sections independently" method endorsed by most word processors.

Tools that do this like (Pandoc being the one I like) do a great job of getting people to think of documents as text that gets styled later.

I won't even acknowledge a document unless it's hand-written postscript.

Reply on news.ycombinator.com