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

List:       koffice-devel
Subject:    Re: KOffice filters revisited
From:       Thomas Zander <zander () planescape ! com>
Date:       2001-09-07 17:39:16
[Download RAW message or body]

On Wed, Sep 05, 2001 at 11:53:19PM +0200, Werner Trobin wrote:
> Nicolas Goutte wrote:
> > 
> > On Tuesday, 4. September 2001 23:49, Thomas Zander wrote:
> > > Hmm, I remember that this was not a good idea because it won't get
> > > you very far.
> > > The user gets his document converted a number of times before it
> > > hits the right filter which can make the desired format. This will
> > > cause losses which are probably to great for any normal usage.
> > > I don't think the solution of piping filters will help anyone beond
> > > being able to read it (a bit). So basically I don't see an advantage in
> > > working in that direction if the real (from a users POV, only) solve
> > > will in the end be to have a dedicated filter anyway.
> > 
> > Yes. I second that.
> 
> Well, but we also don't lose anything, do we? We only gain the
> possibility to have filters for file formats we didn't write a
> native filter for.

True, and I really like that, but my fear is that having multiple 
conversions will make the output worse. And all I am saying is that
the press _will_ flame you more for bad filters then for not having
filters.

It also make the process less tranparent, I can curse at SuSE now 
since the KOffice 1.1 release of them does not open a .doc file, 
but what do I have to do to open that excel file like my collegue 
does? Install perl, lots of perl modules etc...

> There has also been some discussion at the LWCE about agreeing
> on a few "standard" XML DTDs with the guys from OpenOffice and
> GNOME Office which all apps can read/write and create filters
> only to convert foreign formats to this "standard" DTD and from
> there only have one "path" to the app. This wouldn't be possible
> with the current engine, e.g.

Yes, we are working on that, and you misunderstood one thing, its a
file format for the office applications itself, not an intermediate
format that would need your filter approuch.

So one filter would convert to this standard XML, and the applications
would take the tags they understand to read that. This approuch actually
is not that hard to design and would allow much more then just having
more im/export filters.

-- 
Thomas Zander                                            zander@earthling.net
The only thing worse than failure is the fear of trying something new

[Attachment #3 (application/pgp-signature)]
_______________________________________________
Koffice-devel mailing list
Koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel


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