ODF and Generic Change Tracking: part II, styles.

So now abiword can save and load ODF files with improved generic tracked changes to styles. These style changes might be nested, and the window that a style is applied to might shift over revisions. The below video demonstrates the scenario in example 6.4.2 of the generic track changes proposal that is being considered by the Advanced Document Collaboration OASIS ODF Technical subcommittee.

The actual serialization to ODF is along the lines of my proposed output but also using the ac:change stack to avoid unnecessary nesting as has been mentioned that OpenOffice might produce and consume if the generic proposal were to be chosen by the oasis subcommittee.

ODT Change Tracking part 2: Example 6.4.2 from Ben Martin on Vimeo.

Libferris for Fedora 14

Long story short, I decided to update to F14 on the desktop to get easy access to qt4.7 for a project. During that update I rebuilt libferris (of course) and noticed a not so subtle bug in boost 1.44 that comes with f14. See my filed bug 694448 for full details, but basically it stops boost::serialization from reading binary boost archives from files generated with f13's boost. To get around this, the build of ferris includes some more smarts in fallback to the backup text archive.

Lucky for me, in the old days I wanted to copy some *boost files to the maemo platform, and not being 64bit on the target binary archives are not expected to work, so I already had libferris writing plain text too when updates were made. So on f14 things continue to work, and 1.5.4 of libferris onward have more graceful automatic fallbacks for cases where the binary archive fails when it really shouldn't.

You might see this bug if you use semantic smush sets, etagere (tagging), and a few other libferris features with ferris 1.5.3 or less and move to a boost in the 1.42-1.44 range.

Given that F15 should be out soonish, and it seems it will come with boost 1.46, I'm not sure backporting boost::serialization fixes is really on anyone's top ten.

ODF and Generic Change Tracking

The OASIS group who are responsible for things like the Open Document Format (ODF) format are throwing around how to improve how change tracking information is to be contained in future versions of ODF. I've hacked some support for the "generic" change tracking proposal into Abiword in a git branch, and Ganesh Paramasivam has been working to make Calligra and KOffice support this too.

I thought a little bit of a look at how documents move between suites was in order. Obviously, these are really trivial changes. The larger use cases screem out for an automated system to test them, so that regressions can be caught and other office suites added over time if they choose to support this method of change tracking.

So, without further (or less) ado, the below video shows a document created in KOffice and bounced through a temporary file to abiword and inspected. Apologies for the delays in the first video, I've sorted that issue of frame dups out for future shows.

2011 April 9: KOffice and Abiword with Generic Change Tracking 1of2 from Ben Martin on Vimeo.

In the second video I make some changes in abiword and send those back to KOffice. In the process I found a few little issues which I've committed some updates to the abiword git repo to help with.

2011 April 9: KOffice and Abiword with Generic Change Tracking 2of2 from Ben Martin on Vimeo.

These videos where created with recordmydesktop, transcoded with mencode for 720 playback (mainly getting the video codec how vimeo wants to see it), and uploaded with ferriscp foo.avi vimeo://upload.

Abiword with ODT and Generic Track Changes

I've been hacking support for the proposed generic track changes for ODF into abiword recently. This means that you can generate and store documents with many revisions and see who added/deleted and modified what in which revision over time. Kind of handy for sending your professor the latest design for your perpetual motion machine and being able to see where they think your design might be too optimistic ;)

Anyway, both the branch of abiword and a test suite are up on github to allow anyone to grab it, prod it in the guts, and see how things might operate. Be aware that this is a work in progress right now, and I might commit stuff which is still a work in progress.

The code is at
https://github.com/monkeyiq/odf-2011-track-changes-git-svn
The test suite is at
https://github.com/monkeyiq/odf-2011-track-changes-tests

The following instructions will build abiword from the change tracking code on github. The build will install into /tmp and will not interfere with an abiword which is installed from your Linux distribution's package system. Both abiword builds will be available to you.

$ mkdir tmp
$ cd ./tmp
$ git clone https://github.com/monkeyiq/odf-2011-track-changes-git-svn
$ cd ./odf-2011-track-changes-git-svn
$ ./autogen.sh
$ ./configure --enable-debug \
--enable-collab-backend-service \
--enable-clipart \
--enable-templates \
--prefix=/tmp/abiword-install-odfct \
--enable-plugins="collab"
$ time nice make -j5
$ make install
$ /tmp/abiword-install-odfct/bin/abiword

