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

List:       koffice-devel
Subject:    Re: Explanation on WP vs DTP modes in KWord (Re: Kde-cvs-digest request for information)
From:       Dirk_Schönberger <dirk.schoenberger () sz-online ! de>
Date:       2002-12-02 10:43:20
[Download RAW message or body]

> > Theoretically you are right.
> > But I would like to tap the KPrinter functionality in KDE, i.e. being
able
> > to print to local and non-local printers via print queues. This means
that I
> > have to provide
> > a QPaintDevice.

> Haeh? I don't see the relation. Whether to print to a local printer
> or a remote printer makes no different in terms of the actual output
> to generate. It is merely an IO question, like telling the backend
> to store things to a temporary file or into a given buffer. Where's
> the relation to the QPainter<>QPaintDevice separation?

It is rather more difficult I believe. From what I understood (I had some
discussion with Michael Goffioul from the KPrinter framework) I have to
provide a QPaintDevice, which could be used instead of KPrinter's internal
PS Generator paint device. KPrinter does the actual management of selecting
the correct print queue.

> > QPaintDevice is most closely coupled to QPainter, both aren't useable
> > without the other. In fact I am not quite sure if I even have the chance
to
> > define new paint deice operators the way I would like to do. Time will
tell.

> The QPainter<>QPaintDevice API was specifically designed to allow
> extending it. See the PDevCmd enum in QPaintDevice and the overall
> design of passing commands through the cmd() dispatcher method.

I have also read the documentation ;) However when I played around with
QPainter/QPaintDeice inherited classes, I had somehow the impression that
this design decision was somehow forgotten, or there were other
implementation details of QPainter that made it difficult.
But this could equally be, because I just had not much experience in
extending QPainter.
OTOH I haven't seen much QPainter inherited classes which have extended
QPainters rendering functionality...

> > You can also render Postscript code using the GDI API. This doesn't mean
> > that the resulting Postscript code is useable.
> > QPainter is fine for normal windowing work, like GUIs which don't need
> > toprint out.
> > For serious graphical work, like in a WYSIWIG Office suite, the API is
too
> > limited.
> > Again, just IMHO...

> It would be interesting to hear say David's opinion on that, as
> someone who has really worked a lot with QPainter.

My basic model of (interactive) computer graphics (may be to simplified) is
that graphics can be divided in the following parts

- "vector graphics" - graphics which are built from graphical primitives
like polygons or Postscript vector paths
- "bitmap graphics" - images
- "text"
- rendering - is their a unidirectional or bidirectional relation between
render deice and canvas. If you have only a unidirectional relation, things
like compositing are just quite impossible, because you can't just ask the
canvas "give me the colour of the given pixel"

Unfortunately I am mostly interested in the first part of graphics. This
means I try to create some graphics out of primitives, where I need a
consistent and complete set of graphics primitives.
"text" can be implemented using "vector graphics", font outlines aren't
anything else than more or less Postscript vector paths.
Beside the actual "rendering" there are some other question in text
graphics, like positioning/typographical layout. This is the reason that
text is its own graphics category.

I think there is no coincidence that a application which tackles basic
vector graphics in KDE/KOffice, starts with its own render device (Karbon's
VPainter)
The first attempt (Kontour) ran into ugly problems and was discontinued
(again, just IMHO)

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]