> I think the problem is that we need more control at print level. As long
as we
> do not have it, I do not think that abandonning QPainter makes much sense,
as
> you need it again for printing.

I would also like to have more control at the display level. I would like to
see Postscript style vector paths (more info on demand) with floating point
coordinates
as basic graphics primitives. This contrary to the Qt/X/Windows GDI style
polygons
with integer coordinates.
If you manage to do text output via vector paths (i.e. accessing the
outlines of Adobe T1 and Truetype fonts directly, vs. rendering them to an
image), you have full
typographical control at print level (for speed reasons I think it would be
feasible, if you can whole chunks of text render directly to Postscript,
instead outputting their outlines)

If we can provide a QPainter "backend", i.e. something which translates
vector paths and transformation matrices to "dumb" polygon calls, I think it
would be possible to re-use the existing QPainter based infrastructure (but
I would be ery pleased if it would be possible to generate PS code from
vector paths, i.e. a 1:1 transformation, without QPainter-style data
mangling)

> (But do not forget: we need to use QPicture in a way or another for
> compactibility to KWord/KPresenter 1.1. That makes it pretty hard to
discard
> QPainter.)

I had the impression that KOffice used its own KoPicture, instead of
QPicture,
i.e everything was rendered directly to an bitmap/image, instead of to some
kind of Metafile?

Regards
Dirk





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