Re: RE: RE: SVG support

[Cyrille Chepelov <cyrille chepelov org>]

Le Thu, Mar 27, 2003, à 02:49:55PM +0100, Jeroen ten Berge a écrit:
> <SNIP>
> > guess the point of switching dia to using SVG exclusively has a pretty
> I've allready sent a new mail later that i responded to soon about SVG and that i reacted to soon without looking at DIA's DOM, it was an unnecessary mail.

Which one was un-necessary? Mine? Possibly. I guess I have been confused by
the broken thread (looks like one MUA out there is not updating the
References: field while scarring the subject line, which is too much for my
poor MUA)... So yes, it's possible I got confused with the order in which
messages were sent and exchanged, and I apologise for that.

Anyway, 

> I'm not thinking of webpages alone ! But you're right about DIA in contrast 
> to SVG, DIA is ofcourse for making diagrams. Still I think parts of a 
> diagram could be defined in SVG (like WMF) for objects like network parts 
> e.a.

Huh. I don't want to sound harsh at all. Have you ever looked at the inside
of a .shape file? :-)

(this reminds me of another pitfall of modifying the SVG exporter; if I
remember correctly (Lars, cluebat me if I need another hit), the .shape
exporter relies on the SVG exporter to produce the .shape file. Problem is,
the .shape loader is not the same code as the SVG importer, and that code
path understands only a very limited subset of SVG. So, if we start
outputting more litterate and cleaner SVG, we will need to not only provide
a better importer -- to reload -- but also a better shape loader code;
otherwise people won't be able to contribute (or more generally speaking,
define their own) shapes anymore.

One rework which might prove worthwile, would be to have some kind of
mid-layer representation for the imported SVG format (regardless of whether
it comes from an actual SVG file or a .shape). Then, we'd convert this
mid-layer representation into either full-blown dia objects (SVG import
path) or the graphic opcodes used inside the Shape implementation. In fact,
maybe revising & revamping these graphic opcodes (deep down in
objects/shapes currently) may be the best way to avoid writing the mid-layer 
rep in the first place, while merging the two SVG import/load code paths 
(less code, better code).

	-- Cyrille

--