Re: Gnumeric 1.0.10

[Nick Lamb <njl98r ecs soton ac uk>]

On Sun, Oct 06, 2002 at 01:57:06PM -0400, Jody Goldberg wrote:
>     Jody:
>       * Export copy/paste data to primary and clipboard to
>         communicate with 1.1.x.

Yay. Meanwhile I am trying to work with Gnumeric 1.1.x on RH 8.0, and I have
some initial success hacking pre-OLE Excel support back in.
libgsf seems to be basically the Right Thing for this job, so thanks to
Jody and others who worked on it. Much better than libole.

First things first:
Is it intended that Gnumeric should not crash when handling invalid XL
data, or are we working on a "Your mother!" basis where it's OK because
XL would blow up too? If we don't want to crash then the Excel plugin
needs a _lot_ of additional range checks. I do not plan to write all
these but I need to know if I should bother catching the obvious ones
during my BIFF work.

My first non-OLE XLS file loaded last night. I still don't have huge
amount of time to work on this stuff, but I do have a few hours once
in a while now. Since I'm not totally familiar with the internals of
the excel plugin I may have to ask a few questions 

1. What's the preferred way to handle pure BIFF XLS in the boot.c
file? Obviously I need to pass the raw GsfInput instead of creating
one using an OLE2. Should I wait for the OLE2 stuff to fail, and
handle BIFF in the "else" case? Right now I just #ifdef'd all the
OLE code out, obviously that's not a long term solution :)

2. Early (like 2.1) XLS is a skeleton of what we have today. So there
is no BOF-Workbook, should I conjure a workbook into existence when I
detect the old version tags in BOF-Worksheet, or ... ?

3. I gather than XFs have something to do with style. But what exactly
is going on when I try to read a worksheet and a default XF is wanted,
can I just conjure one up with sane values from somewhere? Excel 2.1
wasn't big on style, and Excel 3.0 isn't much better.

Nick.