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

List:       kfm-devel
Subject:    Re: SVG + KOffice/khtml
From:       Daniel Molkentin <molkentin () kde ! org>
Date:       2001-06-15 10:15:28
[Download RAW message or body]

On Friday, 15. June 2001 10:42, Harri Porten wrote:
> On Fri, 15 Jun 2001, Nikolas Zimmermann wrote:
> > On Thursday 14 June 2001 23:15, Daniel Molkentin wrote:
> > > On Thursday, 14. June 2001 23:00, Harri Porten wrote:
> > > > On Thu, 14 Jun 2001, Nikolas Zimmermann wrote:
> > > >
> > > > 90% of *all* SVG features ? Wow ! ;)
> > >
> > > *g*, Well, not really. But anyway ....
> >
> > just path and style are missing which aren't the easiest :)
>
> So gradients, patterns, filters, animation and interactivity is done then
> ? ;)

No, I think Niko means the the basic shape primitives that are working. 
Reading the specs, I found that SVG has a DOM2 based Object Model and thus it 
even has scripting facilities using ECMAScript 
(http://www.w3.org/TR/SVG/script.html).

So we should share code with khtml if we want to have a full-featured viewer 
Otherwise, reading the specs, I feel we would reinvent the wheel.

>
> > > > What does your parser output, i.e. how are the graphics rendered ?
> > >
> > > Niko's parser converts SVG to the propretary kivio stencil format. As
> > > does kpresenters import filter for KPresenter if I am not mistaken.
> >
> > killu....

upps, right :)

>
> What does libksvg feed to killu and kivio then ?
>
> > > Thus, a native renderer for SVG is missing.
> >
> > not when using killu
>
> Than make this a KIllustrator plugin for Konqueror offered by the KOffice
> package and put the support lib into koffice/lib. Wrong thinking ?

That _would_ be an approach but somehow I don't like it. It sounds like 
overkill. Besides, we need the resulting image to be almost a common khtml 
image just like vadim says. This is because SVG is also indented to be used 
in conjunction with HTML.

My knowledge of khtml and Qt3 is just too small to judge, but:
Given these facts, what would be the best approach? Besides the common 
appoaches (using QDOM and such), would it make sense to use libxml for it 
(now that we depend on it anyway)?

</daniel>

-- 
KDE 2.1 - Conquer your Desktop!
http://www.kde.org

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