On Tuesday 29 October 2002 14:02, Dirk Sch=F6nberger wrote:
> > No, he is meaning that you can use EPS as *picture* in KWord/KPresent=
er.
> > (Sure, mostly you get a pixmap.)
>
> AFAIK a picture is non-destructive, ie. it doesn't destroy the vector d=
ata
> which is used to render the image.
> On the other hand it is non editable, because you have no way to change=
 the
> vector data.

Yes! However, you can save the image, modify it in an external program an=
d=20
insert it again in the document (by changing the picture.)

>
> There still exist the QPicture, containing the calls to the render API
> which were used
> to render the image? This meta file can later be replayed on another
> QPainter.

EPS does not use QPicture but QImage. That is the main reason why I had d=
one=20
all the "unified picture" stuff, because it was not intuitive that EPS is=
 not=20
a clipart for KWord/KPresenter.

>
> Is a KWord picture more sucha meta file, ore merely a QImage where the
> ector data, like EPS, isn't discarded?

As just written it is basically a QImage, however re-scaled from the orig=
inal=20
EPS file each time when a re-scaling is needed. (If it is a MS-DOS EPS fi=
le,=20
the preview included in the file is not used at all.)

>
> Would it be useful to be able to "export" a Karbon document to a "pictu=
re",
> and vice versa?

That is what Shaheed had proposed to do between cliparts (QPicture, WMF o=
r=20
SVG) and Kontour. It has never been done, but I still think that it would=
 be=20
interesting (Krita could be used for non-vector formats.)

>
> Would it be possible to use the IMHO more powerful rendering model of
> Karbon for other Office applications? This could mean that that Painter=
 API
> should be extended, because it is not really complete?
> This would also allow that a KWord picture could contains calls for the
> more advanced VPainter API instead of the current QPainter API (if it
> really is a QPIcture)

I think that it could be possible. The class KoPicture is only a black bo=
x for=20
whatever KOffice program that uses it. The real work is done by the=20
KoPictureBase-derived classes (for example KoPictureEps.)

Such a KoPictureBase-derived class can be based on anything. You just nee=
d to=20
be able to load the picture from a QIODevice, draw the picture on a QPain=
ter=20
and extract a QPixmap out of it. Saving is simple, as we save the exactly=
=20
what we have loaded (except for MS-DOS EPS files, where we only save the=20
PostScript stream.)

>
> Regards
> Dirk

Have a nice day/evening/night!

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

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