As someone who usually hacks on LibreOffice, external import filters produced by the Document Liberation Project cut both ways: they are great, as they deal with obscure formats and we get them for free, OTOH hacking such code is more complex than the usual LO code. I recently contributed a few patches to libvisio and libodfgen, but before I was able to do actual code changes, I had to set up a number of repositories and configure them to talk to each other — this post describes one possible setup that suited my needs.

It turns out LibreOffice’s RTF and DOCX import filter ignored borders around Writer pictures. Given that this worked in the RTF case in the past, it’s a bit amusing that now the very same commit implements a new feature for the DOCX case and at the same time fixes a regression in the RTF filter. Code sharing FTW! :-)

UPC traditionally had a setup consisting of a cable modem providing internet access to a single computer, and then it was up to the users if they use that access to really connect to a computer or to a router, providing wireless access and so on. It seems, these days they are more after actually encouraging people to use their subscription on multiple devices — possibly that way it’s easier to sell larger packages (like 60 MBit/s download rate instead of 30 MBit/s, etc). One fallout from this move is that they started to replace modems with a combination of modems and routers, in this case this is an Ubee EVW3226, with the brand removed. I wanted to try out if this new device could replace my previous router or not — so far it seems to be good enough, though there was one pitfall, hence this post.

It’s possible to define a range of IP addresses to be used for DHCP purposes, though you can’t serve fixed IP addresses based on the MAC address of the clients. Given that my home network isn’t that large, I can tolerate that: as long as there is a range that can be safely used for fixed addresses, I can configure that manually. It’s also possible to do port forwarding, e.g. redirecting the incoming ssh traffic to a given address — except you can’t do both at the same time: you can’t redirect traffic to an address that’s not known (served via DHCP) to the router. Which is a shame, the #1 use case for port forwarding is to redirect traffic to a home-server that will then also have a fixed IP internally…

So here is a hack that allowed me to still do this: set the start of the range of the DHCP served IP’s exactly to the address of the (to be used in future as) fixed address, e.g. 192.168.0.5. Connect with one client, so that the address will be known to the router. Then add the port-forwarding rule, finally set the DHCP range back to its original value (in my case I use 192.168.0.1..99 for fixed addresses and 100+ for dynamic purposes). It’s a stupid trick, but it works… ;-)

This year’s LibreOffice conference was held in Bern, Switzerland. Links to my slides:

During the sessions I also had some time to hack on the followings:

Regarding the number of attendees, draw your own conclusions from the group picture — probably around 300 attendees, counting all days.

Thanks for the organizers for this beautiful event — and also the sponsors! :-)

My pictures are available here (and I also made a panorama).

In June, we decided to get rid of XSLT usage in writerfilter, the module responsible for RTF and DOCX import in LibreOffice. As usual with cleaning up mess, this took time (about two months), but I’m now happy to say that I’m mostly done with this. :-)

See the doctok blog post for some background, the topic here was to clean up the OOXML tokenizer, that is that building block that turns a zipped XML document into a token stream.

The following problems are now solved:

Oh and the bonus feature: I’ve implemented a script called watch-generated-code.sh, which can record a good state of the generated code, and then compare later generated results against that, so that refactoring of the generator can now be performed in a safe way: you can change the generator in any way to make it better, and still avoid accidental output changes. :-) This is particularly useful, as it only diffs the end result of the whole generation process (cxx and hxx files), not temporarily files, which are OK to change, as long as the end result is the same.

As a conclusion, here are sizes of a stripped dbgutil version of the writerfilter shared library, from the libreoffice-4-3-branch-point and today’s master:

Again, the 8,3MB → 6,1MB size reduction is mostly thanks to Kendy’s map cleanups + the duplicated gperf hash going away. :-)

From time to time developers feel that they have little time, but they would want to take care of many bugs. Last week I was frustrated enough to actually design a T-shirt for just that. ;-)

Above is how it looks like. In case you don’t get the joke, see here for a hint. Oh, and if you would like to build your own binary… err T-shirt, you can do it: here is the ODG file that can serve as a source. Happy bugfixing! :-)

TL;DR: see above — it’s now possible to have complex Writer content (charts, tracked changes, tables, fields, etc.) inside drawinglayer shapes, yay! :-)

Last year I published some Writer training slides, which are hopefully a useful extension to in-tree documentation like sw/README and sw/qa/extras/README.

Last week I reviewed those slides and realized that some of them are outdated. So here comes an updated version:

The intention is that these build nicely on top of Michael’s generic intro slides, and with that, the reader can have a good "big picture" understanding of the code base. For the gory details, you always need to read the code anyway. ;-)

I’ve arrived home yesterday from Zagreb where I gave a keynote at CLUC 2014 on Tuesday.

Here are a few talks I enjoyed:

I also took a panorama and some pictures, available here, including photos of some speakers.

Thanks Elizabeth for the above photo, and also to the organizers of the conference, it was a great one! ;-)

Shapes in Writer are provided by LibreOffice’s drawing layer — they are independent from the normal Writer paragraphs. Given that the drawing layer does not support tracking changes, just Writer’s "native" paragraphs, fully featured tracked changes in real shape text would be quite some work. In case of ODF, the markup describes tracked changes in a way, so that in case the reader does not support tracking changes, it can at least read the normal and inserted text, i.e. the current version.

This is exactly what I implemented in the DOCX import filter now:

Previously we just ignored both inserted and deleted text, so if you had content which was all either deleted or inserted, you ended up having no shape text at all (can be tested using e.g. this test document):

To be fair, the reference layout looks like this:

I still hope to fix that as well one day, but the above fix is something we’ll already provide in 4.3. :-)