Hi Andrea: I have been loath to enter this discussion as I quickly get confused between the different points of view (indeed most of the time reading these emails it sounds like you are both saying the same thing).
There is a style visitor used by uDig to adjust a style to respect the current DPI of the target output device; mostly this involves adjusting line width; font-size (which is crazy as it is in points not pixels so an extra conversion is needed). It assumes the default java2d 72 dpi (if I recall) and is used to adjust map display for screen (often 96dpi) or printing (300dpi or more). The only thing in its favour is that it is tested ... however it is a point of reference if you want to know uDig's ideas on what is expected of a DPI setting. The handling of UOM stuff should be handled the same as for Fonts; we want a consistent size at the end of the day regardless of the device used for display. DPI is an indication of pixels per inch; a ratio we can then go on to use to base line our configuration; when outputting results. To be explicit: - For a symbol size specified in pixels; I expect it to shrink to the point of stupidity when DPI is increased - For a symbol size specified in a UOM; I expect it to remain the same physical size when DPI is increased (the number of pixels it takes to accomplish will increase) To be realistic: I kind of expect that we will need an option telling the renderer to accept Java2D default concept of 72 pixels per inch when it sees a pixel; just to prevent the constant questions of why the output does not match the screen. A couple stupid questions about draw order - which one is the default? Or do I choose ... - can I specify a line symbolizer width in a screen unit such as; such as 1.5 mm (often when rendering cartographic output lines need to be an exact width regardless of scale) - can I specify a line symbolizer width in a map unit such as 3 km; producing a poor mans buffer (or is this what a geometry function is for) Jody On 16/06/2010, at 6:28 PM, Andrea Aime wrote: > Hi, > I'm looking into exposing the DPI setting as part of > the GeoServer WMS request, mostly so that people can > get images to send to a printer with a certain DPI. > > (note: the streaming renderer already takes a hint > allowing to specify the DPI) > > What I expect to see is that the symbolizers sizes > increase as the DPI increases, and also that > the scale computation changes accordingly. > > I guess that the UOM and DPI rescalings should be independent, > so that DPI rescaling works also with symbolizers whose > size is specified in pixels. Am I right, or I'm getting > confused? > > What I see now is that using DPI and UOM in combination > (and without a custom rescaling step for DPI) > does not affect the size of the symbols on the map > because the UOM rescaling computes the rescaling factor > in a way that's DPI independent. > > Yet what I'd expect to see is that increasing the DPI > should increase the symbol sizes. > However, that should also happen when I'm not using UOM. > > So I think I should introduce a separate rescaling step in > streaming renderer to be used when the DPI is not > the default value. But I wanted to double check that. > > Am I missing something? > > Cheers > Andrea > > PS: I see we already have a generic RescaleStyleVisitor, > I guess I'll use that one for DPI handling (maybe double > checking it's doing all the same rescales as the uom one, > which has quite some unit tests backing it) > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
