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

List:       koffice-devel
Subject:    Re: karbon, kpainter and kword
From:       Dirk_Schönberger <dirk.schoenberger () sz-online ! de>
Date:       2003-06-13 17:27:54
[Download RAW message or body]

> > Unfortunately this is currently only in the concept phase...
> >
> And what are the concepts? :-)

Not much more that KPainter should have the following additional methods

void drawText (KText *)
void drawGlyph (int code);
void drawChar (QChar &char);
void drawString (QString &text);
void setFont (QFont &)

which are mapped to backend operation (pdcDrawGlyph, pdcDrawChar,
pdcDrawString)

- KPaintDevice should get a new paint device capability (supportsString)
- the text output function should use the current transformation matrix, so
that you could do calls like

KPainter kp;
kp.translate (100, 100);
kp.rotate (30);
kp.moveTo (100, 100);
kp.drawString ("Hello world");

Sub classes from KText (itself a KPainterElement) should implement special
text model, like the SVG Text Model or the Adobe Illustrator text model.

thats all, basically

> > If KPainter is to be used wider in KOffice it is strongly suggested to
> > implement another paintdevice for scrren output. Libart based client
side
> > rendering is fine for static display, but for faster high quality output
> > something like a Xr/Xc/Xrender paint device would be really useful.
> > Another victim of limited resources, I suppose...
> >
> Would it matter in a program such as KWord?

I would think so. Karbon uses a libart based rendering and there is a reason
there exists the wireframe mode, which use plain qpainter.

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]