OpenDocument got a lot of publicity lately. StarOffice 8 and OpenOffice.org 2.0 finally arrived, and all the other makers of office suites (with the notable exception of Microsoft) have started implementing the new standard into their programs. Massachusetts recently decided to use OpenDocument as the standard file format, effectively locking out MS Office as soon as January 1st, 2007. Other countries are on their way to do the same. Also, OpenDocument recently got submitted to become an ISO standard.
Why support OpenDocument in browsers, you ask? In my opinion, rendering capabilities for OpenDocument are a logical complement to nowadays HTML-rendering. Just imagine you could write a small text, spreadsheet or presentation and put it on your website without changing anything. “Write once, run everywhere”, they say (about Java, admittedly). No need to worry about the formatting – your browser of choice renders the document perfectly fine. This would solve a lot of common problems and simplify the process of web publishing significantly. Let’s have a look at the options we have right now:
- Put the document directly on the web;
- Export to PDF;
- Export to HTML.
The first option is really ugly: I don’t really want to see MS Office files offered for download. Not everyone has MS Office, as it is pretty expensive and doesn’t run on any platform except for Windows and OS X. Plus, there is virtually no browser integration.
The second option is quite good. PDF is a well-known standard. Still, it has some drawbacks: your visitors still need the PDF-plugin installed on their machine. Also, there is no way to edit a PDF-file. This is fine and most of the time you will probably not want people to edit your files. But it still may be possible that you want to publish a document that others can not only view but also download and edit. Also, the exporting of the file to a new format is basically just extra work that should not be necessary.
Exporting to HTML: this is probably the best way to make your documents “web-ready”. The big drawback is that you lose (most of) the formatting of your document. Also, if you want to work with that file later again, you will probably not pick the HTML version but the original (.doc), edit this one and export to HTML again. Again, exporting the file is redundant work.
Now imagine the advantages of OpenDocument: it would be instantly possible for anyone to create web-ready documents. The formatting would be consistent. No problems with different browsers. Also, OpenOffice.org Writer, Calc, Abiword, Gnumeric, or the KOffice suite (just to name a few) are much better tools to create documents, spreadsheets and presentations than, let’s say, Dreamweaver.
Also, I imagine that implementing OpenDocument rendering capabilities into browsers should be fairly easy: OpenDocument is a well-defined XML-standard. After all, browser programmers have a long history of wrestling with “HTML-soup”. Today, browsers render almost everything that calls itself “HTML”, including dozens of legacy tags introduced by Netscape 1-4 and Internet Explorer 1-5. It should be fairly easy to implement a completely new, well-formed, 100%-correct XML standard.
I know that there is already a possibility to render OpenDocument files on Mozilla/Firefox: there is a plugin in OpenOffice.org (it can be found under “Extras” – “Options” – “Internet” – “Mozilla Plug-In”). But this is not the solution that I envision: in my opinion browsers should be able to render OpenDocument XML just as they do HTML right now. OpenDocument could then become a very much appreciated supplement to HTML. “The” format for longer texts, spreadsheets and presentations. Of course, this would not really work as long as Internet Explorer does not support OpenDocument. But eventually, Microsoft may be forced to support OpenDocument sooner or later. Let’s hope the best. Lots of cool possibilities ahead!
About the author:
Christian Paratschek, 29, works as Webdesigner and IT-Professional in Vienna, Austria.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
In my experience, when exporting to html, you don’t lose your formatting; you get your formatting so fubarred nothing can make it look decent after…
The only thing I’ve seen export to html right is latex, and I know we don’t all use latex!
And even that requires certain rules in your markup for it to export right!
Latex is so sexy …
Unf.
Latex is so sexy
So you’re a LaTex user poo?
BTW I just looked up your website http://www.tomchu.com on Netcraft it reports your site as running on Linux. If you view the detailed site report it reports it as running on Linux and FreeBSD hosts but never on a Windows host. Please explain. Are you not true to your beliefs or do you just troll for the fun of it. Are you going to change your hosting provider?
Wow. How are you any less of a troll?
Wow. How are you any less of a troll?
No, I was feeding the troll I know you shouldn’t do it but sometimes it is irresistable.
Secondly and more seriously, if a regular poster behaves in a way that demonstrates consistent hypocrisy and double standards and one discovers evidence to suppot this, then one has a moral responsibility to bring to the forums attention. So I repeat myself:
Linux Is Poo I just looked up your website http://www.tomchu.com on Netcraft it reports your site as running on Linux. If you view the detailed site report it reports it as running on Linux and FreeBSD hosts but never on a Windows host. Please explain. Are you not true to your beliefs or do you just troll for the fun of it. Are you going to change your hosting provider?
Edited 2005-11-17 12:40
Why would Poo answer to scum ?
Yeah latex is cool – dunno what you’re smoken
Anyway, the article forgot one possibility i often times use – export to both doc and odt.
Thanks Christian for the ephiphany I experienced reading your article. A while back, there was an OSNews blurb about how Sun was touting ODF would tranform the Internet. I could see how it would provide many things, but transform the Internet was not one of them.
You very clearly explain why that makes sense and I am very excited about this possiblity. Great job.
I see a lot of room for innovation here … I’m checking out this plugin & openoffice.org v2 now.
I wonder if Google is going to help rolling the ODF engines from OOo into Firefox. That would be so powerful. MS basically has that with Office and IE.
“Also, there is no way to edit a PDF-file.”
?? I like OpenDocument, but you said that there is no way to edit a PDF file!
Ever heard of Acrobat.. Ofcourse it’s not free, you have to buy the product from Adobe..
A common misconception about Acrobat is that it lets you directly alter text in a PDF file. This really isn’t true. I think the Pro version might give you options for exporting a PDF into DOC format, but you can’t necessarily do live, direct editing on the file, AFAIK.
I have something to say here.
PDF is a presentational format. Therefore, it’s not suited to be edited (ever tried to edit some text in Acrobat? it doesn’t reflow, so you get your text screwed up).
It’s a very good format, to publish things. The way you created it (the way it looks), will look on every platform, today or in 15 yrs.
But it’s not suitable for being edited. Even though PDFs can be tagged (so the PDF viewer know that all those lines of text indeed belong to the same paragraph), text reflow (and re-layout) can (will) break things.
Just my .02
NachoKB
Hundreds of dollars, frequent (costly) new versions, and none for Linux (only Windoze and Mac).
Though you are right, that Acrobat costs quite a lot and is only available for some platforms, that does not make the statement “PDFs cannot be edited” any less false.
Or one could do convert to PostScript, edit the PostScript file (can be done even by hand), convert to PDF || print.
Export to xsl and make templates 🙂
“Export to xsl and make templates
”
Me izz Mr. Wise Guy tonight… XSL (resp. XSLT) is a language in which you can write templates to transform XML code – so no need to “export to XSL”
Okay, here’s the serious part of my answer: Doesn’t make sense – does it? Using XSL you can transform the XML Code of the OpenDocument format into something else. But you’d still need some new capability in the browser so that “something else”(tm) is displayed with the layout etc. of the original file.
Edited 2005-11-16 19:42
Ok, I wrote my comment really fast because the boss was coming 😉
Seriously, I think people focus too much on the form of the document, and not enough about its content.
An OpenDocument should generate an XSL template for PDF generation (XSLFO, for example) or HTML generation, along with the generated document (or there could be 2 standard XSL templates for this).
This way, an exported document from OpenDocument to XML could be converted directly into browsers that support XSL Transformations.
Does it sound better now?
I think you, like me, misunderstood what he meant by XSL, probably XSL-FO/XSL:FO and not XSLT. See my post for link.
Some while ago i was thinking about a very evil plan about this topic:
I think the perfect content manager(tm) should store its pages in an as rich as possible form, possibly xml, and now the better/cooler is OpenDocument, and should transform the pages with xsl server-side (obviously with an aggressive caching of the generated documents to not eat too much cpu).
And then when the user access the site, (s)he can specify the preferred format, for example:
-www.ubercoolsite.com/index.html will be the default, normal html page
-www.ubercoolsite.com/index.odt will be opendocument and so on
in this way there will be a consistent way to generate html, opendocument, pdf and tons of different formatted documents, with a wery little effort.
… possible to export OpenDocument to HTML without losing a lot.
This is possible for other fileformats and ofcourse also for ODF.
Besides that… There is no reason to export ODF to HTML. All you need is a PDF-like plugin for ODF. Or to put it another way: An ODF-Viewer plugin.
You don’t export PDF to HTML when viewing PDF-files in FireFox. Nor should it be nescessary to export ODF to HTML.
We “just” need the plugin-viewer
Me again.
As I posted in [1], there’s a big difference between PDF and ODF, as I see them. On one hand, PDF is a presentational format, meaning it brings the highest output (visually) fidelity possible, at the expense of semantics (for example, it doesn’t know it’s a title, it just knows it’s bold, big and with font xxx); on the other, ODF aims to preserve documents structurally (XML is perfect for that), at the expense of output fidelity (I’ve known some people which freaked out when Word changed +0.01% kerning or something like that under different systems, so a 100+ pages document had a few more lines, because of reflow; of course, that reflow broke their pixel-aligned layout they carefully crafted on a WYSIWYG view… pity).
So, a PDF-viewer plugin has to know how to draw exactly what the file says. On the other hand, an ODF-viewer plugin should generate a layout, and it probably will be different than that of the app which created it. This alone is not bad, but…
Furthermore, as the ODF file preserves structure information (practically speaking a DOM), it makes sense to leverage all of the browser technologies (stylesheets, scripting, anything else). It’s just that ODF and HTML are somewhat alike.
So, with ODF you got a document, while with PDF you got a snapshot of it.
[1] http://osnews.com/read_thread.php?news_id=12685&comment_id=60912
Well, I’d still prefer a plug-in solution, but yeah.. you’re right, but still.. I’d like to stick with HTML as the (primary) format for web content.
But that’s probably just silly me
Not just you. Me too (sorry if I said otherwise).
I don’t want yet another standard. There are two arguments for the contrary
1- W3C is really underperforming… its standard are obsolete even before they get released, and are a mess to implement (even understand; I mean, why on earth is it so damn difficult to center something, horizontally or vertically, with HTML/CSS? what about CSS3? isn’t it already 3+ yrs obsolete?)
2- there’s information inside the ODF which would be a shame to not get exposed to the rest of the browser (structure blablabla).
Anyways, I prefer a slow, ineffective standards body than one another which accepts (and even enacts) patented standards.
KB
That’s exactly a kind of vision Gary Edwards had in his article “OpenOffice.org 2.0 leaping over legacy lockdown with clean XML”, i recommend reading it:
http://madpenguin.org/cms/html/62/5304.html
There have been many rich formats before. Why didn’t the browser makers rush to display them, but overcome all kinds of problems with poor HTML, Javascript, DHTML and such things?
Maybe now with broadband Internet more available, people will be ready to use rich documents?
You wrote about plugins, and I think it’s up to the OOo developers to make plugins for different browsers. That will speed the things.
I remember the old days when MS also created things PowerPoint viewers for those who didn’t have MS Office.
Wouldn’t it just be better to support XSL-FO? http://www.w3schools.com/xslfo/xslfo_intro.asp IIRC it’s supposed be W3C’s XML version of PDF. It it supposed to be powerful enoguh for typesetting books so I assume it should be good enough for Word/ODF. And since ODF is also XML based all that is needed should be an XSLT transformation from one to the other (I believe that there are compilers that will take an XSLT and spit out the C code to do it to improve performance). It seems more logical to stay within W3C’s suite of tools.
Apparently Apache’s FOP project is an open-source XSL:FO processor.. perhaps this could be used as a base. http://xmlgraphics.apache.org/fop/
—
Edit: It now seems to me that XSL-FO is the XSL as previous post mentions. I originally understood it as meaning just making a ODF -> XHTML XSLT
Edited 2005-11-16 19:45
Exactly. XSL-FO is the way to go.
XSL-Fo is a ‘read-only’ format. You have to go through a ‘compilation’ stage (eg with FOP) in order to get something viewable.
XSL-Fo is designed to be a print medium, ie to allow publishers to store their books in an ‘intermediate’ format that can be exported to a printable binary file (pdf, ps etc)
In short, XSL-Fo is _not_ going to replace opendoc any time soon.
OTOH, it would be nice to be able to easily convert between opendoc and XSL-Fo – you could do this with an XSL stylesheet.
–Robin
I started reading thinking that it would be a nice idea, but then it struck me: If the “biggest” desktop browsers supported ODF rendering directly, many pages could become simply a collection of ODF files, odf replacing normal html, and if that doesn’t really matter for desktops (as they would have support for seeing them), for pdas, smartphones and the like it would cut them off. Of course they could have odf rendering too, but we have html for a reason, and if we start having other page formats it’s going to make the internet an even more confusing mass of information.
Just my 2 (euro) cents.
There are already several plugins to show rich formats in the browser, but they’re not replacing HTML, nor XML on the websites.
So I don’t think you have to worry. Supporting ODF in the browser is not different than supporting DOC,PPT,RTF and whatever. It’s just another plug-in.
There are already several plugins to show rich formats in the browser, but they’re not replacing HTML, nor XML on the websites.
<p>It doesn’t need to replace XML. ODF is a form of XML, so someone would just need to create a means of rendering that XML in browsers.
<p>This could be done a few different ways, but it seems to me that the guy has a point. We’ve made browsers to render XML (including HTML). Now, we just have another form of XML. Why not make it so browsers can render that, too?
XML files really aren’t much more than simple text files. Some binary data could be included with XML such as pictures or sound files. ODF is pretty much a JAR compressed XML with formatting.
ODF isn’t common on the internet now. If it did become common, by that time portable internet devices should have the capability of rendering the files.
What about fonts? Let’s not forget that just creating a doc that looks great on your workstation may look horrible if someone does not have your exotic fonts. That’s one of the benefits of PDF. I don’t think ODF deals with fonts. Correct me if I’m wrong.
How does xsl-fo stand in this regard?
I think it shouldn’t support that. At least for now.
Again, PDF is presentational, while ODF is structural.
BTW, ODF and HTML certainly will overlap. At first thought, that’s a bad thing (stop relying on an inefficient standards body to start relying on another, whose efficiency is not yet known, but which accepts patented standards mmmmmmmmmmm bad idea), but on the other hand, HTML is a mess, and W3C only knows how to create confusion. Perhaps THIS time we could get it right? Nah, I’m dreaming…
Whatever…
NachoKB
You are right, if you don’t have the fonts on your computer, you won’t get the same result. On Windows Times New Roman is the default font in OOo, so Windows users usually use this font. If a Linux user opens such documents, the font is translated to another one. Therefore, this whole idea is not applicable.
same thing happens to webpages allready and i dont see much complaining happening from the penguins and daemons…
mostly its a questions of what your used to, and where the files come from…
files made by openoffice on windows and viewed in firefox on windows will see no diffrence. other combos tho may produce other results.
this however is more with copyrighted fonts then anything else
same thing happens to webpages allready and i dont see much complaining happening from the penguins and daemons…
Webpages are not page-oriented, so there is no problem, if the fonts don’t match. In OOo documents it might happen that the page structure (text/objects moving to the next/previous page) will be changed if another font is used. Worse if you use manual page breaks in your document.
this should rarely happen as long as both the original font and the replacement font is mono-space, something thats the best to use if you want to ensure correct placement of items.
First off, HTML, when used with CSS, lets you specify multiple fonts, in order of preference, for a piece of text. This means you can ensure the appearance on a variety of platforms.
Secondly, HTML is not page orientated, and when designed with modern techniques allows for fluid page layouts, so it can deal with different fonts and font-sizes (not everyone can see as well as you, you know).
This means good HTML/CSS will reflect the designers wishes on all platforms (note: market-share for Apple is around 10%, market share for Linux is around 10%, market share for Windows is around 85-95%, but as the first two figures show, it’s not used all the time). Further, HTML/CSS offers far more aids for people with disabilities: it is a scandal that the web, which should have been the greatest gift ever to the blind and those with chronic eye difficulties, has remaining broadly off-limits.
At the end of the day, if you just want your users to read something, instead of entirely re-format it, HTML/CSS is superior, and that’s why it’s the language that web uses for publication, and rightly so.
opendocument has the concept of paging as does pdf. browsers don’t do this natively because web pages themseves aren’t meant to be printed. i’m sure one could implement your idea but you would lose all the paging of the original document (i imagine). I think you completely ignored a lot of issues when envisionning this.
CSS has the contept of printing built in to its @print media support, paging included.
I’ve looked into print formatting for css and it does help printing on the web but doesn’t help us define a printable document. I don’t think there are any mention of page breaks etc.
Regardless, extend my argument to other features of opendocument like the spreadsheet, how to diplay multiple work sheets etc…
it just seems to me that these types of non web documents will be handled by specific plugins (how they are handled now).
HTML printing? with CSS cou can define things like pagebreakafter and pagebreakbefore, for an arbitrary element… so better do your homework before FUDding 🙂
The point is, ODF is just XML. OpenOffice interprets this XML one way, and web browsers could be made to interpret the same XML to display in a web browser. It really isn’t far fetched.
In fact, HTML can be set up to display one way on your screen, and to display differently when printed.
Have the exported xhtml separate the content of each page in layers. That way the exported document would be easier to print than in basic html(on and of course, defining the intended size of each layer with css or something)
Basically, the article suggests browsers render ODF documents like they do HTML today.
I don’t like the idea of having to kludge ODF support into the browser I demand instant responsiveness from.
So I think rather than tax the HTML rendering engine, I prefer to just pass the document to an external handler as you won’t be browsing the web through the document anyway.
I can open a browser, surf to Google, and spell check a word in less time than I can do the same in Word or OO.o from my PC. That is sad.
If only my browser was as lightning fast as OO.o I might just have to kill myself.
Edited 2005-11-16 20:36
I like it. If it’s feasible, it boosts the utility value of OpenDoc wonderfully and solidifies the case for OpenDoc over NotOpenDoc ;-). As for implementation, if a browser plugin that provides efficient, transparent support for OpenDoc is feasilble, I’m O.K. with it, but I suspect that native support would be be better. I don’t really hate PDF, but I think Adobe’s browser support is poor. Personally, I don’t like to view .pdf’s on the web. While Acrobat works well enough as a vehicle for publishing documents, it makes a slow, klunky appendage to the web. Acrobat docs are really a different animal than web docs. If OpenDoc cannot be smoothly integrated into the web such that OpenDoc documents are web documents, it, unfortunately, will have the same problems.
Edited for grammar.
Edited 2005-11-16 20:38
I think the OpenDocument format will open a bright new window of possibilities.
Take content management systems for example. Today you have all these dirty hacks to support rich text format editing in your browser (and it’s a hassle to import documents properly).
With the ODF format you could just easily upload your document and it would be automatically converted to XHTML using XSL templates. Need to edit the text? Download the document (could be converted from XHTML back to ODF on the fly), edit it and upload it again. In combination with WebDAV it would be even easier. And you wouldn’t need to upload the images seperately. You could just embed them in your document.
The guy has no idea of what he’s talking about.
Point 1: It is possible to edit PDFs, there just aren’t many PDF editors out there (KWord currently features basic PDF editing support)
Point 2: Quote: “I imagine that implementing OpenDocument rendering capabilities into browsers should be fairly easy”. Nonsense. Web-Browsers are built around an entirely different paradigm. Building in support would be an enormous challenge, the disconnect between the XML in OpenDocument and XHTML is huge; it’s not just a matter of lashing together a couple of XSLT stylesheets.
Point 3: The web is for viewing documents. If you want to distribute documents to other people for editing, fair enough, use OpenDocument (or Word, or RTF). But if you just want people to read your documents, HTML is far better: it’s more lightweight, saving bandwidth; a multitude of accessibility tools, from text-mode browsers to screen-readers already exist for it; and a multitude of applications already support it.
Point 4: It is perfectly possible to export to HTML without losing any significant graphical detail. It is also possible to paste that HTML into a document and retain most of the formatting. The only problem is that HTML itself is not immediately editable, but the web is about publishing things that people can read, not providing documents that they can edit and send back.
The biggest problem is an internal contradiction in the article. The author is trying to make an argument for “Why Browsers Should Be Able to Display OpenDocument”, but then goes on to say that “OpenOffice.org Writer, Calc, Abiword, Gnumeric, or the KOffice suite (just to name a few) are much better tools to create documents”.
The crux of the matter, as I said in point 4, is that the web is a publishing medium: authors make content available for others to read, not to perpetually edit. If you want users to be able to edit documents, then they should surely use editors like OO.o Writer to do that. Further, things like GMail, Blogger and Wikipedia show that where a certain level of editing is required, HTML is up to the job. Ultimately it’s a format just like OpenDocument, but optimised for publication, not editing.
ad Point 1: fair enough, it is possible to edit PDF files with some tools, but it’s a lot easier to download, open and edit an OpenDoc file.
ad Point 2: really, i don’t know how difficult it is to build rendering capabilities for OpenDocument into browsers. maybe you know better, maybe an expert on this matter should clear this up.
ad Point 3: “the web is for viewing documents” – i certainly think that statement will not hold true 10 years from now. let’s wait and see.i don’t buy the “lightweight, saving bandwidth” argument: while i know how to write very efficient HTML, i think that OpenDocument files are really small enough to be put on the web. the difference between HTML and ODF doesn’t eat nearly as much bandwith as your next flash ad. also, accessibility tools could be used for ODF easy enough: it’s XML, it’s human readable plain text after all.
ad Point 4: one of my main points was that this importing/exporting thing is useless. it’s just an additional step we don’t need. ODF on the web could also save the problem with printing we nowadays have on the web: that most of the webdesigners don’t know how to use print stylesheets and a lot of documents look like crap when you send them to the printer (of course not, when you get a PDF).
The biggest problem is an internal contradiction in the article. The author is trying to make an argument for “Why Browsers Should Be Able to Display OpenDocument”, but then goes on to say that “OpenOffice.org Writer, Calc, Abiword, Gnumeric, or the KOffice suite (just to name a few) are much better tools to create documents”.
i said: “better than dreamweaver”. you certainly don’t want to tell me that you would write your next spreadsheet with table, tr and td tags in a webeditor/text editor when you can use OpenOffice Calc/Excel/Gnumeric. use the right tool for the job!
and as soon as you’re done, put it on the web. people love their office suites. everybody can use word, excel and powerpoint. who can write html? not even 95% of the people who call themseves “webdesigner”. so let the people use their favourite tools to create documents that are google-friendly, printer-friendly and user-friendly…
regards,
christian
It is possible to edit PDFs
Not always. That depends if the PDF actually has text in it or if it’s image based, which many times, scanned documents are. Also, password protected documents aren’t editable. Many people use PDF not only for formatting but BECAUSE they don’t want the documents edited.
Web-Browsers are built around an entirely different paradigm. Building in support would be an enormous challenge, the disconnect between the XML in OpenDocument and XHTML is huge; it’s not just a matter of lashing together a couple of XSLT stylesheets.
Partly right. Building in standard and consistent support would be a challenge, but it could easily be done. I would bank on Opera being the first to pull it off, like they did with voice support. It is something that a company that controlled their own rendering engine could add client side, the same way that Firefox can parse RSS in a certain manner.
The web is for viewing documents
I hate to argue, but isn’t that awfully narrow-minded? Because you want to keep things status quo, no one should innovate or extend? Yikes.
Point 4 is solid, I suppose, but also rely on the idea that the web should be a read only playground.
I would bank on Opera being the first to pull it off, like they did with voice support. It is something that a company that controlled their own rendering engine could add client side …
IMHO a corporation (e.g. Novell, Sun or IBM) will sponsor/ develop a Firefox extension (using the XTF technology) in a similar way it was done with the XFORMS extension
BryanFeeney: Nuff ‘Said
Rest of my comment has been removed, as I took to long to write it, and Feeney made it worthless
Edited 2005-11-16 21:17
If you want to edit docs, install OOo or an other ODF-ready office suite. No need to pack those 80 MB OOo into a browser plugin.
For docs not meant for editing, HTML and PDF do a much better job than any office document format will ever do. Yes, PDF needs a Acrobat or another viewer, but it’s more realistic to expect that than a full office suite.
“Not everyone has MS Office, as it is pretty expensive and doesn’t run on any platform except for Windows and OS X.”
Only a linux geek would write such a thing without laughing out loud. 😉
…to develop such an extension (in particular for gecko based browsers) since ODF is based on standards like zip, html, css, xsl-fo, svg, smil, xforms or mathml which are (in large part) already implemented in the latest gecko release.
Would be much easier to add browser capabilities
to an Opendoc app than the other way.
Anyway, view only code must be scanted first.
Sure, but FF could a powerful vehicle (with 10+ % market share) to promote ODF. Moreover I don’t want to download a “slow 76 MB browser” (OOo) when I can have a fast 5 MB browser (FF)
Since the major browsers now support both CSS and in-browser XSLT, you can already display ODF directly in them. You just need a stylesheet (CSS) or XSLT transformation to XHTML. Presumably an office package can format documents in ways that exceed the current capabilities XHTML or CSS, but CSS will develop. Of course, a plugin supporting XSL-FO would allow you to convert directly to PDF for display, as others have noted.
this:
1 renamed zip file.
1 xml based file containing data and markups, like say the cell content of a spreadsheet or the text of a document.
any number of images and other stuff thats embedded into the file. mostly relevant for text documents and presentations.
only problem i can see is stuffing a spreadsheet into a browser window. why? the cells that contain formuals rather then raw data. these have to be calculated by the browsers plugin or similar…
i recall a comparison that have been done on filesizes of the exact same document saved in odf and in ms doc formats. i think the diffrence was something like either 5:1 or 10:1 in favor of the odf format.
Browsers Should Be Able to Display OpenDocument
KDE’s Konqueror can already do that (by embedding the KWord part).
Like it wasn’t hard enough to get browsers to conform to standards!
I’m sure this could be easily accomplished in KDE.
Eg, When using Konqueror, and you vist an OpenDocument file, it will show up, as if you were in Kword – Just by using the appropriate Kpart.
Too Easy.
All MS Office programs, word, visio, excel, ppt, have the plugin for IE to *display only* those docs, and these plugins are very small to download, very easy to install, and are freely available. It would be a shame for OOo’s lacking of this. Is it very hard to implement?
This would be a great way to see more people put their idiotic, overformatted documents online. Something nice about the web is the clean way it’s presented. Anybody ever seen a webpage made in MS Word and exported to HTML? If not, count your lucky stars. Even if the Word->HTML converter does a perfect job (which it sometimes does in new versions), it still looks like a three year old was playing with MS Paint. Most peoples’ ideas of good design practices seem to extend to using light green text on a dark green background and lots of flashing thingies. Frontpage is bad enough. Don’t give people any more excuses for ugliness, and leave web browsers out of it.
I don’t know about other people, but one of the first things I do after installing acrobat is disabling the browser integration. Maybe I’m just weird, but I prefer to use a web browser for browsing the web, a text editor for editing text documents, a pdf reader for opening pdf files, and so on and so forth. I don’t like it when MS Word opens a hyperlink inside of itself instead of launching my web browser and I also don’t like it when word essentially loads in IE if I go to a .doc file. Is it really that cumbersome to have your browser download the file to a temporary folder and launch it with the associated application? Is it really that confusing to have two applications running at the same time? I mean, I’ve seen my mother inadvertantly work on a word document in excel, I would think that would be more confusing than always using the same specialized program to work with the same types of files.
On the other hand, HTML, PDF, Word, ODF, are all just different ways to encode a text document. When browsing the web and reading documents, why should I care what format a document is encoded in? I just want a simple and consistent interface for displaying and navigating any of them.
I agree that separate applications with somewhat different interfaces do make sense though when editing those formats, because they do offer different features.
I guess what matters is your idea of consistancy. Is it more consistant to open everything in one program to view if it’s on the internet and seperate programs to edit or view if its on your computer, or to have different programs launch if you click a document on a webpage. IMHO the latter is more consistant, especially since opening in the browser changes the browser’s appearance, and often displays a slash screen just so you know that you aren’t really using your browser. If document types were visually similar then I might agree with you, but an HTML document usually looks completely different from a text document or a spreadsheet, and text documents, pdf files, and spreadsheets act differently if you try to edit them.
PDF is not meant for editing. It is a low level drawing language. Text strings are left encoded as ASCII within the file; however, trying to do more than changing a word or two is not feasable. You are much better off editing the original and regenerating the PDF. You can more or less think of PDF as being the successor to Postscript.
I know Adobe tries to sell it as some kind of do it all document format, but it’s really just not meant for that.
The entire premise of the web was that documents would remain in a highlevel structural markup and each client would decide on how to render it best to its capabilities. It seams like everyone forgets this.
Arguments pitting HTML(CSS)/ODF/LaTeX vs PDF/Postscript/PCL are silly. Ultimately, when you print the HTML it’s going to wind up as Postscript or PCL anyway. The former is a highlevel structural document format while the later are low level drawing languages.
You can also think of HTML as having a dumb language with a smart interpreter and PDF as having a smart laguage with a dumb interpreter. It’s a lot easier to write a PDF viewer than a web browser.
I hope this clears up the dumb things I always hear people say about PDFs.
The file format is XML… People can choose how these documents should be rendered by using XSL… dah!
XSL-FO is like PDF 1.3 and is purely layout without structure. It doesn’t have tagging which is necessary for ODF and so is unsuitable.
Yes webpages could all become OpenDocument but they could already become all PDF and it hasn’t happened. Also IE wouldn’t support it so HTML will still be the most popular. ODF is a page-based format, and it doesn’t scale so well as HTML. Also there was the contention by the Opera browser company that the XSL-FO spec should disallow online use so all pages don’t become FO… it didn’t happen with PDF or Flash (for the majority of sites).
ODF is a good word processor format. It’s not a structured format like Docbook or LaTeX but it’s not supposed to be, it’s supposed to be a flat list of paragraphs with styles attached.
I don’t know much about the ODF format’s spreadsheets and diagrams. I know that the macros aren’t standardised in the ODF spec.
Mostly I think this is a great idea because we need a trim version of OpenOffice.org, and OpenOffice.org won’t ever be trim. Probabably better to write a client in XUL
konqueror embeds kword. Kword supports opendoc (from next version onwards).
So you may argue anyway you like, but what is suggested is allready a fact of (bleeding-edge) linux desktop life.
KDE is not just a linux desktop
To show a little priview of the file would be easier.
That is something which konquerer and nautilus could be do, because in the ODF-Files are Thumb-nails of the documents.
Indeed, KDE/KOffice can already display OpenDocument files in a browser:
http://www.ntpb.co.uk/koffice/odtinkonq.png
I think this is just plain stupid.
– breaks backwards compatibility
– really bad for accessability
– different designs for different medias – how?
Ok, you say, we don’t need to replace all HTML. But for what use, do we need this then? PDF ist great for publishing read-n-print-only documents. For share documents? There are only very little places for such use and Wikis fit would fit the most of this space today.
So I can’t think, what would be the rest space between HTML and PDF excluding the Wiki space.
This idea is under scrutiny for a long time. It became hotter because of the sudden attention spent on ODF.
See http://qa.openoffice.org/issues/show_bug.cgi?id=22406
Anyone with a login in OpenOffice project is invited to vote for this issue.
Within HTML we’ve got WYSIWYG editors, why not make them proper editors that can have structure?
Your have just rolled out some really nice perspectives
Visioo-Writer is a free OpenOffice.org and OpenDocument file viewer.
The project is to create a multi-operating sytem, multi-language, fast and
simple to use program, for the smallest possible size.
<http://visioo-writer.tuxfamily.org/EN/>
Can we use it like a plug-in?
I want docs to open in their native application. I don’t want PDFs and spreadsheets opening in my browser. You can’t use menus. The area for displaying the doc is too small.
After reading all your comments I came up with two new (cross platform) solutions for displaying Open Document Format (ODF) files in browsers:
1. Create a CSS file to transform ODFs into XHTML for web on the fly.
– Looks like someone has already thought of this: “Apple Developer Connection has a tutorial describing how to render XML in Mozilla using CSS and DOM” http://www.mozillazine.org/talkback.html?article=2503
2. Create an apache plugin that does the transformation before serving (possibly XSLT could help)
Some people mentioned creating an XSLT file to transform ODF files into XSL-FO files (which would be great for typesetting books created in ODF) -looks like Mozilla/Gecko may soon be able to display this without a plug-in. XSL Coming To Mozilla: http://mozillazine.org/talkback.html?article=765
XSL is an umbrella term for 3 standards: XSLT (xml conversion), XSL-FO (page layout), and XPath (node selection).
XSLT is available in IE and Mozilla/Firefox (and maybe even Safari) and is for converting one XML format to another. It’s nothing to do with word processing, although an XML-based word processor would probably use it for conversion.
XSL-FO is not available in any browser and is not a suitable word processor format. I can tell that the people who think it is have not used the format for word processing, and that in the distinctions between high and low level languages they don’t know where word processor formats should be. It’s not suitable, please just trust me on this.
XPath is used in XSLT and is available in browsers.
To make things more muddy, the term XSL is most commonly used to mean XSLT.
Ok, so hopefully I’ve established that I know what I’m talking about.
We need something better than textarea tags, and the current WYSIWYG editors that are being made today out of complex Javascript just isn’t working. They’re trying to be word processors, but each site starts from scratch and and there’s no standardisation (in capability, Eg, spellcheck, tag support, adding alt text to images, metadata, clipboard, etc.
No website editor does this but a word processor does. We’re already making crappy word processors and this would be a positive simplification.
The next question… is HTML enough? Why ODF? …ODF is a higher level language than HTML and is more espressive. ODF contains spreadsheets and other common office formats which HTML does not. ODF is clearly superior and more extensive, but is more difficult to implement.
Regardless I’d like to see Firefox/XUL and Flash (for IE / Safari / Opera) implementations of great word processor editors.
I’m sorry, but I just don’t think this is a good idea.
It makes about as much sense as someone saying “sed, vi, grep, cat, and more are all really useful, think how useful a program that combined all of them into one command would be.”
Yeah, the end result will have a lot of features, but it’s unlikely to gain anything over the way it is now.
Maybe because I am on Macintosh, I find many of the OpenDoc implementations very conservative and clunky at best. This is just to underline there are other alternatives than the three you list, among which Wikis.
You dream of “write a small text, spreadsheet or presentation and put it on your website without changing anything” -well, all wikis go one step further, and now: you do compose your page right in your browser.
And, will you believe, there are even wiki motors that *are compatible with OpenDoc* !
Hervé
Let me quote a fragment of what Richard Stallman once
wrote about not liking MS Word mail:
Receiving Word attachments is bad for you because
they can carry viruses (see
http://www.symantec.com/avcenter/venc/data/acro.html).
Sending Word attachments is bad for you, because a
Word document normally includes hidden information
about the author, enabling those in the know to pry
into the author’s activities (maybe yours). Text
that you think you deleted may still be embarrassingly
present. See
http://news.com.com/2100-7344_3-5170073.html for more
info.
The same goes for OpenOffice documents posted on the
web. Having a web server that does ODF to HTML
conversion on the fly covers the read-only use. The
collaboratve stuff is taken care of by the emerging
tools for dealing with Wikis and Blogs. I don’t
see ODF in browsers fitting in.
Very good article. But the lack of ODF support by Microsoft will not last as long as so many expect.
I think they will be very quick to implement ODF support when it become a mature standard.