Hi Carlos,
Great to see your proposal coming together!
Here are my comments (I've also pasted them as a comment in the blog)
at:
http://betterprintsupport.blogspot.com/2010/04/draft-proposal.html
* First Paragraph: the problem is not just when printing maps to PDF.
Certainly many people target PDF output when going to print but all
formats require advances to support high resolution output/scaling.
But, I understand why you stated it this way, because the example of
townguide pushing PNG output into a PDF certainly highlights easy
problems that needs fixing. The more advanced way to provide PDF
output is to render all map features as vectors into the PDF (or SVG).
Even thought the PDF format can support embedded rasters, usually when
high resolution output is desired the PDF will look better and be of
smaller size when all vectors are used.
* I like the way you've divided up the application into "control over
scaling" and "post-processing"! Very nice.
* "Better post-processable output" section says: "photo editing
applications". Really people are using vector editing or vector
drawing applications like inkscape and illustrator, not photo
applications (which work on rasters). I'm sure you understand this,
its likely just a typo...
* You say "so the challenge is to investigate, design and implement an
algorithm for scaling raster". Actually I think it is easy to scale
rasters, and in fact the algorithms to do so (always uses to scale
down) are already available inside mapnik (http://svn.mapnik.org/trunk/include/mapnik/graphics.hpp_
). The trick is that certain objects need to be scaled BEFORE being
painted onto raster surfaces. In some cases this is easy, e.g. if
higher resolution output is requested (to be rendered by AGG) then
larger fonts and line widths can be fetched before rendering, etc...
I've not given it much thought, but potentially the "scaling" factor
will need to be different depending on whether the output is raster
(via AGG) or vector (via Cairo). Not something that needs to be solved
now of course, but a fun challenge to test this summer :) Symbols are
different of course, because currently mapnik only supports raster
symbols which, if scaled up, look bad. But you cover this later on, so
let's not worry about this to much now...
* The next several paragraphs in that sections are great!
* Re: "Implementation of an algorithm for scaling raster symbols if
needed (this point needs to be investigated further to determine its
applicability in the project" - this is good enough for the
application. We can talk more about this. In particular Tom Carden has
some ideas that might help that he is researching. And Artem has
recommended using AGG SVG parser to read symbols in a format that can
then be easily scaled.
* in relation to writing a new svg_renderer: I talked with Artem more
about this today and I want to confirm that I think this is a very
good idea that it should be feasible to have a part of the project,
with Artem's guidance, so he will be the primary contact in advising
this. However, you say "cairo_renderer already produces SVG output,
but does so in a rather slow way [7]. " I think a native svg authoring
renderer certainly could be written to be faster than cairo, but the
main idea is that we need something more flexible that Cairo can
provide, to be able to customize our output for more of the varied
usecases of SVG/Post-processing. We can talk more about these later.
* I really admire and support your ideas about how your skills can
contribute to Mapnik and GIS software as a whole. Bringing Math and
Graphics skills to GIS problems is exactly the basic of this project,
so great stuff.
* I also think the collaboration with Waldemar is fantastic - thanks
for making this possible.
On Apr 6, 2010, at 3:46 AM, Carlos Enrique López Garcés wrote:
Good morning everybody. I have updated my proposal and everyone can
read it at: http://betterprintsupport.blogspot.com/. Comments and
suggestions are more than welcome.
Thanks everybody for the suggestions, feedback and support you've
given me.
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
