The Whole is Less than the Sum of the Parts

So the saving powers of the self-proclaimed messiah Re and his holy book are now being doubted even at the primary shrine, with allegiances of the most loyal being switched to a new deity:

… we at the OpenDocument Foundation have been displeased with the direction of ODF development this year. We find that ODF is not the open format with the open process we thought it was or originally intended it to be. … [it] does not adequately respect existing standards and does not address the market’s requirements for a single Universal Document Format with which any and all applications can work on an equal basis. [1]

It escapes me how anyone apart from those uninitiated to the word processing netherworld could have expected anything else from the mighty Re and his high priest. It all feels like an Indiana Jones sequel — I wonder, is the holy grail there to be found, or will we all just have to put up with our mortality?

P.S. If we all ask Santa nicely, we will find a universal file format in our stockings this festive season (if it does not turn up, it will be because were up to no good; Santa, as we all know, does not like that).

AbiWord 2.5.x with the shiny new embedded UI on Sharp Zaurus SL-C1000, running Poky (screenshot courtesy of scap).

(Had to scale the image from 640×480 to 320×240 for the blog; the original capture is here.

One thing that I have wanted since the INdT guys produced the initial Maemo port of AbiWord is a normal (that is, plain gtk-based) version of AbiWord tweaked toward use on embedded devices. Over the past year or so I have been pecking at it, and it is finally coming together in the shape of a bunch of new options that can be passed to the AbiWord configure script:

–enable-embedded: this option results in an alternative user interface that is intended to improve the use of screen real estate:

• The Normal mode becomes the default mode, rulers are hidden, various ‘dead’ space areas around the page are reduced in size or eliminated,

• There is no status bar, and no menu bar, only a simple toolbar, with the main menu accessible via a button on the lef side of the toolbar.

The alternative interface looks something like this:

Apart from the UI-oriented –enable-embedded, there are also three other options that can be used to reduce size of the application:

–disable-printing: removes code and dependencies associated with printing.

–disable-spellcheck: removes code and dependencies associated with spell and grammar checking features.

–disable-exports: when this option is used, symbols are not exported from the executable; this reduces it’s size by about 1/8, but the executable compiled with this option cannot use any plug-ins.

An ipk package of AbiWord built with all of these options is only 1.4MB in size, which I think is pretty amazing. A bitbake recipe to build AbiWord from CVS using OpenEmbedded environment can be found here.

Some insight into how ‘cross-platform’ development works @M$; I felt a bit sorry for the Mac guys, until I read in the update section,

If we had to add support for Open XML to Mac Word 12 without being able to port code from Win Word, the read/write estimates shrinks down to about 8.5 man/years …

That made me really, really laugh; come on, 8.5man/years? I am not surprised nothing from M$ is ever produced on time if it takes 8.5man/years to create an import/export filter from a file format that was tailored to the Word internals, to a file format that was tailored to the Word internals, via (yes, you guessed it) an intermediate file format that was tailored to the Word internals. (Bad news for the OpenDocument though; how could M$ ever manage to support such a complex file format that has no connection with the Word internals whatsoever?)

As I recall, this about half of what it took to add HTML support to Word: 10 or so devs over a release cycle of 2 years.

One less mystery in the Universe: I finally understand why Word HTML is so bloated.

We have been talking about making some changes to the AbiWord piece table for a while now, and so in the past week, I have decided to start some hacking.

There are two separate, and largely orthogonal, issues that impact the perfromance of the PT. The first has to do with the way the pieces are stored — we use a double-linked list, which does not scale well to very large documents. The second has to the with the handling of text attributes and properties; because the attributes are internally represented by strings, we happen to make a large number of calls to strcmp(), and also have to constantly validate pointers that are being passed around. It is the second issue that I have decide to start tackling. Read the rest »

Will need to have a look at this (BSD-licenced) project if it could give us a way to support AbiWord files in Word, or at help with improving our Word importer.