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

List:       koffice-devel
Subject:    Re: Explanation on WP vs DTP modes in KWord (Re: Kde-cvs-digest request for information)
From:       Dirk_Schönberger <dirk.schoenberger () sz-online ! de>
Date:       2002-11-30 22:42:54
[Download RAW message or body]

> Yes, sure, you can save it. Otherwise, it could not be in a KWord file.
But
> only in its own format (in a few QT sub-versions) and in SVG. (I do not
know
> the quality of the SVG output.)

Somehow I think that the SVG support is more marketing than anything else.
From what I understood, QPicture is a meta file format, i.e. a serialization
using C++/Qt of the different operators/methods in QPainter. "Semantically"
I think it is similar to WMF, but WMF is rather unfashionable, these days. A
meta file works via an "engine". SVG is more "entity" than "engine" based,
again IMHO.

The main idea for a meta file format is to be able to express all features
of a given rendering API. Most exchange formats define their own rendering
model, which make them more or less incompatible with the target rendering
API.
Unfortuantely most meta file formats are not especially human readable.

> However while looking at the code, the trick is to use QPicture::play on a
> QPaintDevice, which could be a generator for another file format. However
it
> seems that you would need to use many public but undocumented features.

> I have the felling that you are going to write: "But then we can decode
it."
> Well, perhaps.

Technically it should be possible to decode it. I somehow doubt that it is
useful.
The QPainter imaging model is not the world's most powerful model...

> Any volunteer for a QPicture to Karbon filter? (As for a mime type for
> QPicture, it could be for example "image/x-vnd.trolltech.qpicture")
This could be rather difficult, I think. Karbon is semantically similar to
SVG, at least with its current functionality. This means, it uses a more
"entity" based approach with a Postscript / SVG like imaging approach.

My idea would be to use Karbons API (VPainter), and build a proper
frontend-backend separation, so that it is possible to build VPainter
PaintDevices, e.g. a meta file format (something like VPicture :)
A converter of QPicture to VPicture _could_ be somewhat easier to implement,
at least if VPainter is extended to be a superset of QPainter.
I think the Postscript rendering model needs some extensions at the transfer
functionality (QPainter ROP), to be compatible.

Regards
Dirk







_______________________________________________
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]