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

List:       koffice-devel
Subject:    Re: [flake] Unit based flakes
From:       Dirk_Schönberger <dirk.schoenberger () sz-online ! de>
Date:       2006-04-29 12:10:08
Message-ID: 015201c66b85$e3d2c020$14b2a8c0 () rincewind
[Download RAW message or body]

> > I still think application dependent rendering models are bad. This is a
> > nightmare for integration, because each
> > application renders slightly different. I would much prefer a general
> > rendering model, i.e. someling like all
> > application follow e.g. the PDF rendering model (and corresponding
> > graphics primitives)

> I'm not sure I follow; flake is a KOffice wide rendering model and we will
> put as much stuff in the libraries as we can; so you can expect a KoShape
> based object in the KoText library which means that both KWord and
> KPresenter will render this stuff exactly the same.

Perhaps I am nitpicking, but for me Flake doesn't sound like a rendering
model, but more like a "graphical component" system.
(normally I would call this canvas / scene graph model), but this does not
really apply to Flake.
A "component system" handles things like interaction / event handling /
dirty region management (you don't want to re-render your whole document
just because a small part was changed)

The actual rendering is left to an actual rendering system, in your case
QPainter / QPaintDevices.

Modern rendering models (i.e. things like Apple Core Graphics, PDF, SVG and
such) seem to do a "managed" approach for rendering.
If a containing context specifies that it wants it stuff rendered scaled
down to 30%, this setting is mandatory.

Your approach seem to be that the actual context (i.e. stuff like the
current transformation matrix CTM, which contains current scaling) is stored
somewhere, but the contained context (i.e. the Flake object) can decide what
it wants to do with the information. It can do the scaling itself, it can
scale using the renderer, it can ignore it altogether, or there may be other
strategies.
I think this is a source of errors and inconsistencies.
If e.g. a component is more focused to screen rendering (low DPI, high
interactivity), I am rather lost if I want to use a output only device
(printer, PDF file generation)

Regards
Dirk



_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]