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

List:       koffice-devel
Subject:    Re: OASIS file format for Krita
From:       dirk.schoenberger () sz-online ! de
Date:       2004-03-22 12:13:37
Message-ID: 57977.217.80.144.23.1079957617.squirrel () webmail ! sz-online ! de
[Download RAW message or body]


>> - Its rendering model is limited to that of QPainter, i.e. basically
>> integer coordinates, pixel wise access and explicit transformations.
>> So you cannot simply create a more featureful rendering system
>> (basically
>> something used in Karbon14/KSVG/KPainter - floating point coordinates,
>> implicit transformations for image and vector data)
> Yes. But surely one could have a KPainter-like rendering model draw into
> a QPainter, no? In the end you still get to pixels...

Not really. KPainter allows for client side rendering, i.e. in order to
screen you only need the bitblit from QPainter. The actual client side
rednering was done by libart.
YOu may also use a QPainterPaintDevice directly. If you use this, you
trade speed for quality of rendering. The render commands are done
quicker, but you lose advanced features like antialiased rendering and
transparency / compositing at vector data level.
Whats currently missing is a PaintDevice which generates Postscript or PDF
calls without having to go via the dtaamangling part of a QPrinter.
QPrinter use leads to loss of data, because the floating point coordinates
and implicity affine affine transformations are "normalized" to the
QPainter model.

>
>> - Embedded documents don't know enough about their parent document. E.g.
>> if you embed a spreadsheet component in KWord, the embedded document
>> shows
>> a full KSpread document, when all you wanted would be a 10x10
>> spreadsheet
>> view / table grid.
> This possibly needs panning (see the thoughts file in kofficecore) and
> limiting the size of a kspread document.

And what about using the text rendering in KSpread? If all you want to do
is calculate in KSpread, the current features are fine.
If you want to print the data, I think you need the full layouting
features from, say, KWord, in KSpread.

>> - window/document/view framework - I think with the added concept of
>> tools and actions this would be useable also outside of KOffice, i.e. a
good
>> candidate for kdelibs.
> Maybe a very basic framework could make sense for kdelibs, but not the
> full-fledged
> koffice framework. The main requirement koView adds, compared to a simple
> "widget to view a document" is the support for zooming (and other
> transformations), which basically requires a real rendering model with
separation
> between the data (e.g. in points) and the result (in pixels). That's
what defines
> KOffice, and I don't see use for it in non-KOffice applications. E.g.
even in
> Kolourpaint supports zooming, surely it doesn't use points and double
> coordinates for its data. It doesn't embed other koffice components,
either.

So basically the features exist in KOffice (I would like to add rotation
and non-rectangular part, but hey), but they are not used in the
applications?
But I think Imixed things up again. I believe I was more thinking of the
undo-redo framework and the "tool" concept, i.e.  the possibility to add
handlers to mouse events as used in Karbon and KolourPaint, I believe)

Regards
Dirk

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