After a slow start, hacking on AbiWord-2.6 is picking up. We've all got pretty excited about the One Laptop Per Child program and are focusing on things that would enhance AbiWord for that activity.
Firstly Tomas Frydrych has been hacking away on our basic Unix graphics class to enable us to use the pango library for the various complex scripts employed in places where the OLPC program might be employed. Today he made his work the new default in CVS HEAD and it appears to work extremely well. A great side-effect of this work is that we may be able to make use of the Gtk-Cairo backend to do sub-pixel positioning of text. I would love this as it would finally remove the off-by-one pixel errors of positioning letters within fully-justified text. Using AbiWord would be like having print-preview quality all the time.
I've been hacking on AbiCollab recently. The idea of this feature is allow real-time collaboration on document creation. Claus Schwarm and I wrote about this feature in Gnome-Journal. I've made good progress. We can now serialize document editing and record the editing information to a file. I have also written code to translate the recorded information back into AbiWord commands so that the file reproduces the editing session. With this in place the next task is to connect two AbiWord's together so that the editing information of one session is communicated to the other. My first thought is that the xmpp protocol used by jabber would be employed. There are a number of good reasons for doing this.
1. Jabber works so the protocol must be good.
2. People will want to use an IM client for offline discussions as they work on the document. Might as well be Jabber.
3. There is good reference code in Inkscape 0.43 which I may be able to steal :-) BTW I wonder when the release announcement of 0.43 will be made? It really is an outstanding release which takes inkscape into territory not covered by commercial vector apps.
4. People will need to find a way through firewalls to use this application. If they've already worked out how to do it with Jabber it's one less issue they have to worry about.
Another thing we might do is make our compressed *.zabw file file format the default and work out how we can prevent superfluous properties being exported. The idea of course is to minimize the "disk" space taken up by documents. The *.zabw format really rocks in this department. This blog post occupies 2466 bytes in *.zabw. By comparison the same document in *.odt occupies 9316 bytes, *.doc 24064 bytes and *.rtf takes 5286 bytes.
For some very strange reason I missed the inkscape-0.43 release prominently displayed at: