[Kde-graphics-devel] Status update

Mosfet dan.duley at verizon.net
Mon Jan 3 23:56:12 CET 2005

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. 

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. 

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

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 ;-)

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

On Monday 03 January 2005 02:28 pm, Dirk Schönberger wrote:
> The problem with a direct coupling to libart is that you are limited to
> buffer based rendering.
> No way to e.g. create PDFs or print to a printer, or you may want hardware
> acceleration, or...
> This may be enoug for a rendering API which is only used internally in a
> paint app, but already for a vector graphics editor
> and even more for a general purpose rendering API it is definitly useless.
> Regards
> Dirk
> _______________________________________________
> Kde-graphics-devel mailing list
> Kde-graphics-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-graphics-devel

More information about the Kde-graphics-devel mailing list