OpenOffice trouble, again, again, again

So I already noted my frustration with OpenOffice yesterday but today I’m definitely reaching my limit. And I’m going to rant, yes, it’s going to be pure rant about OpenOffice, encompassing some of the most annoying problems I had with it in the past years. So if you’re one of those people who can’t stand when other Free Software developers complain about projects that are not perfect, please move along. I’m not just going to bless OpenOffice as perfection just because it’s Free, it’ll have to improve for that. Oh, and yes I know that version 3.2 was just released, and I’ll test that one, but then again I’m not sure that there is any improvement about this, I’ll have to see it by myself, and right now it’s not available in Gentoo for me to try.

So let’s begin with one of the most hyped and, apparently, still incomplete feature: interoperability thanks to the OASIS OpenDocument Format. With OpenOffice 2, there should have been total interoperability between Free Software aiming at managing documents, presentations, spreadsheets and so on so forth. Unfortunately, just after the release of the first two suites using that format, I came across a difference in implementation that caused the two of them to export the same content (lists) in different way, both available in the specification for the format, and yet not equally implemented. So long for the interoperability. At the time, I even considered Microsoft’s much more complex solution more feasible — two years after my first rant, the bug was still open; it was only fixed an year later with OpenOffice 3.1.

Interestingly enough, yesterday Morten Welinder, of Gnumeric fame, posted an unrelated rant that finds its root in the same problem: OpenDocument wasn’t specified nearly as deeply as it should have been to begin with. In this particular case, the problem is even worse, as the lack of a standardised interface for formulae makes it almost useless as a format for complex spreadsheets. On a more related note, I also complained about the formula support especially related to the fact that formulas in OpenOffice change function names depending on the used language, and the comma/dot change as decimal separator makes it almost impossible to use it properly in Italian.

To defend OASIS here, ODT is definitely not the only format designed for interoperability that is not interoperable by a long measure. For instance, SVG caused me headaches also including OpenOffice in the mix.

Other problems are intrinsic in the way OpenOffice is developed, I guess, and the priority that they have. I already complained about the tentative imitation of Word regarding their work toward adding “HTML editor” to the list of features Writer has. Not sure how to read the fact that they moved the MediaWiki editor support to an extension… I didn’t even know it had such feature… wasn’t the point of Wikis to not have to use a full-fledged editor to begin with?

There is definitely a number of minor annoyances with OpenOffice as it is. The fact that to set a colour, anywhere, I need first to get to the options and define it as a custom entry in a palette, rather than having a simple colour picker like any other software (Inkscape, Gimp, …) is just the start. You also need to install extensions to have any kind of document template available, and quite a few of them look also totally broken.

Most annoyances seem indeed to come near the areas of drawing and spreadsheet handling (especially charting). You might have noticed my Ruby-related charts and graphs but you might not have noticed one bad things with them. Beside the minor annoyance that I have to copy the graph from Calc to Draw (and thus lose the correlation with the data I’m charting) to be able to export it properly, if I copy the legend out and add text boxes… OpenOffice Draw exports the spell-checker warnings! Look at the images, and notice that the text is zigzag-underlined in red. I couldn’t believe it the first few times.

And today’s problem, is due once again to Calc, and to the charts provided above: I have a spreadsheet file where I keep the scores for the various implementations, to see the trend in porting (for instance I know that nobody else beside me is handling JRuby support nowadays, as it’s stuck when I don’t touch it).

One of the problems I had before is the area and line charts have different ideas on how to handle empty values. If I chart a 30-lines spreadsheet area with a line chart, which is only half-filled in, the graph stops at mid-air, and that’s it (works out fine since it gets automatically extended when I add more lines); on the other hand, if I do the same with an area chart, then it assumes that the empty results have zero as value, and will draw a line falling down to the X-axis at the first empty position. Annoying, but at least acceptable.

On the other hand, what is definitely not acceptable to my way of using this is the way it handles the X-axis values! I was away for FOSDEM, and then had a bit of personal trouble, so I stopped gathering data on February 3rd and I resumed yesterday, February 10th. I added the data to the spreadsheet and… the graph didn’t jump, the same distance that applies between February 2nd and 3rd is applied between 3rd and 10th. This is not right. Indeed, Microsoft Excel gets it perfectly right in this case, and this is exactly what I was expecting: keeping proportions. And before you suggest I keep the same value as 3rd for all the missing days, that’s not how it was, and it’s not what I’m interested in charting. I’ll have to see if I can get some other software to deal with that kind of data (interestingly enough, Gnumeric does not seem to have that feature either, but it might be I just don’t know how to use the charting tool there).

So, should I accept the compromises just because this is Free Software? I don’t know what you think but I don’t think so, I’ll look for a better software, if it’s Free it’ll have extra points, but since there is a boolean gate to the “better” definition (either it does what I need or it does not), right now OpenOffice is definitely not better than anything else for this task (it does not do what I need). It’d be definitely absurd if I’ll end up relying on Microsoft Excel to provide the graphs for Gentoo’s Ruby porting trends, but right now, that does pass the boolean gate. Please, do provide suggestions! I do want to find a better software, a Free Software doing this.

