Dia2, SVG, XMI, Dublin Core, aw hell just look at OO.o [RE: RE: RE:SVG support]

[Alan Horkan <horkana maths tcd ie>]

Dia2, SVG, XMI, Dublin Core, aww hell just look at OpenOffice.org Draw.

sorry i am mostly going to skip responding directly to the thread.

You want XML (eXtensible Markup Language) and you want to do UML type
stuff in it then you want XMI (XML MetaData Interchange).  IBM Eclipse is
doing something called EMF (not to be confused with Microsofts Enhanced
Metafile .emf, close relation of Windows MetaFile .wmf).

You want to draw stuff, then you want SVG (Scalable Vector Graphic).

Take an OpenOffice.org Draw document, unzip it, look at the XML.  I looked
at Dublin Core for quite a while but my inability to get Dia to build held
me back somewhat (amongst other things.  Cant wait for RedHat 9).  I had
some notions on how to facilitate aritrary user extensions, make sure to
remind me.

In general I think it is wise to follow the lead of others and only do
things differently when there is a good reason to do otherwise.
Please dont break what we have.

Please talk to Dom Lachowicz about librsvg, there might be some potential
for code reuse.  Shame that we cant rip a lib SVG out of Sodipodi, or
maybe Sketch.
I dream of better SVG support so that we can do cool things like create a
web site diagram full of SVG icons representing the files.

I have filed a bunch of bug reports suggesting good directions to take
things, if i weren't typing this on a 56k dialup connection i would tell
you which numbers but you will have to look them up for yourself.
http://bugzilla.abisource.com

I was thinking that the .shape files should be SVG with extra embedded DIA
infromation rather than, Dia with embedded SVG.  This way SVG programs
would be able to display the visual SVG part of the Dia .shape files and
ignore the rest (although in an ideal world they would be smart enough to
see the Dia XML contained embedded SVG and display it).

One of my problems with the dia file is that in effect it is just a list
of objects.  It might be possible to reinterpret this as SMIL.

While messing about with Dia and having renamed some of my shapes i found
that old save files would spew a s---load of not found errors and not
display anything useful.  Imagine what would happen if we had thousands of
shapes but did not ship with all of them.  Document exchange and
portability is a nightmare.  It would be nice if the save format was more
robust and the SVG was inlined into the actual Dia file so that if
hte object as unavailable at least there would be a placeholder
image to display instead.

I really dont like the programmed objects, it would not be so bad if they
were SVG for the visual parts.  Binary file formats, ick.  Mixed and
matched XML with Binary is even worse.

If you are not particularly interested in UML and more in the diagramming
aspect then in the short term you can keep things simpler and focus on
getting Dia to round trip SVG.

I would be inclined to plan a Dia2 file format seperately without breaking
what we currently have.  This notional Dia2 format would combine all the
aforementioned standards with the working bits we already have.

I'm tired and I am not sure this is making much sense, so I will get back
to you with more later.  In the meantime your work to improve the SVG
import/export is very much appreciated.

Sincerely

Alan Horkan
http://advogato.org/person/AlanHorkan/

Visit Dublin!
http://www.guadec.org


On Thu, 27 Mar 2003, Jeroen ten Berge wrote:

> Date: Thu, 27 Mar 2003 16:15:30 +0100
> From: Jeroen ten Berge <Jeroen.ten.Berge@Vialis.nl>
> Reply-To: dia-list@gnome.org
> To: dia-list@gnome.org
> Subject: RE: RE: RE: SVG support

> > a better importer -- to reload -- but also a better shape loader code;
> > otherwise people won't be able to contribute (or more
> > generally speaking,

from the bits of computer sciences i was paying attention to i keep
thinking of inheritance/extending a class/code reuse/blah probably using
terminology from a wrong language.

> > One rework which might prove worthwile, would be to have some kind of
> > mid-layer representation for the imported SVG format

> > (less code, better code). Probably, sounds like there's a lot to do
> on that... Interested in helping with that ? I now all about SVG1.1
> DOM, so i can help with that, now there are more basic shapes than