kicad-developers team mailing list archive

["Marco Serantoni" <marco.serantoni@...>]

> >> This is a good idea. SVG is simply XML, so a person can use libxml2, 
> >> which is standard on most linux systems. A person can read the whole 
> >> file into a DOM tree in about 5 lines of code. Then you simply have to 
> >> walk the tree, and generate PCBNEW graphic constructs from them.  
> >> However, I do not believe that PCBNEW's graphic constructs, nor graphics 
> >> environment, are currently general or rich enough to support anywhere 
> >> near 30% of what you might find in the SVG spec.

> > Indeed we have to reduce/approximate them to polygons and save them in the library cache / document without too much changes.
> > You have excluded wxXMLDocument due bad experiences or for coding attitudes ?
> No, I had forgotten about wxXMLDocument, never used it. The tinyxml 
> library seems nice at first glance.
I like tinyxml too but, you could agree, i think that is better to add new dependencies only if what we have is buggy or is more problematic to write new code.

> Note that I was not advocating supporting XML in kicad, per se. Just 
> that I think a superior graphics environment, such as one that is 
> demanded by SVG, would help Kicad. A person could get closer to a full 
> graphics environment by supporting some of the things that an SVG file 
> demands of its interpreter. I actually am not advocating SVG support 
> directly, but perhaps through a conversion utility only.

I've nothing against XML neither for kicad per se.
I think that a prerequisite is add a couple of CPolyLine::AppendBezier calls adapting the code in http://www.antigrain.com/__code/src/agg_curves.cpp.html for example.

> Regarding the "graphis environment", it would be nice to have:
> Objects contain graphical attributes
> Objects get drawn into a graphics context
> Objects can have transforms and can be grouped, and un-grouped.

> These are all missing features in Kicad's graphics environment. It 
> does not have to be as rich of an environment as one capable of 
> supporting SVG drawing, but we are too far at the opposite end of the 
> spectrum currently. That is all I am saying.
After having cubing and quadrating bezier to line strokes we have all to trace the path that is a great start point as we have the way to draw all thepath commands for SVG.

> And if something like wxGraphicsContext is already finding its way into 
> a library that we are dependent on, I think it is something that needs 
> to be studied as a *possible* solution to the poor graphics platform 
> that we suffer from now. Particularly if consider that the Mac guys 
> responsible for wxWidgets, chose to use wxGraphicsContext for the entire 
> wxDC implementation.
I know, and one of the first thing they do was to suppress the graphical logical operators...
I think that with wxGraphicContext we can do a lot of job better and when we have migrated to wxGC we can think to pass from the current path description to a SVG like path description syntax also in the libraries and files.

--
Marco