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

List:       koffice-devel
Subject:    Re: Re: [Karbon14] Re: Re: Re: misc
From:       Nicolas Goutte <nicog () snafu ! de>
Date:       2002-10-29 17:25:53
[Download RAW message or body]

On Tuesday 29 October 2002 14:02, Dirk Schönberger wrote:
> > No, he is meaning that you can use EPS as *picture* in KWord/KPresenter.
> > (Sure, mostly you get a pixmap.)
>
> AFAIK a picture is non-destructive, ie. it doesn't destroy the vector data
> 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 and 
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 done 
all the "unified picture" stuff, because it was not intuitive that EPS is not 
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 original 
EPS file each time when a re-scaling is needed. (If it is a MS-DOS EPS file, 
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 "picture",
> and vice versa?

That is what Shaheed had proposed to do between cliparts (QPicture, WMF or 
SVG) and Kontour. It has never been done, but I still think that it would be 
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 box for 
whatever KOffice program that uses it. The real work is done by the 
KoPictureBase-derived classes (for example KoPictureEps.)

Such a KoPictureBase-derived class can be based on anything. You just need to 
be able to load the picture from a QIODevice, draw the picture on a QPainter 
and extract a QPixmap out of it. Saving is simple, as we save the exactly 
what we have loaded (except for MS-DOS EPS files, where we only save the 
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
[prev in list] [next in list] [prev in thread] [next in thread]