[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:       Simon Hausmann <hausmann () kde ! org>
Date:       2002-12-01 22:12:28
[Download RAW message or body]

On Sun, Dec 01, 2002 at 10:38:55PM +0100, Dirk Schönberger wrote:
> extended
> > > (hopefully something like
> > >
> > > class KPainter : protected QPainter
> 
> > (why protected inheritance?)
> 
> I would like to provide a clean separation between the "old" API and the
> "new" API.
> The new API should be based on the Postscript imaging model, including its
> coordinate origin different from the default QPainter (lower left corner
> instead or upper left corner) and its different coordinate model.
> QPainter uses a IMHO rather too complex transformation model with its wordl-
> and viewport coordinates, and its integer coordinates, where affine
> coordinate transformations are rather a backthought.
> Instead I would prefer that affine transformations (and the appropriate
> transformation matrices) are part of the render API. The coordinates should
> be floating point and based on a fixed 72dpi (I believe) display.
> Again, this is modeled after the Postscript imaging API, which is also used
> in SVG and PDF. I hope this would create some confidence to the newer API,
> so that it could be easier memorized / used.
> There should exist methods which provide similar functionality than
> QPainter, perhaps modulo the other coordinate space.
> Other methods, like  drawWinFocusRect () or qDrawShadeLine (  ),
> are rather widget oriented and are IMHO current not needed in a WYSIWIG
> context.
> The whole world/iewport model I would like to either abandon, or or emulate
> them with manipulations of the current transformation matrix.

Well, if you inherit from QPainter protected there is no point from
inheriting from QPainter at all then. The point about inheriting
from QPainter is not the implementation (the way it calls cmd on the
external paintdevice) but the API.

> > My point is that I believe it is much better to re-use the existing
> > QPainter API and extend it if necessary instead of starting a new
> > painter API just from scratch. There is much code written using
> > QPainter, developers are used to it.
> 
> I am not quite sure if a "hybrid" rendering API between original QPainter
> and a more Postscript rendering model would be positive. You would have to
> relearn a new API and have nothing already known.
> I think that there exist some resources which teach programming in
> Postscript / PDF / SVG ways.
> 
> Beside, you would have to implement new PaintDevices for the new API.
> So, instead of implementing only the new operators, you would also have to
> implement the old operators. I hope to be able to re-use implementation of
> libart-based anti-aliased and QPainter based not anti-aliased painters in
> Karbon.
> These only support the new style API.

Let me give you a nice counter example why a QPainter compatible
(derived at best) API is so important IMHO: Imagine there would be a
KoPainter that inherits from QPainter. KoDocument could be adjusted
to pass a KoPainter to the virtual draw functions that koffice
applications have to re-implement. Now imagine you go through the
work of implementing a new paintdevice maps the QPainter API to say
the SVG rendering model. You do that one, and immediately all
koffice applications would get the additional ability to output SVG.
Abstraction at its best ;-)

The postscript printer in Qt shows that it is possible to map the
QPainter API to things like the postscript rendering model.


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