[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-12-01 18:32:19
[Download RAW message or body]

> > 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.
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.

> 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
{
  ....
  public:
    void moveTo (double x, double y);
    void lineTo (double x, double y);
    void curveTo (double x1, double y1, double x2, double y2, double x3,
double y3 );

    void setClipPath();
    void resetClipPath();

    void drawPath();
    void strokePath();

   void save();
   void restore();
}


For a full list of proposed operators see koffice/karbon/render/VPainter.
The current VPainter doesn't use a QPainter/QPaintDevice based architecture,
which makes it rather difficult to extend the API e.g. to printing to PDF.
This is what I would like to tackle at first.


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]