[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 18:57:41
[Download RAW message or body]

On Sun, Dec 01, 2002 at 07:32:19PM +0100, Dirk Schönberger wrote:
> > > Do you think it would be worthwhile to work for a better imaging model
> in
> > > KOffice?
> > > For purely graphical elements (vector paths) the code in koffice/karbon
> > > could be used, but I think the text functionality is not quite up to par
> of
> > > e.g. KoText.
> > > IMHO this would mean KOffice specific graphics code, so that the current
> > > QPainter based graphics should be abandoned.
> > > Instead a more powerful imaging model should be supported, similar to
> things
> > > like
> > > Postscipt/PDF/SVG, Java2D or gnome-print.
> 
> > Is it really the QPainter API that is the problem or is it the
> > backend bound to it?
> 
> I think it is the QPainter API that is the problem. QPainter provides no
> easy way to express things like
> - vector paths
> - complex fill algorithms like procedural patterns, gradients and the like
> - transparency effects
> 
> There is simply no way to express it in the API. If I cannot express it, is
> is of no use if it could be possible for a backend to generate appropriate
> code.
> 
> Example:
> 
> QPainter has a method setColor (QColor), and a method drawBezier() (IIRC)
> What I would like to see is something like setColor (VColor), where VColor
> has an opacity property, which is used for setting transparency effects.

As far as I can see QColor uses QRgb for color storage, which in
turn can hold an opacity value (alpha channel) ?

> What I also would like to see is full vector path composing methods, like
> 
> VPainter painter;
> painter.moveTo(10.0, 15.0);
> painter.curveTo(10.0, 15.0, 20.0, 30.0, 20.0, 30.0);
> painter.lineTo(30.0, 100.0);
> painter.closePath();
> painter.setClipPath();
> 
> If these methods (and others, as appropriate) are defined in the frontend,
> it is more or less possible to create this behaviour, with some effort also
> using QPainter calls as a backend.
> If it is not defined in the frontend, there is just no way to get such
> behaviour.

Ah, I see. I guess for extending the API one could indeed create a
new painter class that inherits from QPainter and uses the paint
device command space (everything > QPaintDevice::PdcReservedStop) to
pass the extended functionality to a backend?

> > Did you consider writing a new paint device that generates the
> > output you want? While probably still a hell of a lot of work I
> > could imagine that it is less work than changing existing code to
> > not use the QPainter API anymore.
> 
> What I would like to promote is a new way of writing things (not really new,
> things like Postscript operators exist for how many years?) to screen or
> printer.
> As long as we have no quick backend for these, and a not stable API, I think
> it would be better if this API is used only on the places where it is
> absolutely needed, like in koffice/karbon, KSVG, and some SVG renderers,
> perhaps in KOffice (like e.g. KWord)
> Later, if better backends become available, like as part of the XRender
> extension in XFree, more parts can use this API.
> 
> A QPaintDevice can just create proper code for the operators QPainter
> supports.
> If the QPainter operators become insufficient, QPainter has to be extended
> (hopefully something like
> 
> class KPainter : protected QPainter

(why protected inheritance?)

> {
>   ....
>   public:
>     void moveTo (double x, double y);
[...]

Right, this is why the QPainter <> QPaintDevice couple is
extensible.

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.

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]