[Kde-graphics-devel] Status update

[Dirk Schönberger]

> I believe I see what you mean: you want to be able to have different
backends
> so you can print to PS, PDF, etc... ie: what Arthur should allow. It's
okay
> to use libart for images, but you want to have non-image destination
devices.

non-buffer devices, but otherwise, yes.

> In this case it would be best to do an Arthur backend but I really don't
see
> this as a good solution. It's too tied to X11 pixmaps and drawables. All
the
> pixmaps used in things like brushes are the most obvious, but QFont is a
> problem too if you want to render text directly to the image.

If you use the KPainter frontend, you don't really see the Arthur
implementtation details, at least so is the theory.
The primitives KPainter provides should be complete (otherwise the API
should be extended, not the implementation details made public)

> Basically, in my ideal world I would be looking for this: I first believe
> people will want to use pattern lines and fills so I would want good image
> brushes. Not pixmaps

If you are right with your assumption that in using QPixmaps I cannot
guarantee 24/32 bit flat image buffers without quality loss, I tend to
agree.
Basically I see the following fill types

- patterns, basically QImages, bitmapped data
- gradients, basically algorithms which describe how a path is filled.
Currently KPainter only contains SVG style linear and radial graients, but
it
  would be nice to have complex gradients (eg. Adobe Illustrator / PDF
gradient meshes)
- vector fill patterns - by a callback mechanism you can use rendering API
calls to fill a "container" path. Currently not really implemented
- hatches - a special kind of monocolour pattern which only contains out of
vertical or horizontal lines

> I would also like to have the text rendered directly to a BGRA or RGBA
image. This would mean using freetype directly, (there is a
> lot of example code for this all over the place), and possibly t1lib.

KPainter (or at least its libart backend), contains some code which uses
freetype to render text. This is just a proof of concept, I am not quite
happy with the current state. I think the text model is to simple (I would
need at least typographic and mass texts), and it is possible not Unicode /
I18N clean. Unfortunately Qt4's text engine is rather close coupled to
Athur, I think.

> With all that work already there is no way I'm not going to utilize
libart...
> That is if I do a painter at all - I'm just throwing ideas around ;-)

Nobody said you shouldn't. For a bitmap editing application a directly
accessible image buffer is a must, no doubt in that.

> I looked around for the Arthur PostScript backend and wasn't able to find
it.
> Do any of you know what file it's in or if it's complete?

I found a qpsprintengine_p.h and related files in beta 1, which should
contain the PS generator. I think in the Linux / Open Source version
printing is limited to Postscript generation. I haven't looked about its
capabilities, yet (basically, Postscript is not able to render opacity,
transparency effects correctly, so there may be some limitation in its use)

> I kind of figured
> that if I kept the API similiar you'd be able to use the new painter for
your
> images and Arthur for printing, PS, and PDF. I just don't believe I can
use
> Arthur for images for the reasons I mentioned. I would prefer if I could.

Unfortunately I differ in some design decisions from Arthur. I would like to
implement a state based rendering API similar to Postscript, while in Arthur
the render state is rather limited. So there are some major differences
between Arthur and KPainter, I think.
The public frontend API should be similar, at least on the level of Qt3's
painter.
It should be possible to implement a Arthur based backend KPainter, I am not
so sure about the opposite.

But for now KPainter is in hibernate mode, because it currently has no
users...

Regards
Dirk