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

List:       koffice-devel
Subject:    Re: Some random KOffice ideas
From:       Dirk =?iso-8859-1?Q?Sch=F6nberger?= <dirk.schoenberger () sz-online ! de>
Date:       2006-03-29 9:08:28
Message-ID: 57756.84.179.251.199.1143623308.squirrel () mail ! sz-online ! de
[Download RAW message or body]

> Hi,
>
> While looking at the latest Beta of KOffice 1.5, I was thinking a bit
> about the overall design of KOffice, embedded objects, and integration of
> multiple kinds of documents into one. Two ideas popped into my mind which
> I would like to describe below. Since I know very little about KOffice
> architecture, these ideas may be totally ridiculous and unrealistic but I
> wanted to post them anyway. You have been warned... :)
>

I will add some equally ridiculous and unrealistic remarks ;)
I think I have some general impression about KOffice, but it could be that
I miss some details.

> Idea 1:
>
> Could KOffice possibly use GNUPlot for creating data plots? It looks like
> KOffice is currently trying to re-invent the graphing-wheel.

From what I understood, KOffice is made of components, so it should be not
really complex to build a KPart which uses gnuplot for rendering.
Two possible problems

- what kinds of "documents" you would like to render using gnuplot?
KOffice seems to discrimintate on terms of MIME types (i.e.
application/rich-text, graphics/png a.s.o). Does there exist some
"application/gnuplot" MIME type, or makes this even sense?
- is gnuplot an application / executable you have to start (e.g. in a
console), or does there exist a library which exports the gnuplot
functionality? Calling an external application to render into a component
is rather problematic and should only be used if there exist no other
means.

>
> Maybe the output of GNUPlot it not hard to integrate into KOffice
> documents, because GNUPlot can render to various vector graphics formats,
> including SVG. I imagine the KChart part could use GNUPlot to generate
> an SVG graphics object and return it to the host application (KSpread,
> KWord, ...). The host application can freely render, scale and rotate the
> SVG graphics without having to call KChart to do this. Only when the
> settings of the graph change, or the data in the graph changes, a new SVG
> object needs to be generated.
>

The problem is that SVG is just another document format which is not
really integrated into KOffice.
The system which all KOffice components use is deeper, on the API level,
i.e. QPainter from Qt. Unfortunately QPainter (3) is makes tasks like
freely rotating, scaling and rendering sub-contexts unnecessarily complex.
QPainter from Qt 4 (which hopefully will be used by the next KOffice), is
slightly better, but still not complete.

> Also, it might be possible to allow the user to convert a KChart object
> into an ordinary SVG graphic. This can be useful for customizing a graph
> using a general vector graphics KPart (Karbon?).

The "normal" way would be to introduce a high level graphics API where all
graphical elements share the same space and build a complex tree of low
level elements (lines, bezier curves, images, text etc). This is called a
"canvas".
Unfortunately the requirements of the existing KOffice parts
(applications) to such a canvas are too different, so the idea was
skipped.

There is a new idea on work, which I unfortunately not quite understand
how it is supposed to work.

> Idea 2:
>
> Idea 1 resulted in a second idea, about integrating KPart objects in
> KOffice documents:
>
> It seems to me that it is difficult to achieve seamless integration of
> KPart objects into the host document, because neither the KPart (KChart
> for instance) nor the host application (KSpread for instance) knows what
> the complete document looks like. The embedded objects are seperate
> worlds on their own. Making the entire document, including KPart objects,
> look like one consistent Work of Art can be a bit of a challenge. Getting
> operations like scaling of objects work smoothly can also be tricky, I
> suppose.
>
> (Please correct me if the above is not accurate)
>

I think these are limitations of the current approach which are worked on.

> The idea is to solve these issues by making sure that the host application
> knows how to render the entire document, *including* the embedded objects.
> The only thing the host application has no knowledge about is how to edit
> the embedded objects. This is left to the responsible KPart.
>

