Older blog entries for Jody (starting at number 40)

26 Sep 2003 (updated 26 Sep 2003 at 14:30 UTC) »

ssconvert lands in CVS.

People have been asking for cmdline access to gnumeric's importers and exporters for years. I've always resisted writing it because it seemed like such a perfect starter project for someone. After receiving three requests in one day I broke down and knocked off a quick wrapper.

150 lines of code, with attribution and fancy white space for the exporter list.

To be honest it did take a bit of tweaking to force it to work without a DISPLAY, and there are definitely lots of bells and whistles to be added. However, if you need to convert to or from xls it'll get the job done.

xls -> html
xls -> latex
OO -> ... well you get the idea

Now we need to add support for command line flags to configure the importers and exports.

24 Sep 2003 (updated 24 Sep 2003 at 16:44 UTC) »

Gnumeric 1.2.0 has been surprisingly stable given the amount of last minute churn. We really violated every tenet of a release freeze except the test suite validations. A couple of moderate crashers have shown up but nothing really major. We're getting some useful feedback on performance now. Things look good, but a few cases for large data sets have forced us to tweak things.

1) row height autosizing was being very stupid. Why bother rendering a cell to calculate its height if it doesn't wrap. By definition all we need there is the font height. Huge space saver when reformating 1 million cells

2) Do not call _() in your value parsing routines. DOH! gettext is expensive with that many calls.

The relative quiet has given me time to get caught up on all the pending patches. Improved svg export for the charts, better heuristics for auto selecting range for autofilter, and more ATK relations for the dialogs.

Probably do a 1.2.1 this weekend to get some of the patches and tweaks out.

Of course that schedule is pretty flexible, depending on the arrival time of goldberg-v2.2 (potential code name 'pretty in pink')

Gnumeric 1.2.0

That was painful. Its been almost 20 months since the 1.0.x series came out and we've spent alot of time tuning the engine adding features and puttering along waiting to get the charting engine back on line. I'd have prefered to have done 2 possibly even 3 stable releases in that time frame.

The new engine is now at the point where its architecture seems to have proven itself, and there are enough features implemented that its useful. sample

So what does the future hold ?

I'm dividing goals into 3 broad catagories

1) Improving Gnumeric

  • Split out libgnumeric
  • Finish implicit iteration for operators
  • XL export for charts
  • Conditional Formats
  • Pivot Tables
  • Scripting
  • Accessability
  • Make the jump to using the SAX parsers by default
2) Improving GNOME Office
  • Polish clipboard interaction to a high gloss
  • split out libgoffice
  • Integrate better with GNOME mime handling and release cycles
3) Improving interaction with other projects
  • Continue exporing use of uno. If we can embed lets embed gnumeric in Impress...
  • A VBA stream parser
  • Pie in the sky talk to OO folk about sharing the charting library. They need to write one, and complain that theirs is currently scatted throuht their system. Ours is designed specificly to enable new types as plugins. The is a weak point for MS Excel. If we combine efforts we might knock them down a peg sooner.
25 May 2003 (updated 26 May 2003 at 01:24 UTC) »

Its been a grind to get charting back in Gnumeric but at long last there is a framework in place. Its still a touch rough around the edges, with some tuning necessary in the libart backend, and lots of unfinished bells and whistles. However, it is quite modular, easy to understand, and has a decent interface to Gnumeric.

Here's a sample imported from xls

I'm not thrilled with the bleed through on bars with 0 separation due to antialiasing, and the fringing should also be tuned.

In other news Morten has been banging away at full throttle and has us mostly multi-head aware. He and Andreas have also been scrubbing text import/export to get tie down utf8 issues. The rest of the system is pretty much ready to freeze. Although 1.1.17 was not announced due to late breaking bugs, 1.1.18 is shaping up very nicely.

I should probably do a quick status report given that gnumeric 1.2 is about to miss its worst case deadline by a few months. Development is progressing nicely in all areas accept graphs where things are still unclear. With the hibernation of Guppi we're left without a gnome2 ready engine and will probably end up using a bastardized version of gtkextras-2 with some guppi goodness thrown in.

For everything else gnumeric is kicking butt and taking names. The XLS export is in great shape, conversion to gsf is done, and autofilter support has landed. Heck even pivot tables look possible. The new target for release is the begining of april. Hopefully by then graphs will be solved.

Ok, researched OLE property sets and started work on reading and writing them. It should not be bad, although I was surprised that both libole2 and POI had some rather significant confusion here. However, adding this did not solve the warning from MS Excel so I was forced to merge in patches 1 at a time from 1.1.5 to present to see where the exported file went wrong. It turned out to be the selection exporter. The old version just hard coded A1 the new version tried to be correct, and ended up specifying the selected pane as #0. Excel did not like that. It wants the pane to be #3 if there are no splits.

Once that was found it was time to release 1.1.8 so that the pango code can get some testing.

Phew it may not be as bad as I feared. The OLE exported was mostly correct, but libole2 was using the bats rather than the stated sizes to build files. This ran into trouble when we padded unused bat elements with 0 rather than 0xfffffffe to indicate unused.

MS Excel is still complaining. However, I'm starting to suspect that it is not the OLE. When I simply clone an existing xls file into a new wrapper using libgsf MS Excel is fine with it. That leads me to beleive that the problem is either with the lack of metadata (which is temporarily disabled in gsf) or a new bug in the XL exporter. We'll see. Either way it is not too bad. New releases of gsf and gnumeric to be made shortly to make sure stable gnumeric can read the generated xls from the development version.

On a positive note support for pango in cells just landed in CVS. There will definitely be some performance tuning and some utf8 bugs to work through but a big piece is there.

1.1.7 is also surprisingly stable, we've been kicking the importers and exports around alot and they are in decent shape. Unfortunately it looks like there are still a few gotchas in the gsf OLE export code. libole2 could not read it and XL complains. I'm working to fix it now.

1.0.8 was released to fix what I hope are the last of the problems handling broken locales.

1.0.9 was just released to polish a few of the importers. Excel now parses all of our test workbooks smoothly, lotus had some problems with relative references, and applix was not requiring a respan at start up.

New development procedes nicely. libgsf is now used for all import mechanisms, and the ole exporter is good enough to supplant libole2 entirely.

Jukka Pekka is a back with a vengance, adding lots of new functions, and I've been poking along adding features like

- a quattro pro importer

- hyper links (import from xls, and activation, no ui yet)

- constructed ranges (eg A1:index(B3,2,3))

- SheetView is finally in place

- I've even started support for implicit iteration

All in all there are lots of new toys coming up. We'll probably do a 1.1.6 release as soon as the zipfile support lands in libgsf.

Ok, email is back and its time to update status.

Gnumeric is chugging right along releasing 1.0.7 to correct some xls export problems, and getting 1.1.5 out also so that printing and embedding would work again.

1.1.6 will depend on the libole replacement, libgsf which has also solidified recently.

31 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!