gEDA-user: Fwd: RFC using SVG with semantic markup as an EDA format

[Andrew Seddon <seddona@xxxxxxxxx>]

> The idea of basing future formats on SVG has been thought of, floated,
> and discussed before now. I don't recall whether any conclusions were
> reached. I personally have mixed feelings, but am leaning towards the
> the thought that it is a good idea - but with a healthy dose of
> uneasiness about it as well.
>
> When I designed "path" support in gschem, I deliberately made the path
> syntax compatible / identical to SVG paths in case we went down this
> route at a later stage, and that so more complex paths could be drawn in
> a graphics program, then copy+pasted from an SVG file.
>
> libgeda only saves (and guarantees to load) simple line and bezier curve
> based paths, but an implementation detail (due to code re-use from
> librsvg), it can actually read any legal SVG path in its path primitive.
> When saving, it always converts that out to simple lines and beziers.
>
>
> I'm not as convinced of the idea for PCB layouts / footprints. I'm just
> not certain the drawing model is constrained enough. to match real world
> geometry demands.
>
> The main niggle is that SVG is more expressive than a generic PCB layer.
> Things like colours and gradient fills are just not meaningful in
> copper. That means we need to act intelligently if something adds those.
> Supporting complex geometry primitives which SVG would bring also means
> internal processing in PCB might get more difficult.
>
> --
> Peter Clifton

Yes I see some work was done into an XML file format before, will try
and dig up the SVG discussion. I cant see any real technical benefit
to gEDA in using SVG to be honest.

The benefit is the warm fuzzy feeling your average hardware
developer/pcb designer would get when they double click on the file
and a nice representation opens up in the browser. My premise is that
this alone would increase adoption of the format and any tools which
use it. There are also knock on benefits in terms of communicating
design intent to production houses etc.

The hard part is going to be constraining and augmenting SVG so as to
produce a dialect which can;

1. Be translated to common EDA formats with relatively simple algorithms
2. Display nicely on standard SVG viewers
3. Be easily to manipulate by tools working natively in the format
(this is probably implicit in 1 though)

Keen to hear why this idea sucks!
---
Andrew


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user