And to keep on the ranting note, do you remember the “OpenOffice Mouse”? That abomination of design that was announced around the time of the past OpenOffice Conference in Italy? The one that a lot of people – me included – thought and hoped was just a joke, playing on Apple’s then just-unveiled Magic Mouse? Well I haven’t heard anything about that for a while, beside being confirmed by Luca that it had been actually developed, and even produced. I went to look it up today, as I wanted to add to the rant the fact that instead of getting a better quality product, time was wasted on products like that… and the results are even funnier. The link above, while having ”OpenOfficeMouse” in the domain, talks about “OOMouse” (trademark, anybody?) and if you drop the actual page, you end up finding that it’s now the “WarMouse Meta” which, and I quote, “compares to the Magic Mouse, the G9, the Naga, and other multi-button and multi-touch mice”… oh, the irony.

Inconsistent Scalable Vector Graphics

The one job I’m taking care of at the moment involves me drawing some stuff using SVG in C code, without using any support libraries. Without going into much detail, since I cannot because of an NDA, I can say the generated file has to be as small as possible since, as you might guess by now, it has to be done on an embedded system.

The task itself is not too difficult, but today I started the actual reduction of the code so that it fits in the software the I have to develop, and here starts the problems. The first issue has been I was tired of looking up the correct attributes for each SVG element, so I ended up doing the same I did for DocBook 5 and added a new ebuild to portage: app-emacs/nxml-svg-schemas:1.1 which installs the SVG 1.1 schemas so that Emacs’s nxml-mode can tab-complete the elements and attributes. I positively love Emacs and nXML since it allows me to have specific XML variants support by just adding its schemas to the system!

A little note now about nXML though: I’ll have to contact upstream because I found one nasty limitation of it: I cannot make it locate the correct shemas on a version basis, which means I won’t be able to provide SVG 1.2 schemas alongside as 1.1 with the code as it is; if I can get a new locating rules schemas that can detect the correct schema to use also through version, that’s going to solve not only SVG 1.2 but also future DocBook versions. So this enters my TODO list. Also, am I the only one using nXML in Gentoo? I’m maintaining all the three schemas ebuilds, it’s not like it’s a big hassle, but I wonder what would happen if I were to leave Gentoo — or more likely at this point if I were to end up in the hospital again; I hope I’m fine now but one is never sure, and my mindset is pretty pessimistic nowadays.

At any rate, I’ve been studying the SVG specifications to find a way to reduce the useless data in the generated file, without burdening the software with doing manual calculations. The easy way out is to use path and polyline elements to draw most of the lines in the file, which would be fine if it wasn’t they only accept coordinates in “pixels” (which are not actual pixel, but just the basic unit for the SVG file itself). This is not too bad since you can define a new viewport which can have an arbitrary size in “pixels”, and is stretched over the area. The problem is with supporting the extra viewports.

The target of the file to generate is to work on as many systems as possible, but it’s a requirement that it works on Windows with Internet Explorer, as well as Firefox. For SVG files under Internet Explorer there is the old, unmaintained and deprecated Adobe SVG plugin (which is still the default Internet Explorer will try to install) and the examotion Renesis Player which is still maintained. So I take out my test file, and try it.

I wrote the file testing it with eog which I’m not sure which SVG library uses for the rendering and with rsvg that uses librsvg obviously; with those, my test file was perfect, the problem has been with other software, since I got the following results:

  • Inkscape wouldn’t load it properly at all and just draw crazy stuff;
  • batik 1.6 worked;
  • Firefox, Safari and Opera shown me grey and red rectangles rather than the actual lines I wrote in the SVG;
  • Renesis Player shown me lines, but way too thick for what I wanted;
  • OpenOffice shown it with the right dimensions but didn’t translate it 2×2 cm down from the upper left corner like I instructed the svg to.

After reporting the issue on examotion’s tracker, since that is the most important failure in that list for my current requirements, I got a suggestion of switching the definition of font-size to direct attribute rather than through style so to change the actual svg measure unit. This made no difference for the three implementations that worked before, nor on examotion, but actually got me one step closer to the wished result:

  • inkscape still has problems, the white rectangle I draw to get a solid white background is positioned over the rest of the elements, rather than under like I’d expect since it’s the first element in the file; it also does not extend the grid like it should, so the viewBox attribute is not properly handled;
  • OpenOffice still has the problem with translation but for the rest seems fine;
  • Safari still has the same problems;
  • Opera 9.6 on Windows finally renders it perfectly, but fails under Ubuntu (?!);
  • Firefox official builds for Windows and OSX, as well as under Ubuntu, work fine; under Gentoo, it does not, and still show the rectangles;
  • Adobe SVG plugin work fine.

At this point I should have enough working implementations so that I can proceed with my job task, but this actually made me think about the whole thing about SVG, and it reminded me tremendously of the OASIS OpenDocument smoke which I had a fight with more than three years ago. I like very much XML-based technologies for sake of interoperation, but it’d be nice if the implementations actually had a way to produce a proper result.

Like in OpenDocument, where the specifications allow two different styles for lists, and different software implements just one of them, making themselves incompatible one with the other, SVG defines some particular features that are not really understood or used by some implementations, or can create compatibility issues between implementations.

