Beta
×

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Opera CTO Hits Back at Microsoft's Standards Push

Zonk posted more than 7 years ago | from the going-to-make-the-nighly-news dept.

246

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."

cancel ×

Yes. Well... (2, Funny)

Frosty Piss (770223) | more than 7 years ago | (#18132136)

Opera CTO Håkon Wium Lie sort of "bitch slapped" a picture of Bill Gates and splashed some white wine around...

Ok... Cheese, anyone?

fsck'n ugly (5, Insightful)

Anonymous Coward | more than 7 years ago | (#18132152)

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.

Re:fsck'n ugly (5, Insightful)

AKAImBatman (238306) | more than 7 years ago | (#18132278)

Yeah, but that "book" is fsck'n ugly. It doesn't even compare to a professionally typeset book, or something produced in LaTeX.

You don't typeset with Microsoft Word, either. Which makes the entire argument specious. Word processors like MS Word and OOo Writer are for creating common documents like letters, memos, and maybe the occasional flyer. Neither one is particularly good at anything even close to professional publishing work. Even the book authors just use Word (or surprisingly, OOo Writer!) to do the text content. That text is then exported to a more sophisticated program, where the actual typesetting and page layouts are done.

I think this fellow's point is that HTML/CSS formats can store any information that a Word Processor might need to store, with no need to invoke new technologies. To a certain extent, he may be correct. Unfortunately, HTML/CSS may make a good intermediary format, but it is not particularly good from a performance or usability perspective. Then again, XML formats in general are fairly poor choices for the same reason.

I think if we want to break this conundrum, the industry is going to have to learn how to keep local data stores that are of high performance, while exporting intermediary formats when emailing or uploading to external computers. The only problem is finding a way of doing this so that it's completely transparent to users. The mythical "mom" doesn't want to worry about emailing a document in the right format, or having the right program to read the attachment she received. She just wants it to do what she tells it, with no bloody prompting with questions she has no answers for.

Re:fsck'n ugly (3, Informative)

Anonymous Coward | more than 7 years ago | (#18132414)

You're entirely right. Word/OOo aren't used for pro typesetting and page layout. But if we exclude that, then we still have many, many other formats, like RTF too (or why not even BBCode while we're at it?). Yes it's quite ugly, but I don't see (x)html + css as being the answer either:

-too many versions of html (4, and perhaps 5 soon) and xhtml (1.0, 1.1, strict, transitional, etc)
-different versions of CSS, browser support for it varies quite a bit (and is pretty much non-existent for CSS3)
-too many rendering engines, css hacks required so the content displays the same in most of them, etc
-html/css sucks at MANY things - how about a self-updating TOC? (don't even try to say some javascript parsing the DOM for header tags with certain IDs to generate it dynamically!) Hell, how can you even tell the page numbers in a html "document" anyways?
-while word/OOo formats aren't real typesetting (like InDesign CS2 would do), at least they have half-way decent typography. Yeah, no fancy glyphs or super precise kerning, but it's still usable. On the web there's only a handful of "just OK" fonts one can use (unless everything is rendered server-side as images).
-if people use html/css, there would basically be no standards *at all* or anything even resembling it (much like anything we see on the web). And I'm not sure the W3C is really going to help much here... Not that their recommendations are implemented very quickly (so many nice standards, but with basically no support e.g. xforms). And I'm not sure they're really being too helpful anymore either - more like slow and misguided IMO.

At least with the new formats you're starting fresh, with the chance to have most features (like a Table of Content), and have them implemented properly. Mind you I'm not saying the new word/OOo XML formats are perfect - nor even the answer to the problem in the first place...

And yeah, it's not like (x)html has angle brackets either ;)

Looks to me like Opera has only one tool: a hammer (or is that a web browser?) and everything is strangely starting to look an awful lot like a nail?

Re:fsck'n ugly (5, Informative)

EvanED (569694) | more than 7 years ago | (#18132490)

html/css sucks at MANY things - how about a self-updating TOC? (don't even try to say some javascript parsing the DOM for header tags with certain IDs to generate it dynamically!)

This would have to be done by the tool displaying it, same as a self-updating TOC in a Word or OpenOffice Writer document. The information is present in a correctly-structured HTML document in the form of Hx tags.

Hell, how can you even tell the page numbers in a html "document" anyways?

The same way you would in a Word document. It doesn't make sense if you're looking at it as a web page in your browser, but if your editor used HTML it would work the same way. (This also partially alleviates the rendering issues.)

Re:fsck'n ugly (5, Insightful)

Anonymous Coward | more than 7 years ago | (#18132554)

I don't see (x)html + css as being the answer either:
Only because you can't tell the difference between "XHTML + CSS" and "web pages".

-too many versions of html (4, and perhaps 5 soon) and xhtml (1.0, 1.1, strict, transitional, etc)
So? Pick one as your word-processor standard, and rule all the others out. The existence of too many versions of MS Word doesn't seem to have hurt the .doc format.

-different versions of CSS, browser support for it varies quite a bit (and is pretty much non-existent for CSS3)
What does browser support have to do with word processing? We're talking about word processors, not web sites.

-too many rendering engines, css hacks required so the content displays the same in most of them, etc
And this is different from word processors how? Microsoft's XML format is absolutely crammed full of hacks to duplicate obscure rendering features of obsolete versions of Word, WordPerfect, etc. And it would surprise me very much if the rendering of ODF was pixel-identical between all the products that support it.

-html/css sucks at MANY things - how about a self-updating TOC? (don't even try to say some javascript parsing the DOM for header tags with certain IDs to generate it dynamically!)
You're thinking of web pages, not HTML. HTML used for a document could easily have an auto-generated table of contents. Remember that we're talking about using HTML as the file format for a word processor. A word processor can trivially parse the DOM for header tags and update a table of contents without requiring any JavaScript at all. It's kind of what word processors are for.

Hell, how can you even tell the page numbers in a html "document" anyways?
By looking at the little "Page N of N" display in your word processor, I would assume.

-while word/OOo formats aren't real typesetting (like InDesign CS2 would do), at least they have half-way decent typography. Yeah, no fancy glyphs or super precise kerning, but it's still usable. On the web there's only a handful of "just OK" fonts one can use (unless everything is rendered server-side as images).
What does "on the web" have to do with word processors? We're not talking about the web here. We're talking about word processors, which will have access to all the fonts the user owns, just like any other application.

-if people use html/css, there would basically be no standards *at all* or anything even resembling it (much like anything we see on the web).
Why not? We're talking about word processors, not the web. We're talking about computer-generated HTML, not something some 13-year-old hacked together by copying-and-pasting examples into Notepad. It would be trivial to enforce valid XHTML 1.1 + CSS2.1, for example.

Re:fsck'n ugly (0)

Anonymous Coward | more than 7 years ago | (#18132958)

CSS3 isn't a standard yet. Why would any browsers really care about supporting a moving target?

It's actually counter-productive, because people will write 'draft-css3' webpages that work in todays browsers, and expect the obsolete code to properly display in future browsers.

Re:fsck'n ugly (0)

Anonymous Coward | more than 7 years ago | (#18132844)

"Let's face it, the average Joe is going to use whatever Microsoft pushes at them. Case closed."

The average Joe isn't Microsoft's target. It is the business environment.

Classic quote for the books, gotta love XML play (5, Insightful)

Tablizer (95088) | more than 7 years ago | (#18132154)

"Both are basically memory dumps with angle brackets around them."

indeed (1)

game kid (805301) | more than 7 years ago | (#18132196)

...and sig'd in tribute.

Even more classic perhaps, 'The "layer" element?!' Sure raised my eyebrow; a huge change from "Netscape engineers are weenies!" by any metric. :)

Re:Classic quote for the books, gotta love XML pla (1)

nigels (264332) | more than 7 years ago | (#18132568)

I also liked: "Microsoft--please--if you think standards are so important, why not start using them?"

Is it mature enough? (3, Interesting)

Goalie_Ca (584234) | more than 7 years ago | (#18132160)

HTML and CSS are quite capable of rendering and displaying webpages. What happens with a simple thing like a file header showing page number and author name. Footers with footnotes? How about dealing with table of contents etc. How would a page in a document be broken down? Anyone who's tried to print HTML knows there are many issues with layout. What's sad though is that even HTML and CSS is not supported the same in all browsers.

I'm a latex junkie. Latex though is a PITA to create templates and styles for. Someone willing to take up the task to modernize latex or completely replace it?

Re:Is it mature enough? (5, Informative)

willy_me (212994) | more than 7 years ago | (#18132194)

I'm a latex junkie. Latex though is a PITA to create templates and styles for. Someone willing to take up the task to modernize latex or completely replace it?
Done. It's called ConTeXt [pragma-ade.com] .

Re:Is it mature enough? (1)

the_womble (580291) | more than 7 years ago | (#18132280)

Context has its weaknesses too.

For example, it cannot produce print and HTML versions of the same document. This may not matter to everyone, but it was something I needed, so I stuck to Latex.

Re:Is it mature enough? (1)

Anonymous Coward | more than 7 years ago | (#18132700)

That must be one of the crappiest websites and presentations I've ever seen.

Oh and that color. Must...not...get...eye...cancer.

Re:Is it mature enough? (2, Informative)

Anonymous Coward | more than 7 years ago | (#18132740)

If you want to stay in Latex use the memoir [ctan.org] document class.

Re:Is it mature enough? (0)

Anonymous Coward | more than 7 years ago | (#18132212)

Latex though is a PITA to create templates and styles for.

With great power comes great learning curve.

As for the rest of the post, I agree. Even as designed, there are lots of things CSS is incapable of on websites that are realistic. People like to thump their chests and talk about how tables are obsolete, but I have yet to see an honest replacement for tables for tabular data, and the table CSS is incredibly weak. If I'm generating data on the fly, I have to cache the entire data so that I can ensure the columns are the correct widths to display the data, since there is no notion of "fit to data" beyond "just make random columns that never look the same way twice". Of course, the measurements I make are meaningless should the user override my font setting, leading to the tables looking even shittier. I could just use proportional columns, on a widescreen display that just leads to shit like a column containing a two digit number being 3 inches wide, but hey, at least the table has rounded corners.

Re:Is it mature enough? (4, Informative)

indiechild (541156) | more than 7 years ago | (#18132406)

Tables are not obsolete. Tables are still used for tabular data, which is what they were originally intended to be used for, and that has not changed.

Tables shouldn't be used for page layout -- that's what CSS is for. It's as simple as that.

Re:Is it mature enough? (4, Funny)

MrNaz (730548) | more than 7 years ago | (#18132604)

You mean you display tabular data *without* tables? Dude, you missed the point in a big way. Like say for example Andre Agassi was serving a tennis ball at you, by "missed" I mean he was serving the ball on a court in California while you were standing waiting to receive on a court in Florida.

Re:Is it mature enough? (1)

lewp (95638) | more than 7 years ago | (#18132230)

http://www.alistapart.com/articles/boom [alistapart.com] describes how they handled that stuff using CSS2 and proposed CSS3 features.

I'm not writing a book any time soon, and if I were I wouldn't take this approach, but it is an interesting read.

Re:Is it mature enough? (1)

tomstdenis (446163) | more than 7 years ago | (#18132330)

Little tip, if your book has any technical edge to it, learn LaTeX and do the layout/setting yourself.

Being in control of the layout and setting is very important if you value your creation at all. ... Just saying. not bitter.

Tom

Re:Is it mature enough? (1)

8-bitDesigner (980672) | more than 7 years ago | (#18132246)

CSS is mature as a standard, though it's lacking a good implementation of many of its features. Web browsers really haven't had much reason to properly implement CSS print standards and layouts, so most browsers are optimized for printing table-based layouts.

I have no doubt that you could print a book with CSS/HTML or manage a Word style document, but you'd need a platform that holds the spec much tighter than the current crop (and yes, that includes Firefox).

Re:Is it mature enough? (2, Interesting)

tomstdenis (446163) | more than 7 years ago | (#18132306)

The trick to using LaTeX safely is automation. The less TeX twiddling you have to do manually the better.

For me, I write my user manuals [for my FL/OSS projects] in LaTeX because the layout is much better, and the process much simpler than wrestling with a word processor.

Why anyone writes books in anything else is beyond me.

My first book [math text] that was published was all LaTeX, and while it wasn't all super simple the vast majority of the layout and setting work was handled by TeX itself. My second book [crypto text] was written in Word [required by publisher] and the tables were not set properly, equations look like shit, etc.

Word processor == memos, letter home to Grandma.

Typesetter == Papers, Books, Print material

Tom

Re:Is it mature enough? (2, Insightful)

sweetooth (21075) | more than 7 years ago | (#18132362)

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.

Re:Is it mature enough? (0)

Dutch Gun (899105) | more than 7 years ago | (#18132444)

It is possible to build a new format on top of the universally understood HTML and CSS.
Awesome. So he wants us to use a language originally designed to display text, images, and hyperlinks in a context-sensitive manner as a document format? That's just what the industry needs... another house built on a foundation of sand.

To show that it's possible, Bert Bos and I published a book using HTML and CSS.
File | Export to Web? Am I missing something here? What does that prove?

Funny, he didn't mention that he "wrote" the book in HTML, just that he "published" it in HTML. I can publish my book to HTML, PNG, text, paper, Braile, and Morse Code. It doesn't make that an appropriate universal document format though.

Look, I agree with his derision of MS and their hypocritical format games. But he really should have known where to quit. The specifications are just binary dumps with brackets around them? I think he stretches his credibility a bit there.

Re:Is it mature enough? (2, Informative)

EvanED (569694) | more than 7 years ago | (#18132512)

File | Export to Web? Am I missing something here?

Yes, the fact that he used a program called Prince to generate a reasonably professional-looking "book" [opera.com] . Not "printed web page". Book.

Funny, he didn't mention that he "wrote" the book in HTML, just that he "published" it in HTML.

"It is now possible, even feasible, to use HTML as the document format for books." (Granted, that's two links off the /. summary.) But "To prove how powerful it can be, the authors decided to use CSS in the production process" is following only one link.

That PDF posted above was generated entirely from an HTML + CSS document.

huh? (4, Funny)

User 956 (568564) | more than 7 years ago | (#18132166)

Putting this to the test, Håkon has published a book using HTML and CSS.

Uhm. I'm no expert, but isn't a book that uses HTML and CSS called a website?

Re:huh? (5, Informative)

8-bitDesigner (980672) | more than 7 years ago | (#18132232)

Actually one of the highlights of the CSS spec is support for non-standard display types, such as screen readers, projectors, PDA, and yes, print. CSS is a rather brilliant standard, but since W3C hasn't really seen fit to publish a reference platform for it, there's no real compliance checking in the major browers.

Re:huh? (1)

hixie (116369) | more than 7 years ago | (#18132500)

Given how much difficulty all the browser vendors (who are working on this full time) have had getting their CSS implementations right, I don't see how we could expect the W3C to make a perfect implementation... Some things are just hard to get right. Dynamic typographic layout of the kind CSS allows is one of them.

Re:huh? (2, Insightful)

kestasjk (933987) | more than 7 years ago | (#18132836)

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.

Re:huh? (1)

EvanED (569694) | more than 7 years ago | (#18132254)

Not really when it's rendered into, say, a PDF [opera.com] formatted like any book. Based on that sample, I'd say that if that's not a (proof-of-concept) book possibly nothing you download is. It looks pretty reasonable.

Did you RTFA?

Re:huh? (1)

natrius (642724) | more than 7 years ago | (#18132322)

Isn't a book that uses Microsoft Word's .doc format called a Word document?

A document doesn't turn into a physical book until you hit print. The book itself is about the content, not the physical form. Dive into Python [diveintopython.org] is a book that I just happened to read online in web page form.

Borat's here (1, Funny)

cntlzed (618525) | more than 7 years ago | (#18132172)

FTA: Kazakhstan recently joined the relevant ISO group.

OMG, Borat is teaming up with Steve Ballmer to spew out 6000 page docs!! Run for cover!

No, NO. (0, Offtopic)

game kid (805301) | more than 7 years ago | (#18132206)

OMG, Borat is teaming up with Steve Ballmer to spew out 6000 page docs

Steve squirts them out, remember?

Re:Borat's here (0, Offtopic)

User 956 (568564) | more than 7 years ago | (#18132234)

OMG, Borat is teaming up with Steve Ballmer to spew out 6000 page docs!! Run for cover!

You should run for cover, because he's spewing chairs with those documents.

CSS for Documents? (5, Insightful)

zaydana (729943) | more than 7 years ago | (#18132174)

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.

Re:CSS for Documents? (1)

athakur999 (44340) | more than 7 years ago | (#18132220)

WordPerfect has had a feature like this for years called "show tags" (I think). It'd show you where formatting markers started and stopped (similar to an HTML source listing). It was pretty useful. I'd love to see OpenOffice incorporate a feature like this (if it doesn't already).

The proper term is (1)

rdwald (831442) | more than 7 years ago | (#18132256)

Reveal Codes

WordPerfect on Linux [linuxmafia.com]

Re:CSS for Documents? (3, Informative)

Coryoth (254751) | more than 7 years ago | (#18132240)

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?

Such things exist. TeX provides a decent the base for such things, so it's a matter of finding a TeX centric editor. LyX would be a good example, and indeed it has the sort of functionality and general approach to document creation that you seem to be after. Of course it doesn't necessarily have all the other features that other word processors might have (like mail merge or what have you).

Re:CSS for Documents? (2, Insightful)

the_womble (580291) | more than 7 years ago | (#18132250)

Latex: its not that hard to learn.

Lyx provides a GUI front end, but you lose a lot of flexibility.

Texmacs might work for you as well, although I found it very clunky.

Re:CSS for Documents? (3, Interesting)

Antique Geekmeister (740220) | more than 7 years ago | (#18132418)

Indeed: LyX is extremely handy for providing to undergraduates or research assistants whose thesis advisors insist on using TeX or LaTeX, who lack the time to learn yet another language. LyX is the difference between having slightly more elegant .tex files, and getting an hour more of sleep a night when writing your thesis because you can edit in a GUI and don't have to debug your .tex files.

I am finding myself wishing that OpenOffice had pursued putting a vastly better interface on TeX and LaTeX, rather than writing their own standard. It would probably have been faster and certainly would have been a lot more stable. Microsoft couldn't have even thought about it: its clean, open standards would not have lent themselves to the proprietary "extend" part of Microsoft's "embrace and extend" approach, or Microsoft's software licensing models.

Re:CSS for Documents? (1)

Constantine Evans (969815) | more than 7 years ago | (#18132694)

LyX is the difference between having slightly more elegant .tex files, and getting an hour more of sleep a night when writing your thesis because you can edit in a GUI and don't have to debug your .tex files.

That depends. LaTeX does have a very steep learning curve, but an adroit user can write in LaTeX itself far faster than in LyX (and faster, I believe, than in nearly any other system), especially for papers with heavy math content. The \def and \newcommand commands are extremely useful in this regard: simply define things that you will need often, and then use them. This can mean the difference between:

r = 1 + \epsilon\sum_{n=0}^{\infty}\sum_{m=-n}^{n}
\left( F_{nm}(t)\mathcal{Y}_{nm}(\theta,\phi)\right)
\en d{equation}
and

\beq
r = 1 + \e \sumni\sum_{m=-n}^{n} \lt( \F{nm} \Ynm{\t,\p} \rt)
\eeq

Re:CSS for Documents? (1)

Antique Geekmeister (740220) | more than 7 years ago | (#18133020)

Sir or madam, I understand your point. I can write in C far, far faster than most object-oriented programmers can write in C++ or Java, and get far better performance out of fewer lines of code. But to do that, I had to learn C. Expecting the many casual document authors to write in a programming language instead of being able to "click on this and click on that" to make a statement in bold text, or change its font, or even make a list of elements, is asking a lot from a casual user.

This stuff needs to work for casual users who are already pressed for time, or they won't use it.

Re:CSS for Documents? (1)

fredboboss (1059056) | more than 7 years ago | (#18132464)

I've been searching for an easy and fast way to publish documents.
In the places where I worked I saw people were loosing too much time
with text processors. Instead of focusing on content they were fiddling
with fonts, colors, ... style. This usely lead to poor content.

What is needed is separation of content and style :
text then style, content then presentation.

Opera CTO is right with HTML and CSS,
but they might not be appropriate for publishing.

PDF is a good format for publishing and it is widely used but
it is missing the template feature.

Lyx can do the trick but template customization and generation
is not easy for non (latex)latex aware people (non programmers).

I've searched for such a mean to separate text and style, you just type text,
then your style is automatically applied, check my web page :
http://fredboboss.free.fr/pyfpdf/index.php [fredboboss.free.fr]

At last you get a PDF ready for publishing, this is just a proof of concept,
but the idea is that you can keep your content an change the style
whenever needed.

I don't know what ODF format consists in, but a good document format
for producing document ready for publishing would allow seperation of
content and style à la CSS stylesheet so that users can just concentrate
on text.

fred

Re:CSS for Documents? (2, Informative)

Haeleth (414428) | more than 7 years ago | (#18132610)

Latex: its not that hard to learn.
But it is tricky to use for any language other than English. Out of the box, it's English or nothing. Other European languages are complicated; more complex languages like Arabic, Hindi, or Chinese require some very involved hacks indeed.

It can be done, some of the time, but it's very, very easy to mess up. I have tried numerous times to get Japanese support, using one of the several special Japanese versions that exist (it seems it simply can't be done with standard TeX), and only once did I manage to generate a DVI - which I was unable to convert to a usable format, because doing so always stripped out all Japanese text, for some reason I never managed to fathom.

And this is all fair enough, because TeX was written to scratch Knuth's itch, and therefore it does what Knuth needed very well: it's brilliant for typesetting English and mathematics. Unfortunately that doesn't make it the solution to all the world's typesetting problems.

I hate to say it, but "inferior" products like MS Word, OpenOffice.org, etc. have supported Arabic, Hindi, Chinese, and Japanese perfectly for as long as I can remember. Largely because they use Unicode internally, rather than one of the numerous inadequate and non-standard encodings that TeX and its derivatives rely on.

To be fair, there's a Unicode version of TeX called Omega or some such. I'd doubtless have found it very useful if I'd ever managed to get it to work at all.

Re:CSS for Documents? (1)

zsau (266209) | more than 7 years ago | (#18132840)

To be fair, there's a Unicode version of TeX called Omega or some such. I'd doubtless have found it very useful if I'd ever managed to get it to work at all.

Take a look at XeTeX [sil.org] . It installed without a hitch on my computer (ppc debian) once I altered the Debian control stuff to compile against the TeXLive TeX packages rather than teTeX. Or if you run on a more normal platform (x86 ubuntu/debian/SuSE, MacOS X, maybe Windows) there's precompiled packages for you. It will use any OpenType (or TTF, or on OSX those Apple fonts) font you've got installed on your computer with complete (low-level) access to the special features, or higher-level access to most stuff via the fontspec LaTeX package. I quite happily no longer bother pissfarting around with stupid font packages. The only disadvantage I've found from XeTeX is that because it uses xdvipdfmx to convert to PDF you can't get special features from pdfTeX, and that it has the potential to make your input files platform-specific.

As for Omega, it's a dead end; AFAIK what it's given us will at some point be intergrated along with the scripting language lua and pdfTeX into something called LuaTeX. I might be mistaken on that front.

Re:CSS for Documents? (1)

the_womble (580291) | more than 7 years ago | (#18132928)

Incidentally, the site linked to from my sig is generated from a latex file. I have some TCL scripts that parse the Latex and generate more Latex files for the index pages.

I did it this was so that I could also do a print [amazon.co.uk] version [amazon.com] from the same source document.

Re:CSS for Documents? (1)

eelke_klein (676038) | more than 7 years ago | (#18132260)

Word processors have had such features for years. They are called styles. If you apply to each chapter title the same style and later change the style all the chapter titles will be changed immediatly. You can even couple things like chapter numbers to such styles.

Re:CSS for Documents? (1)

EvanED (569694) | more than 7 years ago | (#18132270)

...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?

Both OpenOffice and Word have this, they're called styles. Word has had it since at least version 6 and maybe before, though at least before 2007 (which I haven't used so can't comment on) they haven't done much to bring attention to the feature. OO has had it since the beginning, and puts rather more emphasis on it.

Re:CSS for Documents? (1)

EvanED (569694) | more than 7 years ago | (#18132284)

Hmm, looks like I was beaten to the punch [slashdot.org] . Feel free to mod me redundant.

Re:CSS for Documents? (0)

Anonymous Coward | more than 7 years ago | (#18132428)

i've always thought, why doesn't updating this style make all text with that style update

In current versions of Word, at least, it does. If you open the Styles sidebar and modify a style, it applies to the whole document. If you click a formatting widget, you're making a local change, so the correct behavior is to change just that text.

Re:CSS for Documents? (1)

zsau (266209) | more than 7 years ago | (#18132848)

In Word, modify your formatting toolbar. Get rid of almost everything from it, except for lists and the first dropdown (and the button before it). Click the button before it. Now you have a setup like mine (when I'm forced to use a word processor--I much prefer TeX). Use the styles. When you think "this would be better in red", just create a new style and format it as red.

I've been doing this since Word 6.0, when I first used a GUI wordprocessor. Stylesheets aren't by any means a new thing: They're just one of the many features of them that most people don't seem to know about.

I don't know that I agree completely (5, Insightful)

Evardsson (959228) | more than 7 years ago | (#18132190)

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. Re:I don't know that I agree completely (1) Rosyna (80334) | more than 7 years ago | (#18132262) 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?

Yes, exactly. Instead of taking one of two specifications created just for rich document formats, he suggests making a brand new specification by extending CSS/HTML to do something it doesn't yet seem ready to do.

Re:I don't know that I agree completely (1)

EvanED (569694) | more than 7 years ago | (#18132298)

Instead of taking one of two specifications created just for rich document formats, he suggests making a brand new specification by extending CSS/HTML to do something it doesn't yet seem ready to do.

Did you RTFA? He's not suggesting making NEW specifications because THEY ARE ALREADY MADE. There is a proof-of-concept "book" [opera.com] linked from the page that demonstrates that the technology to do this at least reasonably well already exists.

Re:I don't know that I agree completely (1)

nick.ian.k (987094) | more than 7 years ago | (#18132372)

Yes, exactly. Instead of taking one of two specifications created just for rich document formats, he suggests making a brand new specification by extending CSS/HTML to do something it doesn't yet seem ready to do.

This talk of not creating new standards is ludicrous: there are already existing XML schemes geared towards this sort of task. Why should HTML/CSS be extended for publishing non-web documents when the work's already been done elsewhere? It gets even more ridiculous when you stop to think about all the bullshit that's been edged out of HTML over the past decade or so that we're *still* struggling to get people away from.

Re:I don't know that I agree completely (1)

Antique Geekmeister (740220) | more than 7 years ago | (#18132396)

PDF would have been a candidate, but Adobe's licensing and that of ancestor, Postscript, are awkward to deal with. That's hindered their acceptance in other uses, such as Postscript display systems. (It could have been a superios display system to X, and much easier to display remotely.)

But it hardly takes a $350 tool to handle: PDFcreator, available over at sourceforge.net, and the old Ghostview viewer both rely on Ghostscript to process PDF and work more quickly and reliably than Adobe's conversion tools, especially with mixed language documents. And they're both freeware. Re:I don't know that I agree completely (1) larry bagina (561269) | more than 7 years ago | (#18132498) PostScript (and PDF) have the adobe problem, but there is a better format that doesn't: DVI (the device independent format created by Donald Knuth). Just as NeXT took PS and made Display PostScript, and Apple took PDF and made Display PDF, the DisplayDVI [displaydvi.org] project has been working on a windowing display system based on DVI. It's still beta, of course, but I've been using it without problems. It includes a rootless X-Window client, so legacy X-Window apps can be run with native DVI apps. Re:I don't know that I agree completely (1) Antique Geekmeister (740220) | more than 7 years ago | (#18132962) How interesting: does it have anything resembling the necessary performance for graphics to handle games? Re:I don't know that I agree completely (1) Evardsson (959228) | more than 7 years ago | (#18132508) But it hardly takes a$350 tool to handle: PDFcreator, available over at sourceforge.net, and the old Ghostview viewer both rely on Ghostscript to process PDF and work more quickly and reliably than Adobe's conversion tools, especially with mixed language documents. And they're both freeware.

I won't dispute the availability of free PDF creation tools, but do they understand and parse CSS3? That was the key element that made this particular implementation work. Considering that CSS3 isn't even a finalized specification yet, I would be more than a little surprised.

Re:I don't know that I agree completely (1)

Kalriath (849904) | more than 7 years ago | (#18132724)

They usually don't parse anything. Usually, they are printer drivers which just print off whatever the browser hands them.

Re:I don't know that I agree completely (3, Insightful)

panaceaa (205396) | more than 7 years ago | (#18132876)

Why is anyone even talking about the opinion of a CEO? Opera is an HTML company -- they make HTML browsers. Why would the CEO of Opera have anything objective to say about OOXML or OpenXML? He wouldn't, which is why his pushes his own company's core competency: HTML. While Opera doesn't have a huge market share, if the market for HTML viewers grows, his company's likely to take a piece of that pie. But it's completely bunk because HTML's a mess of different standards, with many people using HTML 4.01 Transitional to this day, and the idea of people adopting CSS3 and writing documents using HTML is pretty far fetched. But you would never hear that from the CEO of an HTML browser company.

I don't think he gets it. (2, Insightful)

8-bitDesigner (980672) | more than 7 years ago | (#18132216)

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?

Validation is relevant (2, Insightful)

SanityInAnarchy (655584) | more than 7 years ago | (#18132352)

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.

He gets it. (1)

Per Abrahamsen (1397) | more than 7 years ago | (#18132452)

> 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.

Depends on what you define the problem as. That there is too many "standards", or that all of them sucks. If the later, defining a new standard that does not suck solves the problem.

How come? (5, Funny)

ShaunC (203807) | more than 7 years ago | (#18132242)

If forced to choose one, I'd pick the 700-page specification (ODF) over the 6,000-page specification (OOXML).
So I'd ask Håkon, "how come?" :)

Re:How come? (1)

im_thatoneguy (819432) | more than 7 years ago | (#18132356)

I don't know. I would also like to know how you can evaluate the strengths and weaknesses of a system based solely by its size.

Besides, how often is a human planning on parsing the files manually? If you ask me, the only purpose these open document file formats serve is to be opened by other word processors, which means as long as its standardized it could probably look like Chinese and it wouldn't phase me in the least.

Re:How come? (1)

vmcto (833771) | more than 7 years ago | (#18132432)

So you don't think an application developer wanting to do something as simple as text searches to provide document integration capabilities should be considered? Let the word processor people make our documents as incomprehensible as possible?

6000 Pages, say 30 pages/day, =200 days (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18132594)

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.

Re:How come? (1)

jlarocco (851450) | more than 7 years ago | (#18132842)

I don't know. I would also like to know how you can evaluate the strengths and weaknesses of a system based solely by its size.

I don't think he was evaluating the strenghs and weaknesses by their size. He plainly said both standards suck, regardless of their size. Given that, if forced to choose which one to implement, it makes more sense to suffer through a "mere" 700 pages instead of 6000.

Besides, how often is a human planning on parsing the files manually? If you ask me, the only purpose these open document file formats serve is to be opened by other word processors, which means as long as its standardized it could probably look like Chinese and it wouldn't phase me in the least.

There are a whole bunch of reasons why the standard should be as simple and small as possible. Not so much that requirements get left out or "blurred", but there shouldn't be a bunch of unnecessary complexity..

The most important reason is that the actual implementations will be done by several groups of developers, working on several unrelated products. The more complex or unclear the standard is, the more likely it becomes that different groups will interpret the standard differently. Since the point is to make an interoperable, standardized document format, it defeats the point if different products implement the standard differently.

Also, the size and complexity of the standard is likely to have a direct impact on the number of bugs in the implementations. Microsoft can't get backward compatibility with Word 95 right, yet it's in their standard. Other projects wouldn't have a chance.

Overall, I agree with the guy from Opera. Both standards are basically memory dumps with brackets. Using HTML+CSS for publishing doesn't make sense, though.

Re:How come? (2, Insightful)

_Shad0w_ (127912) | more than 7 years ago | (#18132672)

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.

"Fly aeroplane."

Re:How come? (4, Informative)

PCM2 (4486) | more than 7 years ago | (#18132822)

So I'd ask Håkon, "how come?" :)

Since nobody gets it, I'll spoil it: That's how Håkon advises people to pronounce his name. It's even on his business card.

XML (1)

infonote (1065258) | more than 7 years ago | (#18132410)

Both standards follow XML, because XML helps documents become universally available whatever the device. HTML and CSS have limitations.

Re:XML (1)

00lmz (733976) | more than 7 years ago | (#18132484)

Both standards follow XML, because XML helps documents become universally available whatever the device. HTML and CSS have limitations.

Yes, because XHTML is not a form of XML and there are more implementations of Yet Another XML Format for "whatever the device" than there are implementations of HTML/XHTML and CSS for "whatever the device"...

Is there a FOSS way to make PDF from XHTML/CSS? (1)

Prince is a commercial product. I have a minor need to produce PDF's from XHTML/CSS and I really don't want to deal with licensing. I would need to run it on a server where multiple people can access it which means I would have to pay $3800 for Prince. Ouch! I don't need to do this that bad. Is there any way to do this with Free/Open Source software? Re:Is there a FOSS way to make PDF from XHTML/CSS? (2, Informative) vtrac (876898) | more than 7 years ago | (#18132506) I don't know if there's an automated way, especially because you run into the problem of differences in rendering. But, if you are on Linux, just install CUPS-pdf or on Windows, use PDFCreator (http://sourceforge.net/projects/pdfcreator/ [sourceforge.net] ). Both are print drivers so you can use the HTML/CSS rendering engine of your choice (pick a browser), then print. Re:Is there a FOSS way to make PDF from XHTML/CSS? (1) Tracy Reed (3563) | more than 7 years ago | (#18132608) Yeah, I have considered that. Unfortunately for my application it would have to be a bit more automated/scripted which I don't think I could do using the renderer from a web browser. Thanks! Re:Is there a FOSS way to make PDF from XHTML/CSS? (1) Spliffster (755587) | more than 7 years ago | (#18132622) HTML + XSLT + XML-FO. XML-FO is an apache project (or at least was 3-4 years back when I used it). Cheers, -S Re:Is there a FOSS way to make PDF from XHTML/CSS? (2, Informative) smoker2 (750216) | more than 7 years ago | (#18132980) CSS not withstanding, you can use HTMLDOC [htmldoc.org] to produce PDFs from html pages. If you are creating reports etc dynamically anyway, just create a temporary html file and convert it through HTMLDOC. I use Perl to generate reports and interface with HTMLDOC, but YMMV. An example of the HTMLDOC specific code used in the conversion : # Run HTMLDOC to provide the PDF file to the user... system "htmldoc --continuous --browserwidth 800 --landscape --size A4 --header ... --left 1in --embedfonts -f$fileref.pdf \$filename";
(the command is all on one line)This is running on RHEL 3 through Apache 2 and Perl 5.8.0

Can != Should (2, Insightful)

gbulmash (688770) | more than 7 years ago | (#18132438)

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

to kill a mockingstandard (2, Insightful)

mennucc1 (568756) | more than 7 years ago | (#18132440)

An extract of H Wium arguments:

ODF is an XML-based dump of the internal data structures of OpenOffice, while OOXML is an XML-based dump of the internal data structures of Microsoft Office.

In 2006, a year or so after ODF entered the fray, Microsoft submitted OOXML to the standardization process. Are we seeing a pattern here? Is Microsoft undermining standards by submitting them? Could it be that it wants both ODF and OOXML to fail?
so Wium proposes to build a new standard from scratch , starting from HTML and CSS ; but, recognizing that they would not cover all "Office" documents, he goes to saying

Additional semantics (say, formulas in spreadsheets) can be encoded as attributes, as do microformats, and CSS 3 offers advanced features for printing (e.g., footnotes and header and footers).
My thoughts:
• Suppose MicroSoft were to listen to Wium (which they wont). Guess what ? Those additional fields containing formulas (and anything else that makes {MS,Open}Office much more useful than HTML) again would be just an XML-based dump of the internal data structures of so and so.
• I dont like , more in general this article. Wium is saying that MicroSoft is proposing OOXML to kill ODF ; and at the same time he is proposing to kill ODF in favour of a non-existent extension of HTML+CSS. It is like the guy saying : "I dont like the power plugs in my new house, lets tear the house down and rebuild it" , and at the same time saying "why are they taking so much time to build the house?". Suppose MicroSoft would use arguments as those by Wium to convince ISO to reject ODF and then start a new draft based on HTML, drafted in cooperation between MicroSoft and other partners (including OpenOffice). That would really kill any hope of an ISO standard for "office" documents.

Why not HTML for books? (1, Insightful)

zerblat (785) | more than 7 years ago | (#18132470)

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 <menu>, and a bunch of other stuff that need to be fudged by using elements that don't really fit). In HTML there is no <chapter>, no <footnote>, no <toc>, no <index>. 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.

Re:Why not HTML for books? (0)

Anonymous Coward | more than 7 years ago | (#18132688)

XHTML2 fixes most problems. I've only browsed through the proposed standard, so I might be wrong.

• It has <section>-elements that can be used to specify chapters
• Elements can have a "src"-attribute, that can include [w3.org] content
• Headers/footers/pages can be defined using CSS3

I think it is an important point (1)

blind biker (1066130) | more than 7 years ago | (#18132534)

I think it is important that a document format is humanly-readable and understandable, so that one can get at least some idea of the layout of a document by reading the content of the file. I understand very well when he says "memory dump in angle brackets". Besides, anything that is humanly-"parsable", can be parsed by software, while the other way around is not usually the case.

Re:I think it is an important point (0)

Anonymous Coward | more than 7 years ago | (#18132904)

Not really. English is humanly-"parsable" but it's too difficult to write software to understand English. File formats should be easy to parse by software and not necessarily by humans.

fonts (2, Informative)

cybpunks3 (612218) | more than 7 years ago | (#18132576)

The problem with using HTML for publishing is that to this day there is no viable downloadable font system. So you are limited to a lowest-common-denominator list of 2-3 fonts like verdana and new times roman. With Flash and PDF you can do a lot more, but obviously authoring becomes a problem.

Re:fonts (1)

nick.ian.k (987094) | more than 7 years ago | (#18132862)

With Flash and PDF you can do a lot more, but obviously authoring becomes a problem.

Well, maybe. Have you ever looked at font licenses? There are more than a few digital type foundries using licenses that expressly prohibit embedding outlines of the glyphs in other files. This is because the outlines of the glyphs (mathematically represented by the font software) are the one part of the font that's actually copyrightable; the actual glyphs themselves are not (this is why so many foundries have their own individual versions of Helvetica and so on). Not everybody's bad, but Linotype and Adobe have been rather outspoken about this over the last few years, though admitedly I haven't really seen them actually enforcing it too much.

Too true (3, Insightful)

iamacat (583406) | more than 7 years ago | (#18132598)

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...

Re:Too true (0, Offtopic)

le_lotus_604 (752411) | more than 7 years ago | (#18132872)

aaahh Kernighan, Richie .. the black cover, always to remember !!! HTML, it stands for HyperText right !!

I wrote my thesis book this way (3, Informative)

Rudd-O (20139) | more than 7 years ago | (#18132616)

And it worked out great.

http://software-libre.rudd-o.com/ [rudd-o.com]

Used MediaWiki to write the chapters, wrote a small python proggie (available there) to consolidate the wiki into a single HTML file (mostly conforming to the Boom! microformat), then used Prince and Hakom's book CSS to generate the PDF.

Great typesetting, collaborative book editing, screw LaTeX!

Hakom was right.

Scribus? (0)

Anonymous Coward | more than 7 years ago | (#18132636)

Anyone? http://www.scribus.net/ [scribus.net]

Jesus Christ, Zonk! (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18132648)

First the Citizenr ponzi scam slashvertisement, and now this ammo for every MCSE who's ever heard of Slashdot? Where the fuck did CowboyNeal find you?

Maybe... (1)

Bellum Aeternus (891584) | more than 7 years ago | (#18132782)

If Html+Css offered a better model instead of the box model (example the point-line model) and offered some way of doing basic data structures I'd agree. The current box model is very limiting in its layout abilities.

Modern documents have so many binary data types inserted in them (images, fonts, etc.) that Html+Css isn't enough. It isn't even enough on the web and that's why Javascript and Flash are so prevalent. There needs to be another specification to support all the needs/wants of the users (who are not willing to go backwards for any ISO standard).

!RTFA (1)

Anonymous Coward | more than 7 years ago | (#18132878)

Okay, I may have read a tiny bit, but it's irrelevant.

The question is what does it do and how well does it do it?'

Should we desire for screen displayed content be equivalent to printed to published? No.

Do we desire for the three to have accessible translations between each other? Yes. And note that it goes both ways. I want to be able to throw an e-mail on a webpage and throw a doc on an e-mail and throw all three in a book and so forth. As more technology becomes available and therefore new mediums develop I want to be able to throw stuff in them and throw them in stuff.

Now sure, a book isn't that accessible to go back to digital (yet). Why not? Throw a barcode system in the books. They have an index and a table of contents and chapters and a bibliography. Why not a printed information to digital information code' (PITDIC)?

But we're talking digital document formats.. which means that there should be what? What is the equivalent of having a barcode system in a book to allow a quick scan to give you all the data contained therein as a digital contents with relevant tagging/metadata? Uhh, dumbass. It's the metadata and the content, together!

Which is what XML and ODF and whatever dreck Microsoft has tried to override ODF with. Now, I have not studied the specific formats (so yes, you can call me an ass for being biased against MSFT), but if they are properly designed then they are a step in the right direction. What is properly designed? It's when they are simple and basic and elegant enough that we can change down the road and not break the old.

We're not children anymore, humanity. It's time we think about how to do that. And before you bitch at me, note there's a difference between being obsolete/technologically inferior and broken. Broken is when I can't access my old stuff. Obsolete/technologically inferior is when I don't want to.

ODF a memory dump of OOo? (1)

renoX (11677) | more than 7 years ago | (#18132880)

I wonder if it's true, after all there are two implementations of ODF: OOo and KOffice, it'd be interesting to hear KOffice developers on the subject.

Recently I hear a criticism of ODF by Miguel de Icaza is that ODF doesn't reuse standards like SVG as much as it should..

Open Office Herecy (sold here) (5, Interesting)

IBitOBear (410965) | more than 7 years ago | (#18132884)

I use OpenOffice. I support Open Document Format over MS/XML and .doc.

That said, ODF it kind of blows. Really.

I write novel-length "books" and it is FREAKING IMPOSSIBLE to do some very basic things in any/every ODF based word processor I have tried to date.

Exercise for the Interested:

Make a "Book" with an automatic table of contents, said table to contain an "Authors Note", "Prologue", auto-numbered chapters 1 to N with their associated chapter titles (where the actual chapter number is the chapter number internal variable), and finally "Epilogue" all at the same level of the index.

This simple task is essentially impossible. The flaw is caused by the fact that everything goes through the "styles" and the styles don't inherit their list membership properties. You should be able to make a style "TOC Entry" that is assigned to a particular table of contents level (e.g. level 1) then make a sub-style "Chapter Heading" based on "TOC Entry" but with the chapter numbering magic attached, and in so doing, create "different styles" that go to the same level/point in the list.

Exercise for the Interested:

Make a "Book" with each chapter, and the prolog, and the epilog in separate sub documents. The linkage thing is a mess, it is hard to move "the pile of files" around especially if you want to use subdirectories (etc). If you have a custom style in the master document style list you have to _USE_ it in the master document if you want it to be pushed into the created sub-documents. Once the sub-documents are created it is a royal pain (read effectively impossible, or "supremely hidden feature required") to update those styles in those sub documents if you change that style.

Exercise for the Interested:

Put three separate "outlines" into one ODF Document. In ODF the outline is a function of the style headers, they only exist as implications of structure instead of first class abstractions. This is largely the fault of Microsoft Word, since the Word folks totally messed this up when they supplanted WordPerfect (which did this inset outline/object sort of thing right).

ODF was, IMHO, poisoned by the slavish attempt by someone trying to make a Word killer instead of a "good word processor."

And there are stacks more of these issues.

And all that said, I *STILL* use ODF (Open Office etc) because I CATEGORICALLY REFUSE to _RENT_ the right to access my own work from a third party. Microsoft has plainly stated that such rental model is their intended business plan, which makes them a non-starter.

In my opinion, having used both Word and OpenOffice for years; and having used Word Perfect and wordstar before them, ODF is a "workman like effort" to create a document format suitable for "normal business purposes". There is a reason that the legal profession never moved over to Word, and they likewise will not move to ODF, when you need to get to a tightly proscribed document format, both Word and ODF have a "you can't get there from here" fundamental limitation. Both formats simply refuse to represent some things because the designers "know" that a different format is better. Neither ODF nor Word has any allowances for _art_, professional or poetical.

So, governments should use ODF because it is "no worse" than Word in terms of the ability to represent the documents it can represent, and given that congruence, the shorter, 100% open standard is, or should be, a hard minimum requirements.

In terms of ODF being the be-all and end-all of document representation, I'd have to say "hardly!" I looked into the OpenOffice code base a while back to see if adding/changing the format to allow for "a book" would be reasonable. It didn't appear to be. Too many of the original StarOffice assumptions about document structure seemed pathologically uninspired. It was like looking at a big pile of Visual Basic. Everything in the standard is way too global, nothing "nests organically" it all nests pedagogically. (Everything is done with styles and styles are not additive in the proper sense. That is, you can base a style on another particular style, but you can't make styles based on the content of an enclosing style. You can put character styles inside paragraph styles, but if you have four different paragraph styles you want to achieve, you have to define four separate paragraph styles instead of being able to do [A] [B] [A+B] and [] by just defining [A] and [B] and applying them selectively to some global [].)

ASIDE: please don't yammer about bold and underline (etc) being additive within a paragraph. This is pedagogically achieved by having paragraph styles and character styles, which is different than being able to define one paragraph style as the sum of two others (etc).

So like I said: Workmanlike, but no art.

output, at most (1, Interesting)

Anonymous Coward | more than 7 years ago | (#18132934)

HTML/CSS is at most only an output format, i.e. one uses it as the final presentation format, like PDF or ps. To actually write and edit something (even through some GUI), then save, reload and make significant changes is absolutely horrible with it. This was supposed to get better when CSS was introduced, but somehow the format specification failed miserably (IMHO, of course).

I'm not a fan of the two mentioned formats either, way too much bloat. somehow that seems to be normal with xml based formats (but that's probably just a pet peeve of mine).

edxwelch (600979) | more than 7 years ago | (#18133054)

He wants HTML/CSS documents? Isn't this what Google docs do?
Anyways sounds like a good idea to me. I often have to share documents and I don't like to have to force people to install a specific application just to read them.

Slashdot: News for Nerds

Life is a whim of several billion cells to be you for a while.

Need an Account?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

• b
• i
• p
• br
• a
• ol
• ul
• li
• dl
• dt
• dd
• em
• strong
• tt
• blockquote
• div
• quote
• ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>