On Apr 2, 2010, at 1:04 PM, Carlos Enrique López Garcés wrote:
Good afternoon,
I have been working on my proposal, but some doubts arose:
1. As I understand, Ben Moores' pdf renderer implements all the
functions for processing each kind of symbolizer, following the
model of agg_renderer and cairo_renderer.
Oh, interesting, I was not aware of this, so thanks for reporting how
it works...
This then sounds like it is a parallel type of implementation, a
`pdf_renderer` that in addition contains the logic for adornments,
since wxpdfdoc supports drawing extra things (like Cairo API) plus
maintaining logical layering in PDF (which we presume Cairo does not
expose).
agg_renderer and cairo_renderer are currently designed to produce
output as raster images for displaying in the screen.
Well, not exactly. They each render to their respective surfaces, agg
being a raster_ptr (artem will know more about this), and cairo being
a generic context/surface that is specifically intended to then
support being pushed into either PNG (raster), or vector formats
(pdf,svg,postscript, and others potentially if compiled in). So while
AGG usage and library is limited to raster images Cairo is designed
around more abstract interface to have different output. Hence this is
why in these discussions sometimes we tend to lean toward
cairo_renderer (or lean away due to limitations).
The difference between these and pdf_renderer is the target output.
certainly a difference, yes. I know see Ben Moore's branch as most
similar to artem's idea of a very tailored new svg_renderer, just
different format and goals based on strengths of the format.
So this makes me think that all the adornment elements, such as the
grids and the scales, might be part of a last processing before
rendering (as they might me placed in the upper layers).
Yes, certainly. But I can see value to at least two different ways to
allowing easy addition of adornments:
1) drawn on a "map canvas" that goes on top of rendered map (from any
backend)
*** to support single image, easily printable Map***
and
2) ability to fetch an adornment as a separate object from the mapnik
api (python or C++) to be displayed in an application, say a web site
of in Mapnik Viewer.
*** to support programmatic addition of adornments ***
The latter is a bit off-topic i realize but ideally the design could
accommodate both.
However, I know that these elements must be implemented in each
renderer, since a different API is used. So if I understand
correctly, the adornments are not elements that are only needed in
printed maps, but also in the maps displayed on the screen. Am I
correct so far?
Well put, and addresses my idea as per above.
2. Robert Coup mentions that the idea is to add these elements to
the cairo_renderer. So both the adornments and the variable-
resolution/units ideas are for improving the cairo_renderer. Is this
correct?
Yes, both these things should be generic to all renderers. It's just
that because target was PDF, and Cairo can produce PDF that cairo-
renderer was discussed first.
I think I should find a way to define these ideas more abstractly in
the code, so the cairo, agg and svg renderers benefit from this
addition, not only the cairo-based one.
Exactly.
Maybe define a set of classes that could be shared between
renderers, leaving the specifics of how to display them to the
renderers.
!!!!!
3. I still think that the svg_renderer would be worth implementing
this summer, though I would like to know your opinion on which ideas
have a higher priority.
I will defer to artem on this. I think it is a great idea, but a bit
beyond my skill level and familiarity with svg. Either way it seems
like a phase II thing after variable-resolution/units/pixels issues
are solved.
Thank you, I hope I can send a draft of my proposal tonight.
Wonderful!
Carlos Enrique López Garcés
2010/4/1 Dane Springmeyer <[email protected]>
I encourage everyone following this thread to respond to carlos's
summary ideas. The applications are due soon and the more feedback
he has the more likely the project with be accepted and in a form
that is both exciting and feasible for the summer.
On Saturday is whercamp and I hope to have a session with Mike
Migurski and Tom Carden to discuss mentorship and progress so far.
At this point I feel very impressed with carlos's awesome research
and the fantastic community brainstorming.
Thanks!
Dane
--- \o/ ---
Sent from my phone
On Apr 1, 2010, at 1:43 PM, Carlos Enrique López Garcés <[email protected]
> wrote:
Good afternoon, how are you?
I was talking yesterday with Mr. Springmeyer about the scope of this
project to determine the main goals and tasks. From the ideas
discussed in this thread, I identify three major groups:
Improvements in resolution, the implementation of a renderer based
on SVG, and the addition of 'adornments' or informative elements
(grids, scale bars, etc.)
Each group has its own level of difficulty. However, I see more
complexity in the implementation of the SVG renderer. I think it
represents a major design task that deserves attention from a more
experienced developer. As I'm new to the project, I think I would do
better if I worked in the other two groups of ideas, which seem to
have very clear and defined boundaries. This would help me become
more familiar with the design and structure of Mapnik and would
allow me to contribute in a better way in the future.
However, I think you'll have a better perspective of the problem, so
I'd love to hear your opinions.
Thanks
Carlos Enrique López Garcés
_______________________________________________
Mapnik-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-devel
_______________________________________________
Mapnik-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-users
