Re: Word attachment...on linuxtoday

[Lauris Kaplinski <lauris ximian com>]

Hello!

A bit of backround, if you are interested.
There are 2(3) display-related subsystems in sodipodi, that can
theoretically be broken apart as libraries. If somebody wants
to do that, then I think I can change licensing to LGPL for
these (have to look who have contributed code before).

a) Low-level display cache tree NRArena. It is modelled along
gnome-canvas, but renders everyting onto RGBA buffers. Basically
it just does composition of shapes to buffers, having hooks to
add clips, masks, filters, paint servers etc. No advanced
stuff (paint servers etc.) is implemented directly, but instead
we rely on outside sources by callbacks.
It should be small and fast enough, so it can be used itself
as paint server - i.e. for doing pattern fill we can just create
additional NRArena tree of pattern, and hook it as paint
server to pattern-filled object in main NRArena tree. Plus
the tree can be instantiated inside buttons, menus etc. to have
widgets with object previews.
Now - I am very sure - it would be meaningless to add any
advanced graphic stuff to it. Just callbacks are enough,
frontend can do everything else.

b) High-level SVG tree (SPDocument). It operates on abstract canvas,
and for all displaying just instantiates NRArena (for the
whole document or of any part of it). The functionality is
(and probably will be) constrained by SVG - i.e. extremely
high-level at some parts, and painfully missing things in other parts.
The interface is at bottom level string-based, i.e. something
like:
sp_object_setAttribute (o, "fill", "pink", &exception)
Theoretically there could be higher-level SVG interface too,
using datatypes defined in SVG DOM, but this is basically
missing, as i have had no need for it from inside sodipodi
yet.

c) Some graphic stuff, like composition of paths etc.
Nothing very interesting, but certainly it should emerge into
quite functional set of geometry operations.

OK, I think you are talking about something different. Although
I have not yet grasped, whether we are talking about:

a) drawing API
b) display object tree API

These 2 are mutually exclusive, believe me. You can do quite
advanced drawing library, but it will still be near-useless due
to (lack of) speed for programs needing persistent graphic objects,
or you can do library giving you advanced graphic objects, but it
would make drawing simple things terribly memory-hungry.
IMHO most programs actually need (b). (a) would be nice to implement
by system, to give something like poor-man common interface
to drawing, printing and bitmap generation, if your needs are
either simple, or you are not concerned about speed.

Ah, and 2 remarks ;-)
- libart is maintained. raph was proabably busy with ghostscript,
but check the changelog of CVS, and you see that lot of activity
is happening recently ;)
- C has some advantages for library (heh gcc 2.9x -> 3.x migration
will be happening for some time now). So if there will be serious
non class-related functionality (bpaths etc.), it would help to keep
it in separate library.

Best wishes,
Lauris Kaplinski


On Fri, 2002-01-18 at 02:31, Martin Sevior wrote:
> 
> 
> On Thu, 17 Jan 2002, Michael Meeks wrote:
> 
> > 
> > Charles,
> > 
> > On Wed, 2002-01-16 at 19:22, Charles Iliya Krempeaux wrote:
> > > Is the sodipodi engine separated out into a library?  (And if so, then
> > > are there any docs about using it... besides the source?)
> > 
> > 	No - read the source; check the module out from CVS, and hack wildly at
> > it; if you want a library - make it a library; quite why you'd want to
> > make it a library I know not. Mostly people dislike dependencies in
> > libraries, and sodipodi is a relatively sane project that doesn't
> > re-invent the wheel (badly) before achieving it's goals, and thus has a
> > number of Gnome dependencies.
> > 
> 
> What we need is a library to draw onto a generic graphics
> context. Actual implementation of draws would be done by subclasses.
> 
> Regarding re-inventing the wheel, we'd MUCH rather (and we have a long
> history of) stealing GPL code.
> 
> However both rsvg and sodipodi have issues for the people doing most of
> the work on this. (I won't do much. My time will be spent stealing code to
> implement Tables :-)
> 
> These guys want a lGPL library because they want to use it elsewhere. rsvg
> and sodipodi are GPL. Also both are written in C which makes stealing code
> hard for C++ projects. The pure virtual methods fits more neatly into
> a C++ framework. rsvg also depends on libart-lgpl which appears to be
> unmaintained. (Please flame and correct me if I'm wrong.)
> 
> Speaking of re-inventing the wheel, does the Evolution team plan to use
> wvHTML to render MS Word docs into in-line HTML for Evolution? wvHTML
> handles tables rather well and is part of the gnome-office library.
> 
> I would love such a feature myself.
> 
> Cheers!
> 
> Martin Sevior
> 
> 
> 
> 
>