The download can be done in reasonable time over ADSL, on an Intel Q6600 the make took about 4 minutes. You might like to adjust the -j on the make line to suit your core count. Notice that since everything is installed into /tmp you don't have to run the install as root either. You will get debugging output in the console when using abiword built this way, but that's what you want when running dev code right?

Starting to use change tracking is really easy now too. Though I need to convince somebody who can create clipart to make new icons for revision handling, so the arrow in the below points to the main toolbar icon you want to know about. The icon directly to the right of it will let you select a revision to see from a list.



At first, the additional icons to the right of will not be visible to you as they are only useful when you are using track changes. Each time you click the icon with the arrow pointed at it, abiword will ask to to name a new revision. This makes it nice and simple to create a 5-10 revision test document to play with ODT and Change tracking. Note that abiword can save the change tracking information in it's native abw format as well as ODT. In fact, that is what the core of the test suite linked above does; convert between these formats and make sure that nothing is lost in translations. This way you get to know that abiword can write *and* read back its ODT files without loosing precious information.

"The desktop" and singularity (also scanning and ferris)

While I normally don't waffle on about higher level touchy feely sorts of things, a recent acquisition of a new scanner prompted my mind to wander through those neurological paths. I think it's fair to say that many folks don't run just one, but many desktops these days. And no, this is not about KDE vs GNOME vs emacs as your desktop, but rather that a whole KDE4 session is happening on another (virtual) machine which is brought across to the normal "main" desktop.

This gives me many apps running on many machines and also proxy X sessions and X-VNC sessions in windows (which normally have an embedded panel et al). A take away idea I had here was why when I have Abiword in the menus is there not an offer to run it on server-Y which I have an ssh key for instead of the local host? Or to bring xpra into the mix there as well. Sure, this is likely not an idea that folks who only own a single machine or laptop will like, but that demographic is surely shrinking fast. Add in nepomuk for tracking this and if I run amarok on furryshark7 most of the time then surely that can become the default host for it's icon rather than localhost.

The scanner idea was simple, a USB scanner, a USB hub to attach it to the host through and a handful of USB sticks. Each stick has a profile (username, colour, dpi etc) and to scan just put the document into the scanner and drop in the usb stick for a moment. Then the host knows the parameters and can put the file into a user specific directory on an intranet share so only the document holder can actually see the scanned version. Privacy and convenience, a rare thing!

Of course now that I have a scanner which doesn't suck, libferris will be getting sane support so I can "cp" documents right from the scanner to the filesystem or web...

cp sane://my-scanner-model/600dpi/colour/adf1.jpg flickr://me/upload

And the reason files are numbered is so a single copy can grab 30 documents from the ADF with a normal copy syntax. In practice, adf2 and adf1 both just scan the next piece of physical paper and give you it encoded in an appropriate manner (jpg for example). The fun part will be smoothing over a paper jam at document 7 of 16.

sync && umount blog://

From Canon CR2 Raw files to the Web

A potentially interesting artefact of me playing around with a Canon DSLR is that libferris now has some initial support for CR2 "raw" files. Complements of course go to the dcraw library and tools for the heavy lifting. The upshot is that ferriscp ~/cam/foo.CR2 flickr://me/upload now works as expected. Once I update my maemo build, this should also let me use an n900 with 3G to upload from RAW while on the move.

I need to include stuff for ICC profiles and the like but at least the Web services get what they expect and everything runs smoothly, and it will for you too next release (TM). I really should look into mounting the kipi plugins as a filesystem sometime, they offer some awesome Web import/export functionality, ripe for a filesystem I tell's ya.

I still need to add "rgba-32bpp" metadata support for CR2 files. As you can imagine from the name, if you read this metadata for a jpeg, png or other supported image file, libferris decodes the image to 32 bit RGBA byte values for you. It might also be interesting to create another "file as filesystem" design where a bunch of virtual files are offered to see the small thumbnail, the roughly 1080p sized thumbnail or the ICC corrected rendering of the CR2 and others. Such virtual files are really handy for drag and drop to other filesystems ;)

I might hunt around for some Nikon raw files to add support for those too at some point. Though there is nothing like having a camera generating files to make you want to make your software support those files.

Talking: RDF and Office Documents

I should be giving a talk about RDF and ODF next saturday (8th jan) at Humbug in Brissie. The challenge is that work is reasonably embryonic in the area, but there are already useful things that can be done like drag and drop of contact and calendar information to/from ODF files. As its a technical meetup I'll be going into the range stuff and how to link semantics to document text. Sorry for the brief post, but hopefully you see it and come along if you want to bounce richer information around in ODF files between OpenOffice, Calligra, and Abiword.