Thank you Mr. Pavlenko, Mr. Springmeyer, Mr. Jones, Mr. Coup and Waldemar for your replies.
Sorry for replying so late. I've been reading a bit about the SVG format specification, but I don't feel I can reply properly to your ideas right now Mr. Pavlenko. I'll continue with my research about it this afternoon and will have something to comment with tonight. Thank you for your patience Carlos Enrique López Garcés 2010/3/29 Artem Pavlenko <[email protected]> > Hi Carlos, > > Thanks for your research! > (replying inline re: svg_renderer) > > .... > >> Ticket #320 (SVG-Based Symbolizers): I don't have enough information to > >> comment here, but Mr. Pavlenko said he is interested in an SVG renderer. > >> > > > > Yes, this one is hard and my feeling is that it is not within the scope > of > > GSOC, but I'd be happy to be wrong. The main functionality here is > already > > implemented, but the Mapnik developers need to discuss further about the > > approach. I think that Artem is interested in using the more basic > support > > inside AGG for reading/rendering SVG instead/in addition to RSVG, but we > > should hear more from him. > > > > Also, I think his idea for an SVG renderer is different. #320 is about > being > > able to read/render SVG symbols and I think what an 'svg_renderer.cpp' > would > > be about is writing a new output renderer that would be very good at > > authoring SVG (better than Cairo). This could be very very useful for > > Nicholas and others than desire optimal SVG output for post-processing. I > > think Nicholas used the PDF output in the past over SVG because Cairo's > PDF > > output is slightly better supported than SVG, though SVG may be more > > desirable/flexibly for post-processing in general. > > > > Dane, you're right I was thinking about svg_renderer which would > extend feature_style_processor e.g > > struct svg_renderer : feature_style_processor<svg_renderer> {} > > and would render to SVG file. There are some nice features we can add > like - simplifications, smoothing etc. Perhaps different policies to > control how SVG elements constructed, layering, embedded > fonts/symbols. > Also, it would be possible to load and edit such SVG in popular apps > like Illustrator, Inkscape. Implementation can be based on existing > agg and cairo renderers. > > Thinking more about SVG based symbols, I reckon it would be feasible > to implement this over summer. I can certainly provide guidance and > help on this one. I just now modified svg_test which comes with agg2.4 > ( adding css color parsing from mapnik) and I was able to display > demo.svg (generated with rundemo.py). Most building blocks are already > there. For I/O we can re-use existing XML parsing framework (mapnik) > and add fast spirit based parser for <path .../> elements for example. > Sounds like fun to me;). > > Thoughts? > > Regards, > Artem >
_______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
