Comparing Spreadsheets

Bruce Byfield posted a comparison of three spreadsheets, namely OO-calc, Gnumeric, and KSpread.

Unfortunately he does not seem to be a spreadsheet user and the tests
he puts the programs through — while all relevant — are very basic.
It is a bit like comparing word processors only on how well they write
one-page letters. Here are some things that an in-depth review really ought to have included:

  1. Excel compatibility. He wants to compare spreadsheets for office use and he says nothing about Excel compatibility? That’s a gaping hole, in my humble opinion. In the office world you just have to be able to take an Excel file and import it and have it work by and large the same. I think Gnumeric does quite well here, particularly in the function and evaluation semantics department.
  2. Big spreadsheets. What would he have seen if he had taken one of the corporate or scientific monster spreadsheets and used them for a test? Generally, OO-calc would load the sheets albeit slowly; Gnumeric would load them faster, but not as fast as Excel; KSpread would roll over and die. The speed tests he performs is
    like testing C compilers on “Hello World”.
  3. Accuracy. If he had looked at other comparisons
    on spreadsheets
    he might have noticed that conventional wisdom is that Gnumeric’s functions compute things accurately while Excel does not. OO-calc and KSpread are still at the Excel level. And for the record, Gnumeric computes accurately not simply because we took R’s functions, but because we also heavily improved them and actively seek to return those improvements.
  4. Cross platform. OO-calc would win here because its Win32 support is still better than Gnumeric’s. But Gnumeric is getting there and unlike OO-calc (as I understand it) runs fine on 64-bit machines.
  5. Scripting. Gnumeric is lacking here. One can write new functins in Python and Perl, but that is about it. We haven’t gotten to programmatic control of the sheets yet.

Rotating text

Everybody and their brother have their own model for dealing with
rotated text.

Postscript (as I understand it) simply rotates the coordinate
system. Fine.

Pango rotates the image and then translates the origin to be
the upper-left of the rotated image’s bounding box. (It used to be at the top-left of the first letter.)

Excel (for a positive angle) rotates the individual lines of
the image and positions them side-by-side (so the lower corners are all on a horizontal line)
in such a way that the first line is translated just enough to the
right to make the text be below a hypothetical line starting at the
origin and having the desired angle from the X-axis.

Pango’s is weird, but the pixel image is at least continuous as a
function of angle. (Well, actually not, but that is because of a different
issue: hinting is turned off for non-zero angles.) But Excel’s?
As the angle goes towards zero, the image translates continously
to the right. If the angles were real numbers, the image would
translate all the way to infinity. Then, suddenly, at angle zero
everything snaps back to the origin.

The job then is to implement the latter in the world of the two

Gnumeric 1.5.1

You saw it here first. Gnumeric 1.5.1 is making
its way to the mirrors as these bits fly. It feels stable, but
there has been a lot of recent shuffling in core parts.

Think of Gnumeric (in general, not just the new version) as the Gnome guinea pig:

  • We do multihead display
    and had to clean up the library stack not to crash with it.
  • Multiline, right-justified and rotated Pango layouts that make Owen bite his lip? That’s us.
  • 100k-lines treeviews? Every day.
  • Planet-sized canvas? You bet.
  • Online documentation the size of “War and Peace”? Certainly.