[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: another suggestion for writing new filters
From:       Werner Trobin <trobin () kde ! org>
Date:       2002-07-10 4:54:55
[Download RAW message or body]

On Wednesday 10 July 2002 03:28, T.J. Mather wrote:
> On Tue, 9 Jul 2002, Werner Trobin wrote:
> 
> > This week I'll have my last exam for this semester and I plan to have a 
look 
> > at the Apache thingy. One huge problem I see are the ugly dependencies and 
> > license issues. Due to that I'm rather sceptic, but we will see.
> 
> The problem with the dependency on GCJ 3.1 will go away with time as 
> everyone upgrades to GCC 3.1 or higher.  The License issue is a serious 
> one, but can be worked around by making the filters standalone programs.

Please don't think Linux-only. There are a number of Unices KDE runs on, and 
right now on most of them it can be compiled using the native compiler (like 
AIX's xlC, the Tru64 cxx, I also heard that very recent Solaris compilers are 
usable ;)

They won't "upgrade" to gcc 3.1 (even most Linux/FreeBSD users won't upgrade 
until they install e.g. SuSE 23.1 and Mandrake 17 or FreeBSD 5.something ;) 
and still would like to compile and use KDE/KOffice. IMHO depending on one 
single compiler version (even if it's free) is not a very wise move.
 
> > Unless David bugs me with problems in the KOffice Library before 1.2 (or 
the 
> > Apache library is The Silver Bullet(tm)) I plan to get some work done on 
wv2 
> > again (in the "Word 8 (97) and newer" part of the code as noone seems to 
be 
> > using Word 7 (95) or older stuff anymore). Especially design wise there 
are 
> > some important questions to solve before any serious work should be done.
> 
> What I'm really hoping for is to combine ideas from wv2 and POI to make a 
> really good MSOffice access library.  Maybe this is unrealistic and I 
> should just accept the fact that we will have to have two competing 
> projects, wv2 and POI.  It's just that reverse engineering MS formats is 
> really tedious work, and I hope that it doesn't have be done more than 
> once.  Also, I'm concerned that Microsoft will make future office formats 
> even more obtuse in an attempt defend market share.

Ohh, misunderstanding there. If POI turns out to be an option for KOffice I 
plan to help them as far as I'm able to (bit-twiddling with Java sounds like 
a scary thing, but well). Only if using POI is not possible due to the issues 
outlined above we'll have to think about alternatives.

About MS "fixing" their format... well, I don't think they will do that. 
They'd have to fix Word first ;-)
 
> On the other hand, maybe having competing libraries isn't such a bad idea.  
> GNOME and KDE have done well - having two projects allows each 
> developer to pick the  project they like based on their preferences
> (C vs C++, C++ vs Java, GPL vs Apache).  If we could work on sharing 
> documentation it would go a long way.

In this case I really think one working implementation should make all users 
happy. You can't choose different styles, icons, or file dialogs for the 
backend anyway :-)
 
> This license issue is really thorny, and the Apache folks haven't been too
> responsive to fixing it so that it works under the GPL.  I find it most
> highly ironic that under the Apache license I could exploit the project 
> by forking a proprietary version of the code, but I can't use with a GPL 
> project, even though I would be giving back to their project.  It is 
> unfortunate, because the Apache foundation could fix their license by 
> making Apache a trademark and issuing a separate trademark license, much 
> like what AbiWord does.
> 
> Also if we use wv2, then we could use a C++ port of the POI OLE library 
> that we started.  That is if the C++ translation from Java is not covered 
> by the Apache License.

Hmm, I really wonder why everybody is trying to rewrite the OLE part of wv2 ;)
Right now we're using a thin (but comfortable) layer on top of the libole2 
library. This library does everything we need for import and export. Up to 
now I only found one bug in the small block handling on writing, but there's 
a workaround available. Michael Meeks recognized that there's a bug (he added 
it to his TODO), so it should hopefully be fixed at some point.
The dependencies are also minimal (we "ship" a current libole2 and a mini-glib 
version, a few KLOC of C code).

Ciao,
Werner
____________________________________
koffice mailing list
koffice@mail.kde.org
To unsubscribe please visit:
http://mail.kde.org/mailman/listinfo/koffice
[prev in list] [next in list] [prev in thread] [next in thread]