Slashdot Mirror

I mean if they just want a conversion system then use docvert software... but OOo isn't web software.

So it seems that it's a publishing cycle question. You should have a source document with placeholders that some later process replaces with code snippets. Your schemas could have foreign nodes that denote placeholder Ids, for to map them up.

You could use Docvert which lets you make XML Pipelines from content and build plugins and conversion stages, that way you could replace placeholders from any of your schemas. It generates HTML and DocBook so you could then convert that to PDF or whatever.

Then what.... well it's in a malleable format so you can move it around between formats (Eg, with Docvert) so you could put it into HTML or DocBook or something like that.

The guy who first responded to you is correct but perhaps overly critical of ODF while being overly praising of the .DOC format for no given technical reason.

Firstly, the file format is typically parsed into an internal RAM format. The file format only has effect when saving and openning, and even for 1000 pages in OOo we're talking less than a second (typically it's less) and this is nothing compared to the processing of any Office Suite.

ODF consists of a zip file containing content.xml, styles.xml, meta.xml, and a directory full of binaries like images. Editing one of these means opening these 3 files and parsing them, which was the easily understood complaint.

The alternative was a binary standard-width field approach as taken by MS .DOC. You can save a binary dump of the format (as early version of Word did) and save/open it quickly. You tend to acquire format cruft over time however because the format isn't easy for programmers to see mistakes in, which is why .DOC files are often larger than comparative ODF files. Parsing this cruft is difficult.

Now Microsoft are moving to XML too. Their patents were around single xml files with base64 encoding of binaries. I doubt if they'd use this in Word but you get the idea that processing/disk speed is meaning we can move to more coherent file formats. Abiword's .abw was always XML. Everyone is moving word processing formats to XML.

So the speed argument given to ODF applies to all modern word processor formats. Infact it was started by Microsoft in Massechusetts (sp?) to associate the speed of OOo with the ODF format and it's all FUD.

One of the most important issues around ODF is that server-software can process it without the overhead of a word processor. The same can't be said of current .DOC. The integration of ODF Converters means that lean libraries can convert the format faster, so as you can see the format means speed in many situations.

Try docvert.org -- it'll convert MSWord to HTML. Typically they shouldn't be making CSS for each page anyway.

My software is working on the presentation engine part -- from MSWord/OpenDocument to HTML or DocBook or RSS. It's called Docvert.

Hmmm... hadn't heard of Xena before. It seems like similar software to mine, see http://docvert.org although it's trying to do an xml pipeline and convert to xml/html. I'm from New Zealand, btw.