[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: QPainter and multi-component beziers
From:       Lauris Kaplinski <lauris () kaplinski ! com>
Date:       2003-03-10 15:26:11
[Download RAW message or body]

Hello!

On lun, 2003-03-10 at 16:53, Dirk Schönberger wrote:
> KPainter tries to keep API level compatibility to QPainter, currently at
> least at graphical primitives /drawPolyline, drawPolygon and the like)
> I need more feedback for things like text output, font rendering,
> pagination, Postscript output and the like, because I don't have much need
> for these features in my work, so they are defined rather sparsely.
> 
> Basically you could try to "convert" an application to KPainter by
> exchanging any QPainter calls with KPainter, to see at least what API is
> needed. If a QPainter method is missing in KPainter, it should included in
> KPainter, hopefully with a nice implementation using the KPainter paint
> device calls... For "interesting" features, like text rendering, an
> extension of the device operators would be ok, I am open for suggestions.
> 
> I agree that a QPainterPaintDevice should be implemented next.

Hmmm... my serious suggestion is - do not try to invent single API,
covering onscreen and printer rendering. IMHO Windows, Qt, StarOffice
and probably many other have shot themselves to leg by trying to
do that.
There can be common frontend, of course, for apps with simpler needs,
but keeping separate specialized rendering API-s IMHO deserves
extra effort.

Other than that, if I'll find a little spare time, I'll try to
write down my ideas about text API. This got halfway implemented in
gnome-print, but AFAIK no application ever used it. But I still
believe it is The Right Thing to do ;-)

Best wishes,
Lauris Kaplinski


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]