Hi Carlos, Thanks for putting together your proposal. I think it looks good and I agree with Dane's comments below. Just one thing I think would be worth adding (or keeping in mind) for this projects (please, correct me if you're already addressed this!)
* Finer control over scaling and resolution It would be really cool feature to be able to have scale dependent units (is this is correct term? can't think about better name atm). For instance, if I define stroke-width to be 10px at particular resolution then it gets scaled appropriately for different scale denominators. Obviously, this behaviour is not always desirable but in some cases it can be very useful. Have you thought about this one? Best, Artem 2010/4/7 Dane Springmeyer <[email protected]>: > 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
