(As i have not much time, I am answering to a few emails in one.)

I am not in favour of another application in KOffice, especially one wher=
e=20
there would be only one developer.

We have already very few developers and we have already had the case that=
 we=20
have to close an application (Kontour) because the maintainer has been lo=
st=20
(other examples: KWord's ASCII and HTML filters before KOffice 1.1 and th=
e=20
RTF import filter before KOffice 1.2)

Out of lack of information, I thought that Scribus was more a library. So=
rry=20
to have misunderstood.

(It is sad that it is only GPL, because that would make the printing libr=
ary=20
GPL. However, in that case, we could take QT's to make something out of i=
t.)

I am also not in favour of splitting KWord in WP and DTP. On contrary, it=
=20
could be its strength to cover both sides. We should try to remove the mo=
des=20
(or at least to downtone them, so that they look as options that we can=20
switch any time.)

This is also about the position of KWord. OpenOffice already covers WP.=20
Scribus seems to cover DTP. If KWord (or KOffice) immitates one of both, =
we=20
will have nothing new.

The sad result out of it is that we probably need to start to take care a=
bout=20
PostScript generation ourself. (Sigh!)

Have a nice day/evening/night!

On Sunday 01 December 2002 00:29, Sean McGlynn wrote:
> On Saturday 30 November 2002 21:37, Dirk Sch=F6nberger wrote:
> > One of the things I absolutely don't like about the "professional" DT=
P
> > applications is their non-sharing attitude and their
> > non-interchangeability, i.e. all applications are specialist tools, b=
ut
> > the general useability, like common file formats,
>
> The native Scribus file format is XML based, liked any KOffice app, so =
that
> wouldn't be a problem.
>
> > common clipboard exchange,
>
> Scribus has a compile-time option (I think) to support drag and drop wh=
en
> running with KDE. I guess that means it uses the XDND standard. As a Qt
> app, I guess its clipboard features are similar to (or easily changeabl=
e
> to) those of KDE apps.
>
> > common clipart/graphics support,
>
> I don't think that's a problem and I'm sure Scribus would improve in th=
is
> area if it were a KOffice app.
>
> > common GUI ..., is non-existant.
>
> Even as an existing Qt app, Scribus can look just like a KDE app (I've =
seen
> the piccies of it using the Keramik style :-)
> Of course, if it "were" a KDE app then that point is irrelevant.
>
> > Somehow I don't have the impression that the Scribus authors are
> > interested much in this direction. This make it rather difficult as a
> > KOffice component, at least IMHO.
>
> Got to say that I disagree with you here Dirk. From my
> (non-KOffice-developer
>
> :-) point of view, I think Scribus would fit perfectly into KOffice as =
a
>
> dedicated DTP component. I know there's some overlap with KWord's featu=
res,
> but I'm sure a little bit of refactoring could sort that out. Of course=
 I
> could be totally wrong in all this; it's just my personal impression. I=
t
> might also be the case that if a native KDE version of Scribus was to b=
e
> created, it would be better as a standalone app rather than a part of
> KOffice.
>
> Naturally all this discussion is moot if Franz Schmid isn't interested =
in a
> KDE version of Scribus and no-one else is interested in creating a port=
=2E
>
> > Regards
> > Dirk
>
> Cheers,
> Sean

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