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
