about gnumeric
Bo Sun
I have used gnumeric (whose format is like execel)to store some data, now
I would like to use some windows application to open it.
I cannot use excel. So, which tool should I use?
Thanks,
bo
ge0rge
In the 'save as' panel, tell gnumeric to save the file in the format you
want (excel, pdf or whatever) instead of letting gnumeric use its own
default format.
ge0rge
--
Life without caffeine is stimulating enough.
-- Sanka Ad
Christopher Browne
> I have used gnumeric (whose format is like execel)to store some data, now
> I would like to use some windows application to open it.
>
> I cannot use excel. So, which tool should I use?
Gnumeric's native data format /is not like that of Excel,/ and is
totally incompatible with Excel.
Gnumeric can indeed import Excel files; it can indeed export Excel
files.
But in order for Excel to be able to read files generated using
Gnumeric, you have to expressly export them in "Excel format."
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www3.sympatico.ca/cbbrowne/spreadsheets.html
"One often contradicts an opinion when what is uncongenial is really
the tone in which it was conveyed." -- Nietzsche
Kevin Easton
Perhaps OpenOffice.org will be able to open Gnumeric files. At the very
least, it can open Excel files, and Gnumeric can be told to save in
Excel format.
- Kevin.
Andi Kleen
Last time I tried it didn't. It's a great annoyance that the
various Linux office applications (koffice, applix, OO, gnumeric, etc.)
all cannot read each other's files. While they are all in some
kind of text or XML format there are no docs and no tools to convert
between them, so it is quite useless.
Usually the only simple way to exchange data between them is to save in
the appropiate microsoft format, which is a kind of standard and can be
usually read or written
(but not always, e.g. kpresenter doesn't read/write power point)
-Andi
ge0rge
...
>
> Usually the only simple way to exchange data between them is to save
Quick! Here's the soap. Go wash your mouth and never repeat that again.
At present, for simple stuff, it is best to just use text format which
is pretty much universal. If fancy stuff is required (variable font
size, italics, undeline ...), the next best format should at least be
one which is cross platform eg. PDF or RTF ... or maybe XML will solve
this problem in future.
ge0rge
--
You will be run over by a beer truck.
Kasper Dupont
>
> or maybe XML will solve this problem in future.
IIRC the people behind openoffice and some others are
working on defining standard fileformats for spreadsheets
and wordprocessing. They will be XML formats.
Can anybody provide a reference to a webpage with more
information about this effort?
--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaa...@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);
Christopher Browne
> Kevin Easton <ke...@pcug.org.au> writes:
>> Bo Sun <b0s...@cs.tamu.edu> wrote:
>> Perhaps OpenOffice.org will be able to open Gnumeric files. At the very
>> least, it can open Excel files, and Gnumeric can be told to save in
>> Excel format.
>
> Last time I tried it didn't. It's a great annoyance that the
> various Linux office applications (koffice, applix, OO, gnumeric, etc.)
> all cannot read each other's files. While they are all in some
> kind of text or XML format there are no docs and no tools to convert
> between them, so it is quite useless.
.. Which is a nice proof that the marketing fluff about "XML being
standard" is just so much useless marketing fluff.
XML is only a "standard" of practical import when combined with a
DTD/Schema that provides authoritative information about what data is
permissible in the "tree," as well as with the more nebulous semantics
of what the software that reads the XML data knows how to cope with.
(Which may not be synonymous with the DTD/Schema, particularly if the
programmer doesn't know what a DTD is!)
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://www.ntlug.org/~cbbrowne/sgml.html
"I think that helps the users too much." -- CSTACY
Kevin Easton
Uhh..yeah. You try saving a Gnumeric spreadsheet into PDF or RTF, then
loading it up to edit in OpenOffice Calc.
- Kevin.
ge0rge
...
>
> XML is only a "standard" of practical import when combined with a
> DTD/Schema that provides authoritative information about what data is
> permissible in the "tree," as well as with the more nebulous
> semantics of what the software that reads the XML data knows how to
> cope with. (Which may not be synonymous with the DTD/Schema,
> particularly if the programmer doesn't know what a DTD is!)
Yes, a well-formed XML document is a very limited one if it is without a
DTD or a schema against which to validate the document.
However, even if you don't get the whole industry to agree on a unique
standard for a particular area whether for mathematical document, oil
drilling document or whatever, XML is still a far more useful way to
make the data portable and understood. At the very least you only need
to write it once and other people who receive your XML document can
manipulate, extract or transform what they required off your document
and make sense of it from the accompanying DTD or schema. That's got to
be better than any proprietory format which leaves you at the mercy of
the vendor who can change the format at will at every release and bugger
your own software (gnumeric and other software trying to provide
compatibility with M$ and a host of other formats is just a case in point).
And don't underestimate the fact that if hard-nose businesses are
jumping on that bandwagon, they must have smelt something of long term
value, a money making opportunity and the fact that they can't play King
Canute forever.
ge0rge
--
Don't take life seriously, you'll never get out alive.
Robert Grizzard
> Perhaps OpenOffice.org will be able to open Gnumeric files.
I had cause not too long ago to dig into a Gnumeric data file, and was
startled to discover it's nothing but gzipped XML. Seems to me a body
could write a unzipper/parser, grep the data, and export it as
comma-delimited text, /in extremis/.
[snip]
--
The appearance of my E-mail address in any venue does not in and of itself
constitute a solicitation of bulk or commercial E-mail.
Kasper Dupont
>
> After takin a swig o' Arrakan spice grog, Andi Kleen <fre...@alancoxonachip.com> belched out...:
> > Kevin Easton <ke...@pcug.org.au> writes:
> >> Bo Sun <b0s...@cs.tamu.edu> wrote:
> >> Perhaps OpenOffice.org will be able to open Gnumeric files. At the very
> >> least, it can open Excel files, and Gnumeric can be told to save in
> >> Excel format.
> >
> > Last time I tried it didn't. It's a great annoyance that the
> > various Linux office applications (koffice, applix, OO, gnumeric, etc.)
> > all cannot read each other's files. While they are all in some
> > kind of text or XML format there are no docs and no tools to convert
> > between them, so it is quite useless.
>
> .. Which is a nice proof that the marketing fluff about "XML being
> standard" is just so much useless marketing fluff.
Sure, being told a program saves data in XML format is not much more
helpful than just being told the program saves data in files.
>
> XML is only a "standard" of practical import when combined with a
> DTD/Schema that provides authoritative information about what data is
> permissible in the "tree," as well as with the more nebulous semantics
> of what the software that reads the XML data knows how to cope with.
> (Which may not be synonymous with the DTD/Schema, particularly if the
> programmer doesn't know what a DTD is!)
Yes, a specification of the format makes it useful. But can a DTD
specify *exactly* what is legal and what is not legal?
Friedrich Dominicus
> Kevin Easton <ke...@pcug.org.au> wrote:
>
> > Perhaps OpenOffice.org will be able to open Gnumeric files.
>
> I had cause not too long ago to dig into a Gnumeric data file, and was
> startled to discover it's nothing but gzipped XML.
Well the same ist true for OpenOffice. Isn't it quite intersting that
XML-files are usually zipped?
Just for the fun of it I have a Letter with around 189 words the whole
stuff unzipped are 4297 words that is a ratio of around 20:1
(markup/content), And I bet with some formatting I could drive it
easily to 40:1 ;-) even better the ratio form Characters, the file
contains 1080 characters the whole XML stuff bloats to 50983
a ratio of 46:1 with a bit work I could probably drive it to 100:1 ;-)
Well I guess you know why they are force to zip it. Just imagine you
want to send a hello over some connection...
That's typical XML from OpenOffice
<table:table-cell table:style-name="Tabelle1.B3"
table:value-type="currency" table:currency="DEM" table:value="208.86">
<text:p text:style-name="P7">208,86 DM</text:p>
</table:table-cell>
quite amazing how much mark-up is needed. And we do not even count the
redundancy of the content too
If you are really interested in what things are neede: see the Header
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE office:document-content PUBLIC "-//OpenOffice.org//DTD
OfficeDocument 1.0//EN" "office.dtd">
<office:document-content
xmlns:office="http://openoffice.org/2000/office"
xmlns:style="http://openoffice.org/2000/style"
xmlns:text="http://openoffice.org/2000/text"
xmlns:table="http://openoffice.org/2000/table"
xmlns:draw="http://openoffice.org/2000/drawing"
xmlns:fo="http://www.w3.org/1999/XSL/Format"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:number="http://openoffice.org/2000/datastyle"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:chart="http://openoffice.org/2000/chart"
xmlns:dr3d="http://openoffice.org/2000/dr3d"
xmlns:math="http://www.w3.org/1998/Math/MathML"
xmlns:form="http://openoffice.org/2000/form"
xmlns:script="http://openoffice.org/2000/script" office:class="text"
office:version="1.0">
> Seems to me a body
> could write a unzipper/parser, grep the data,
> for what will you grep?
> and export it as
> comma-delimited text, /in extremis/.
Good luck
I guess I understand now why we need such big computers ;(
Have a nice day
Friedrich
Kasper Dupont
>
> Robert Grizzard <griz...@mindspring.com> writes:
>
> >
> > I had cause not too long ago to dig into a Gnumeric data file, and was
> > startled to discover it's nothing but gzipped XML.
> Well the same ist true for OpenOffice.
IIRC AbiWord also stores gzipped XML.
> Isn't it quite intersting that XML-files are usually zipped?
Sounds reasonable to me. AFAIK gzip is a well documented
compression format, and is even part of the HTTP/1.1
standard, though it is optional and shouldn't be used
unless you know your partner supports it too.
XML formats can also be well documented, and are to some
extent human readable and writable. And I believe you can
get quite a large compression factor when gziping XML
files. So that makes sense.
I prefer gzipped XML files over any ultra compact and
poorly documented binary format.
> Just for the fun of it I have a Letter with around 189 words the whole
> stuff unzipped are 4297 words that is a ratio of around 20:1
> (markup/content), And I bet with some formatting I could drive it
> easily to 40:1 ;-) even better the ratio form Characters, the file
> contains 1080 characters the whole XML stuff bloats to 50983
> a ratio of 46:1 with a bit work I could probably drive it to 100:1 ;-)
>
> Well I guess you know why they are force to zip it. Just imagine you
> want to send a hello over some connection...
>
> That's typical XML from OpenOffice
> <table:table-cell table:style-name="Tabelle1.B3"
> table:value-type="currency" table:currency="DEM" table:value="208.86">
> <text:p text:style-name="P7">208,86 DM</text:p>
> </table:table-cell>
>
> quite amazing how much mark-up is needed. And we do not even count the
> redundancy of the content too
Well, XML is very verbose and also too verbose for my
taste. But with lack of better alternatives I still think
it is a good idea. However the redunancy in this particular
piece of XML bothers me. Why do they include the value
twice in slightly different formats? And what if they were
different, is that allowed by the format?
ge0rge
...
>
> Uhh..yeah. You try saving a Gnumeric spreadsheet into PDF or RTF,
> then loading it up to edit in OpenOffice Calc.
>
> - Kevin.
Hey, I was just making a general point - not talking about how to
implement a specific example. Of course, when you come to the details,
you're gonna find the gremlins and you have to find a workable solution.
There is no point in saving a gnumeric file as PDF or RTF if
OpenOffice.orgCalc does not read either of these formats. CSV is a
common format for both these apps - whether you can put up with the
inevitable subtle incompatibilities, that's another question.
ge0rge
--
There you go man,
Keep as cool as you can.
It riles them to believe that you perceive the web they weave.
Keep on being free!
ge0rge
Including redundancy in this particular instance was an OpenOffice
decision. If there were two recipients and each of these recipients had
only coded to parse the data for only one of the ways, I am sure they
would be grateful that OpenOffice had put in that redundancy.
But as a general point, given the well-known verbosity of XML, should we
worry about it? My own feeling is that we should not. Most XML files are
written by app to be read by another app. Being human readable is a
bonus for the odd times one has to delve into the XML file. The critical
points for XML are portability (hence a text format) and extensibility
(which removes the restrictions on how you arrange and describe your data).
Worrying too much about file size is to my mind not worth the bother.
Disk space is dirt cheap and most apps use it profligately anyway. A one
character file is saved as a 19K file by MS Word or a 5K file by
OpenOffice.Writer. Obviously zipping a file which has such a good
compression ratio makes sense for network transport purposes.
In answer to your question in a previous post about ... But can a DTD
specify *exactly* what is legal and what is not legal? The answer
depends on what you mean by legal. If you mean structural validity, yes
the DTD or schema will state categorically whether the document follows
the rules or legality of what is allowed. If you mean the semantic of
the data then it can't. Only humans can do that at the moment.
ge0rge
--
How come everyone's going so slow if it's called rush hour?
Friedrich Dominicus
>
> Well, XML is very verbose and also too verbose for my
> taste. But with lack of better alternatives I still think
> it is a good idea.
Well you might check out one of the Lisp there data format could be as
easy as
(some-key . some-val)
nest it and you have
(:cell ((:font "what-you-want")
(:size 20))
some-value) ....
you just need a tag for finding cell and than you just need info if an
attribute list is there or not but that's in fact one did not need to
have a new construct for this those things were/are/and will be called
Association List, maybe Property lists would be fine too. Clashing
names could be avoide with the package system. Parsing is as simple as
can be but probably not funky enough.
Just for the record such format
was used in Lisp Machine Concordia ages before HTML was nearly heard
about it.
So we prefer reinventing the wheel
badly. The most brain-dead extension for programming XML is
XSLT, but hey to get that right needs many resources and so it's the
way to go.
Not simplifying things is the way to go but make things be drowned
under a hundred layers of abstraction...
Well sorry, for ranting here, but I really can't hear that XML is the
best since sliced bread.
>However the redunancy in this particular
> piece of XML bothers me. Why do they include the value
> twice in slightly different formats? And what if they were
> different, is that allowed by the format?
The miracles of XML ;)
Salve
Friedrich
ge0rge
...
> Well you might check out one of the Lisp there data format could be
> as easy as (some-key . some-val)
>
> 20))some-value)
...
>
> Well sorry, for ranting here, but I really can't hear that XML is the
> best since sliced bread.
I really can't see what your objection to XML is. Look at the XML
equivalent of your Lisp example. They look identical to me.
<cell>
<font>
whatYouWant
</font>
<size>
20
</size>
someValue
</cell>
or, compactly, all on one line
<cell><font>whatYouWant</font><size>20</size>someValue</cell>
or write it another way
<cell font="whatYouWant" size="20">someValue</cell>
The crucial point is - XML is becoming an accepted industry standard
(and resources are being poured into that technology XSLT, DOM, SAX,
SOAP) while Lisp had not. If Lisp had become widely accepted then there
would not have been a need for another standard be it XML or something else.
ge0rge
--
Experiments must be reproducible; they should all fail in the same way.
Christopher Browne
> Yes, a specification of the format makes it useful. But can a DTD
> specify *exactly* what is legal and what is not legal?
Only to a very limited degree.
It can characterize the permissible hierarchy.
But it can only provide /very/ limited guidance as to what values are
allowed to be assigned to elements/attributes.
And it's not not nearly enough guidance.
I once tried "hacking in" values into a GnuCash file; it turned out
that order of elements was /hugely/ significant, where you /had/ to
declare <gnc:account> elements before any <gnc:transaction> that
references the account.
If you looked at things from the DTD perspective, it would be quite
acceptable to define things just about whereever you like in the file;
the implementation turns out to be somewhat fragile, expecting a
pretty exact ordering.
I've gotten Gnumeric to blow up pretty good by hand-generating XML
input that was structurally legitimate, but which it couldn't cope
with...
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://cbbrowne.com/info/xml.html
I always try to do things in chronological order.
ge0rge
> Oops! Kasper Dupont <kas...@daimi.au.dk> was seen spray-painting on
> a wall:
>
>> Yes, a specification of the format makes it useful. But can a DTD
>> specify *exactly* what is legal and what is not legal?
>
>
> Only to a very limited degree.
>
> It can characterize the permissible hierarchy.
>
> But it can only provide /very/ limited guidance as to what values are
> allowed to be assigned to elements/attributes.
>
> And it's not not nearly enough guidance.
I don't agree with your statement about very limited ... For example, in
your DTD, you can declare an enumeration list of allowable values
(north, south, east and west) for a particular tag (compasspoint). If
the value for that tag in your document does not match one of these
values, the XML parsing will cause a validation error. Schemas allow for
an even richer set of data types. You can be as tight or as loose (Don't
parse this bit at all) as you want when you create your DTD or schema.
> I once tried "hacking in" values into a GnuCash file; it turned out
> that order of elements was /hugely/ significant, where you /had/ to
> declare <gnc:account> elements before any <gnc:transaction> that
> references the account.
Absolutely, if that is what the DTD/schema dictates.
> If you looked at things from the DTD perspective, it would be quite
> acceptable to define things just about whereever you like in the
> file; the implementation turns out to be somewhat fragile, expecting
> a pretty exact ordering.
>
> I've gotten Gnumeric to blow up pretty good by hand-generating XML
> input that was structurally legitimate, but which it couldn't cope
> with...
I am sorry. I don't believe that is the case. You must have
misinterpreted something along the line. Otherwise the XML W3C and its
community are in deep shit.
ge0rge
--
The trouble with the rat-race is that even if you win, you're still a
rat. -- Lily Tomlin
Jody Goldberg
Gnumeric can export files in several formats it depends alot on what
your needs are. It's native format is currently gzip xml, the HSSF
project from the apache group can read that and generate xls
indirectly. Gnumeric-1.0.x can export to XL95 (the 1.1.x
development version handles XL97/2k/XP also).
Other less comprehensive formats include text (csv and friends),
html, latex, roff, and DIF.
What do you need to do with the files under windows ?
Hope that helps
Jody (Gnumeric Maintainer)
PS
I'm working towards supporting a win32 based version of gnumeric
but don't have easy access to a windows box to support it yet.
Some help would be appreciated.
Jody Goldberg
> Kevin Easton <ke...@pcug.org.au> writes:
>
>> Perhaps OpenOffice.org will be able to open Gnumeric files. At the very
>> least, it can open Excel files, and Gnumeric can be told to save in
>> Excel format.
>
> Last time I tried it didn't. It's a great annoyance that the
> various Linux office applications (koffice, applix, OO, gnumeric, etc.)
> all cannot read each other's files. While they are all in some
> kind of text or XML format there are no docs and no tools to convert
> between them, so it is quite useless.
information is still lost, the main content is intact. kspread can
import Gnumeric. At this point I don't think openOffice can read
gnumeric files, although it would probably not bee terribly hard if
someone wanted to.
The key problem is that a file format reflects the structure of the
applications. I learned a fair amount about how XL does things jsut
by reading its files. Doing the mapping is hard work at times.
> (but not always, e.g. kpresenter doesn't read/write power point)
I'm fairly sure kpresenter has a powerpoint importer.
Jody Goldberg
> Kevin Easton wrote:
> ...
> >
> > Uhh..yeah. You try saving a Gnumeric spreadsheet into PDF or RTF,
> > then loading it up to edit in OpenOffice Calc.
> >
> > - Kevin.
>
> Hey, I was just making a general point - not talking about how to
> implement a specific example. Of course, when you come to the details,
> you're gonna find the gremlins and you have to find a workable solution.
> There is no point in saving a gnumeric file as PDF or RTF if
> OpenOffice.orgCalc does not read either of these formats. CSV is a
> common format for both these apps - whether you can put up with the
> inevitable subtle incompatibilities, that's another question.
I would not reccomend pdf, rtf, or csv for serious spreadsheet work.
The reality at this point in time is that the lingua franca is XLS.
none of the other formats are as rich just yet. Even the new
openoffice xml and structured container still leaves much to be
desired. xls ain't pretty but all of us have to support it.
Hopefully with time something better will emerge. As Jim Getty's
put it in a talk at GUADEC in 2002, we need to 'drain the swamp'.
Which for me means that I'll need to contribute gnumeric read/write
filters to OpenCalc.
Jody Goldberg
> Oops! Kasper Dupont <kas...@daimi.au.dk> was seen spray-painting on a wall:
>> Yes, a specification of the format makes it useful. But can a DTD
>> specify *exactly* what is legal and what is not legal?
>
> Only to a very limited degree.
> It can characterize the permissible hierarchy.
still very dependent on the implementation. Especially for things
like spreadsheets. Important elements like expression syntax are
completely ignored.
> I've gotten Gnumeric to blow up pretty good by hand-generating XML
> input that was structurally legitimate, but which it couldn't cope
> with...
Ouch. Please file bugs for that sort of thing. I've tried to be
pretty rigorous about validating, but there are certain to be
pathological items that slipped though. PAtching them should be
trivial. bugzilla.gnome.org should get things handled quickly.
Thanks
Jody (Gnumeric Maintainer)
Jody Goldberg
>
> I had cause not too long ago to dig into a Gnumeric data file, and was
> startled to discover it's nothing but gzipped XML.
Yup, that is the case for many applications with xml based formats
(eg dia, abiword). I'm going to be migrating to a zip based
structured file to support more advanced embedding in the next major
release (1.2) but the primary content will remain xml.
OpenOffice and Koffice do pretty much the same thing. This is a
nice step forward after having to write libgsf (and its predecessor
libole2) to read the MSOffice OLE2 files.
Andi Kleen
> > (but not always, e.g. kpresenter doesn't read/write power point)
> I'm fairly sure kpresenter has a powerpoint importer.
Must be a recent development then, when I tried originally it didn't.
Anyways, openoffice at least cannot read native kpresenter files.
Yes, this can be a serious problem when you're working for a linux company
where all these formats are actually used...
Files I got regularly were:
- Applix (mostly SpreadSheet, sometimes WP) text files
Nothing but Applix can read it. Seems to be fortunately dying now.
Avoid these at all costs.
- KPresenter, Koffice native XML files
Nothing but Koffice can read it.
Best to avoid these.
- StarOffice 5.x binary files
Nothing but Star Office / Open Office can read it.
Best to avoid these. Seem to be fairly common.
- OpenOffice text / spreadsheet/presentation files
Only OO itself used to be able to read them; nice if it has
changed for gnumeric at least.
For Spreadsheets it may be an alternative in the future, for text/presentation
I would still advise to stay with the microsoft format.
- Gnumeric XML
Seems to be gnumeric only. Best to be avoided.
- Microsoft .doc
Seems to be best supported. Plenty of programs that can read and
write it.
- Microsoft .xls
Seems to be also well supported. Near all Linux spreadsheets
(except perhaps oleo) can read it.
- PowerPoint
Only OpenOffice/StarOffice used to be able to read them, now
if kpresenter does too that makes it pretty much universal.
- RTF
can be usually read, but is bloated to enormous sizes even
for simple documents because it is very inefficient.
- CSV
Works nicely for data, but cannot preserve any formatting or more
complex spreadsheets.
I still hold to my original point that the Microsoft formats
are still the most widely supported interchange formats even in a
linux only environment. RTF and CSV work too, but have disadvantages.
The XML hype didn't seemed to have helped at all, except for causing
lots of new incompatible data formats, so overall I would consider
it harmful.
-Andi
Christopher Browne
> - RTF
> can be usually read, but is bloated to enormous sizes even
> for simple documents because it is very inefficient.
What is remarkable is that despite the "bloat," RTF tends to be a lot
more size-efficient than MSFT ".doc", even though the latter is a
binary format, which /in theory/ ought to be able to be a lot more
efficient...
--
output = reverse("moc.enworbbc@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/emacs.html
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
Jody Goldberg
> Files I got regularly were:
>
> - Applix (mostly SpreadSheet, sometimes WP) text files
> Nothing but Applix can read it. Seems to be fortunately dying now.
> Avoid these at all costs.
> - StarOffice 5.x binary files
> Nothing but Star Office / Open Office can read it.
> Best to avoid these. Seem to be fairly common.
> - Gnumeric XML
> Seems to be gnumeric only. Best to be avoided.
There is also 3rd party support for apache via the hssf project.
> - Microsoft .xls
> Seems to be also well supported. Near all Linux spreadsheets
> (except perhaps oleo) can read it.
The quality varies. Gnumeric has the best XL95 importer, OO has the
best XL97 importer (although we're edging them in spots :-)
> I still hold to my original point that the Microsoft formats
> are still the most widely supported interchange formats even in a
> linux only environment.
You're correct.
Kasper Dupont
I think that is a problem. Hopefully that is about to change.
Before we get open document formats for those purposes, I
don't think there is much hope about weakening Microsofts
current position.