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. Two main concerns drive this initiative: Performance and scalability. 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? 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). 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. 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? Thanks, 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
