Hi Carlos, (inline)
2010/3/31 Carlos Enrique López Garcés <[email protected]>: > > Good evening Mr. Pavlenko > > Here's what I understand about your ideas: > > There are currently two main renderers, one based on Cairo and the other on > AGG. The idea is to develop a third one that would not use this kind of > graphics libraries, but rather use SVG as output. Correct. Two main concerns drive > this initiative: Performance and scalability. The main goal would be to output optimised SVG with a finer control. This can't be achieved with cairo backend. Some important features would be - layers, embedded/external symbols/fonts. While cairo_renderer can output SVGs they are is not very useful for post-editing in Adobe Illustrator, Inkscape etc. So I see main concerns in this order : 1) Optimised/User friendly SVG 2) Improved performance (more below) > Concern #1: Performance. In your first reply to this thread, you mention > that the Cairo-based renderer is kind of slow, so an SVG output generator > using Boost.Spirit.Karma would be considerably faster. I read that both > Cairo and AGG are able to do it, but Spirit would increase performance, > right? Yes, using boost::spirit::karma should result in better performance. > Concern #2: Scalability. Since the main virtue of SVG is that of making the > image scalable, this feature would be relatively straightforward to > implement. Furthermore, SVG is a common format, widely used by many > applications (Inkscape and Adobe Illustrator, for instance). Yes, SVG is by definition scalable. > About the implementation, I understand that agg_renderer and cairo_renderer > are subclasses of feature_style_processor. This class does the basic > processing of the map, iterating over its defined layers and rules. The > subclasses (cairo_renderer and agg_renderer) are responsible of defining the > way each symbolizer is rendered, using each a different API (Cairo and AGG, > respectively). The svg_renderer would be based on Spirit to produce the > image in XML format. Correct. > > I haven't read about how an SVG image can be embedded in a PDF file. My > question is, would this require the implementation of a separate PDF > renderer for SVG, just as Robert Coup says about a Cairo-based one? > OK, SVG->PDF needs some r&d, it should be easy, though. re:Cairo - it hasn't fine control required to implement features we're discussing, Robert could verify this please? > Thanks, > > Carlos Enrique López Garcés > Regards, Artem > 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
