Slashdot Mirror
Opera CTO Hits Back at Microsoft's Standards Push
Michael writes "Opera CTO Håkon Wium Lie hit back today at Microsoft's push to fast track Office Open XML into an ISO standard, in a
blistering article on CNET. He also took a swipe at Open Document Format: 'I'm no fan of either specification. Both are basically memory dumps with angle brackets around them. If forced to choose one, I'd pick the 700-page specification (ODF) over the 6,000-page specification (OOXML). But I think there is a better way.' The better way being the existing universally understood standards of HTML and CSS. Putting this to the test, Håkon has published a book using HTML and CSS."
Yeah, but that "book" is fsck'n ugly. It doesn't even compare to a professionally typeset book, or something produced in LaTeX. I hope that isn't the "solution" to this standards "problem". Let's face it, the average Joe is going to use whatever Microsoft pushes at them. Case closed.
"Both are basically memory dumps with angle brackets around them."
Table-ized A.I.
Having a word processor act more like a web browser would be awesome. Ever since I started using word processors (which for me was a long time after I started using web browsers), i've always thought, why doesn't updating this style make all text with that style update? Why do I always have to change the same thing over and over again?
While turning word processors into web browsers would be stupid, things like CSS would be awesome to have in word processors.
While I do agree that the ISO doesn't need more than one standard for printable documents, I don't think that Håkon Wium Lie is on the right track with HTML/CSS for print.
Sure, it works, with enough tweaking, and CSS3, and a $350 download of a product to turn HTML/CSS3 into a PDF. This is better how? What about LyX, LaTeX, or even OpenOffice if you are just going to convert to PDF?
The whole HTML/CSS-to-print thing shoots the real argument in the foot.
Death looks every man in the face. All any man can do is look back and smile. - Marcus Aurelius
Hmm... both of these standards suck. I know what, we need another choice!
Somehow I don't think that's going to fix the problem. Oh, and pointing out that the Microsoft letter doesn't validate. Isn't that a little petty?
Only problem is, the Oasis page itself doesn't validate. However, it seems Wikipedia does...
But if the Oasis pages did validate, the basic argument goes like this: "How can they claim to care about standards if they can't even bother to support that most universal standard of standards, HTML?" And indeed, I could still make that argument -- just look at the sad, sad state of affairs that is Internet Explorer's CSS [mis]handling.
Don't thank God, thank a doctor!
Keep in mind this was published by a bigwig at Opera. The Opera web browser tends to stay way ahead of the other browsers in terms of standards compliance. This includes things like the ability to use the page elements to force page breaking and to help create layouts useful for things like books, reports, etc. Opera is a great engine for rendering HTML & CSS, I personally just can't get past the UI.
Been a long time since I typeset anything, but I used Adobe Pagemaker when I typeset a couple of college magazines in the mid-90s and FrameMaker when I was maintaining courseware in the late '90s for Nortel.
HTML + CSS vs. Word vs. OO.o seems to me to be an argument related to formatting documents, not a "book". It's not that you couldn't do it, but I'd consider using Quark or InDesign (what seems to be Adobe's successor to PageMaker) or even Tex and its variants (haven't used any Tex-based stuff, but heard wonderful things) for typesetting.
Arguments about standards aside, proof of concepts aside, I'd think that the real issue when it comes to any job is using the best tool for it. It's not a question of whether you can use these tools to typeset a book, but if you should.
The point of the proof of concept is to prove that the system is flexible or capable enough to go beyond its original intended use. I get that. But proving a chainsaw can be used to spread butter, doesn't mean it's inherently superior to a coping saw.
- Greg
Start a happiness pandemic
HTML sucks for books. The reason is simple. HTML was designed for web pages. HTML does a fairly good job of covering the things you need when you create a web page (although, why is there no , and a bunch of other stuff that need to be fudged by using elements that don't really fit). In HTML there is no , no , no , no . Also, with HTML, one file == one document. If you're writing a book, it would be nice to be able to for example have one file per chapter and include them all in a master file (assuming you're writing your HTML by hand, of course). That's not possible with HTML.
It would be possible to extend HTML to include such features or to create a HTML-like format that is more suitable for books (cf docbook). I agree that "word processors" today are a horrible mess, and we definately need something like a modernised LaTeX, but HTML isn't it.
Please alter my pants as fashion dictates.
So say you can absorb 30 pages a day, thats 200 days to read the spec.
Oh and the spec is defined to fit an existing product, so that product fits the spec and there are unspecified patent hurdles attached to it. Wow which idiot would fall for that one.
700 pages is not understandable by anyone but authors. "C programming language" book is 1/3 in size, have endured for 20 years and was instrumental in solving many more problems than word processing. Also, creating an ODF document is a minor function in most applications and is not worth the effort to understand such a huge standard. Proponents of both standards should come up with a modular design instead. At the base level, stick with basic HTML - bold and italic tags, fonts and sizes, paragraph breaks. Define many extensions that can be implemented independently or in any combination, in a manner convenient for both computers and, in a pinch, humans. Opera guy is biased as well - while basic HTML is great at its limited function, CSS is not very readable by humans. Nor does it solve pagination, collaborative editing, resolution independence, color profiles for printing...
My speculation would be that no-one wants to sit and read a 6,000 page specification. 700 pages is far more palletable.
It's a crap way of judging the relative merits of specifications, but human nature will out.
Yeah, I had a sig once; I got bored of it.
CSS would be a great standard, but it leaves too much to the people who implement it; is this a block type or inline? What should the default for this nonstandard tag be? etc, etc.
If they spelled everything out without any ambiguity it would make a better standard.. but then it would be another "600 page long" standard with is what he seems to be against in the first place.
// MD_Update(&m,buf,j);
Those who don't understand LaTeX are doomed to reinvent it... poorly.
This sig is intentionally left blank
Using a word processor to write a book is like using stone tablets and and abacus for spreadsheets. You really ought to look at markup-based typesetters like LaTeX or DocBook or software specifically designed for book production.
Well, the basic parser isn't really an issue. I haven't investigated either standard in any detail, but assuming they're actual XML, or even reasonably close, there are a million libraries that can handle the parsing. Expat, Xerces, Arabica, the Qt XML parser, and the Java library XML parser come to mind.
The majority of the work is interpretting the tags and actually laying out the document in a standardized way. I can already load a Word *.doc file into OpenOffice and have it look relatively close to how it looks in Word. The reason it only looks "close" is that the Word .doc format isn't documented, so developers for competing products have to make some assumptions and ignore some stuff they can't figure out. Having a standard is supposed to rectify that.
Ideally, with a standardized format, a document would look identical in any word processor that supported all the features used by the document. That's the whole point.
Off-topic: I absolutely hate when people make statements like "I'm no programmer, but I could write that software in very little time." Contrary to popular belief, programming isn't trivial. Sure, you may be able to write the parser in very little time, but would other people want to maintain your code? Would people reading your code even be able to tell what you're doing? Would it have fewer bugs than code written by actual programmers? Would it be fast enough? Would you know what to do if it wasn't? Sorry, it's just a pet peeve.
Maybe not