The problem is that the rendering API which is used (QPainter), provides
no implicit context, where the part can access information about where it
is supposed to be rendered. Think things like current Zoom level, current
rotation.
These informations have to be provided by some kind of API, and they can
be ignored at will. There is currently no real way to enforce this
context.
Additionally, each document has its own "coordinate system". For a table /
spreadsheet component like KSpread it makes no real sense to define its
space in terms of big rectangular boxes like a word processing component.
Instead it uses its own coordinate system out of sheets, rows and columns.
There exist no general way a container application (say the word
processor) can determined how big the contained application is to be.
Each system to translate between these two coordinate systems has to
assume things like the used font and line breaking rules, where the
assumptions are not necessarily the same between container and contained
object.

> Since KOffice is now using the XML-based Open Document format, how about
> the following approach:
>
> * All KOffice parts present their content by outputting XML or SVG data.
> In any case something that can be rendered without knowledge about the
> KPart that generated it.

This makes no real sense. XML data contains no information about how it is
to be rendered (that is left to specific XML formats like SVG)
SVG is a rather complex file format, which is only basically supported in
KDE (cf KSVG), but not in KOffice. Especially SVG is not a "native"
format.

> * The host application will request the XML/SVG data of an embedded object
> only once, and use it to render the object when needed. Updated XML data
> of an embedded object is requested whenever the embedded object has been
> edited by the user.

An alternative would be the use of a meta file format, i.e. a a file (or
stream) which contains a sequence of operations which are needed to render
the embedded object.
Unfortunately the current QPainter is not really suited for such a file
format (because of the missing context I mentioned above) It is not really
possible to "nest" the rendering of embedded components, because each
componen has to set its render context itself. This is error prone and
leads to inconsistent output.

> * All KOffice parts use the same KOffice-wide XML data rendering engine to
> render the XML data to screen or printer. The rendering engine does not
> know which KPart generated the XML/SVG data, it can render it completely
> on its own.

In theory this task should be executed by the used rendering API, i.e.
QPainter.
In practice this works already and is implemented as such, but with
limitations.

> * The host application will gather its own XML data along with the XML
> data of all embedded objects into one big XML document that is rendered by
> the KOffice XML rendering engine. The rendering engine does not see the
> difference between a KChart object, a KWord document, or a KSpread
> document with lots of KChart objects in it.

What I understand you would like to see, is some kind of compound
document, i.e. a generic XML container which contains mixed content out of
separate XML file formats, i.e. a document which contains HTML (text)
documents, mixed with SVG (graphics), one or more embedded bitmapped
images, and some other elements like formulas (MathML)
There is work in progress on such a system, but not in KOffice.
KOffice is about editing data, while projects like KHTML are about just
the display aspect (viewing data).

If such a system is in place, perhaps it would make sense for KOffice to
do an "export" of a compound document to such a "renderable" compound
document.
Currently a similar approach (on a lover level) is done if the document is
printed to PDF. A PDF document contains several low level primitives
(text, "graphics", i.e. lines bzier curves) and bitmapped images) which
are comined on separate pages.
What is missing are high level constructs like "tables", "mathematical
formulas" or a centralized overridable "style" system.

> * Allow the host application to override the rendering style of the
> embedded objects. For example, the user could change the default font
> size/family/style of the entire document, including the embedded objects.
> This will make it much easier to create documents with a consistent look.

This is complicated because there exist currently no way that things like
the current font (and its size) can be communicated to a emededed element.

>
> * Embedded objects can be rendered without calling the KPart. When a
> certain KPart is not installed (think of possible third-party KParts), it
> can still be rendered without problems.

This would mean that the graphical representation of the object (in a
scalable way) has to be rendered into the actual document. This is
possible, but would bloat the document.

>
> * The user can save system resources by converting an embedded object to a
> general XML/SVG object that can only be rendered, not edited. All data
> that was needed by the KPart to edit the embedded object can be removed.

Normally the data needed by the edting part is much smaller as the data
needed for visualizing its data in a generic way. So I doubt that you can
save space by this approach.

>
> * Fast and smooth scaling/rotating of embedded objects, because the
> host application has all the information that is needed to fo this
> correctly. The KPart does not need to be invoked.
>

Nice idea, but currently unfeasible because of limitations in the
rendering system.


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]