In this case, it seems like my problem is the way I use SVG subdocuments to establish new viewports, and then use the viewBox feature to change their unit space. This is perfectly acceptable and well described by the specifics, but it seems to cause further issues down the line with the measure units inside and outside these subdocuments. But it seems like the problem is not just one-way, from this other bugreport on Inkscape you can also see that Inkscape does not generate so pure SVG as it should.

While XML has been properly designed to be extensible, thanks to things like namespaces and similar, one would expect that the feature provided by a given format would be used before creating your own extensions; in this case from that bug report you can see (and I indeed double checked that it still is the case) that Inkscape does not use SVG’s own features to establish a correspondence between “SVG pixels” and the size in real-world units of the image; indeed, it adds two new attributes to the main document: inkscape:export-xdpi and inkscape:export-ydpi, while SVG expects you to use the viewBox for providing that information.

Sigh, I just wished to get my graph working.

Specifications, specifications, specifications

I was talking with a friend about OpenDocument, and why I think it is just a name empty of an effective ability to share the documents saved in that format between different software (remember my thoughts about ODF?), and I was pointed at a blog entry of Uwe Hermann (Debian developer, if I remember correctly), read of it here.

Yes, probably the specifications of OpenXML are overly comprehensive, to the point they are most likely useless (I maintain that too long specifications are pointless, too), but OpenDocument specifications are too empty of content; they don’t seem to specify enough details so that the documents can be shared between two implementations, like KWord’s and OpenOffice’s.

And yes, it seems like the bug I reported about two years ago it’s not fixed yet. So maybe, but just maybe, this time Microsoft might make something good for Free Software too, if OpenXML is absolute enough for the same document to be rendered in the same way on Office, OpenOffice and KOffice.

Of course, it would be of no use if they patent it.

My thoughts about ODF

I think I blogged about this more than a couple of time in my old blog, but I won’t be listing them here, because I don’t really want to go searching for those posts, or I’d find a lot of stuff I said last year that might make me cry because I wasn’t able to do what I was planning (or simply because it would show me how much time passed and I’m still doing the same stuff), and also because the more I link them around, the more spam comment they attire and the more junk mails I receive on my inbox (yes, I still receive Planet’s comments by mail).

Today’s hot topic among a lot of Planets seems to be the support of OpenDocument by Microsoft, although only in some extra stuff and likely crippled. There is who asks for more, for a proper complete support of ODF in Microsoft Office, there is who tells that this is just an economic or political move, and so forth.

What I think, is that the support cannot be complete, and this is not because Microsoft does not really want it. Yes it was a political move for sure, as they had political pressures to support that. But when the problem is political is likely to make the development to be complete as much as possible to show that they are actually doing what requested.

The problem is that ODF is not ready for prime time. The current implementations are different and distant one to the other. The format that should be the simple one (ODF) is not compatible between KWord and OpenOffice 2, that are the first two applications supporting ODF and the main ones by all means. Bugs in KWord and bugs in OpenOffice are the cause, they both don’t implement the specific in their completeness, so when one relies to one way to record something, the other prefer a different method. Don’t even let me started on spreadsheets and presentations, that goes worse and worse.

So the result is that ODF is hardly a working solution right now. If I want to write something that I’m sure I can read in two years from now, my best bet would be LaTeX rather than ODF. Because two years from now maybe a new spec of ODF is implemented and used by both KWord and OpenOffice, and the current one not being supported anymore would make it difficult for me to open the old file.

So, once you stop all the hype about ODF itself, and look at the real world situation, you can see that Microsoft has hardly reasons to try to hinder open formats by ditching ODF for their OpenXML. From one point of view, it might make a better open format with OpenXML than ODF is now, because they would be the ones writing the reference implementation, and the others should simply follow that, without implementing their own ideas and thus making the format incompatible with others implementations… tyrannical, yes, but would be better than the current anarchical situation.

The Curse of the Word Processors

Ok this is getting interesting.

As I bought a new keyboard, and it’s quite comfortable, I moved working using my desktop system instead of the iBook. This also because the temperature under my hands on the iBook is quite high because of the hard disk.

The problem is, as I have an AMD64 system, that I don’t want to use OpenOffice as that’s using 32-bit emulation, so I used KWord from KOffice which works good on its own, and it supports also OASIS OpenDocuments.

I must deliver using SXW format so I thought of just saving in OpenOffice format and then send, but.. lists aren’t exported in OpenOffice documents.

Then I thought of just saving in RTF and open them with NeoOffice/J on the iBook, but… different ordered lists are seen like one continuing list when importing RTFs in OpenOffice. Ok I’m now using KWord and just re-style the lists on NeoOffice/J, but this still isn’t a good way to do, so I installed OpenOffice 1.9.109 here and thought of saving in OpenDocument format and then saving them using OpenOffice to the SXW format but… well it doesn’t work, the OpenDocument saved by KWord and then loaded in OpenOffice doesn’t contain any list.

The problem now is that I just know of two programs which supports ODT: KWord and OpenOffice, and this makes difficult to identify which of the two is at fault now.