> The basic rendering in Qt / KDE exists in the form of a QPainter / > QPaintDevice framework. > The KPrinter is a special QPaintDevice, like QWidget, QPrinter a.s.o. It is > used to proxy to multiple > printing queues, like LPng, CUPS a.s.o. Internally it uses an hard-coded > Postscript generating paint device. > > So in order to integrate your PDF code generator, I suppose you have the > following options: > > - implement a pure PaintDevice (inherit from QPaintDevice and wire the > operator implementations) > Doing so would require application developers to explicitly call their > renderings with your paint device. I suppose > this could be done via a standard action in an application GUI? > > - make the generator in KPrinter changeable and provide your PDF generator > as some kind of special printer > queue. This would involve changing KPrinter source code, I suppose. As explained, you need a QPaintDevice implementation that produces PDF code in the QPaintDevice::cmd function. Plugging this into kdeprint needs some code arrangment, but not that much, as the KPrinter object redirect all the drawing commands to an internally created QPrinter used simply as a PS generator. So it's only a matter of replacing that internal code generator. So if you come with a fully-featured QPDFPrinter class (inheriting from QPaintDevice), then integration should be pretty easy. But the main point IMO is then to define a common printing interface that a potential backend would implement. Michael. > > Hope this helps, > > Regards > Dirk > > > > >>>Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << -- ------------------------------------------------------------------ Michael Goffioul IMEC-DESICS-MIRA e-mail: goffioul@imec.be (Mixed-Signal and RF Applications) Tel: +32/16/28-8510 Kapeldreef, 75 Fax: +32/16/28-1515 3001 HEVERLEE, BELGIUM ------------------------------------------------------------------ >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<