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

List:       koffice-devel
Subject:    wvWare 2
From:       Werner Trobin <trobin () kde ! org>
Date:       2001-05-26 15:18:00
[Download RAW message or body]

Hi!

As you all probably already know Dom Lachowicz suggested on
dot.kde.org that we should collaborate to make WinWord import
and export work as good as possible. Dom, the current maintainer
of wvWare, said that he plans to totally rework the current
wvWare codebase and create a 2nd version of it.

We met on IRC and came to the conclusion that our thoughts
about such a library are not very different. Therefore I'd
like to start a discussion and design phase and I'd like to
kick off with a few very basic questions (attached). Feel
free to add questions, answer them, and so on.

If you'd like to join us please create a sourceforge account
and ask Dom to add you to the developers.

For the KOffice-Devel people: If you are interested in discussing
that topics please go to www.freedesktop.org and join the xdg-list.

Ciao,
Werner

-- 
Werner Trobin - trobin@kde.org
["questions" (text/plain)]

Some questions regarding the design and implementation of the new wvWare
library. Nowhere near complete, feel free to add/remove/correct them.

1) Which programming language(s) do we want to use?
   Dom suggested to use C++ and provide a C interface for the most common
   functionality.
2) Which libraries can we depend on?
   We surely need a library for XML processing and as GNOME and KDE already
   use libxml2 I suggest using it.
   Next we will need libole2 to read/write OLE storages. The small problem
   we face is that libole2 depends on tiny parts of Glib according to Dom.
   He suggested to use his mini-Glib if Glib (with the correct version) was
   not found. We'll need some auto* magic to do that.
   We will also need libwmf and probably some other small image related libs.
   Our goal however should be that we don't create a nightmare for packagers
   with our dependencies.

Open Questions:
- How are we going to represent Unicode strings within the library?
  STL strings? (related: is iconv portable? I heard of some problems on
  FreeBSD)
- Which platforms our code has to run on? Endianness problems? iconv (FreeBSD)?
- What formats do we want to support for reading and which one do we plan to
  write out?
- What to do with embedded images, vector graphics, other MS Office documents,
  stuff like embedded .dxf (AutoCAD) pictures,...
- Do we want to run the filter as separate process or do we want to dlopen the
  library on demand and run it in-process? If we run external, how to we want
  to communicate?
- Are we able to communicate with the calling process/method to signal
  progress?
- How do we request information from the user (e.g. a password for the file)?


Design:
I really don't know how the current wvWare library is designed, and I think
I'll leave talking about that to Dom :)  The basic design of the current
KOffice winword filter is described in: 
http://kdewebcvs.nebsllc.com/cgi-bin/cvsweb.cgi/koffice/filters/olefilters/winword97/README?rev=1.5&content-type=text/x-cvsweb-markup



_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel


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