Hey there Hmm, I guess I see what you mean, although I feel like it is just a different way of seeing things.
Let's see: > symbolizers to have the same size. However on the screen 50 pixels > are long X, whilst when printed the are long just X/3 because the > priter can cram a lot more pixels in the same space. Right, that's why I said that symbolizers given in pixels end up with a smaller apparent size as DPI increases. Now, if you say your symbolizer has a size of 10 pixels, then obviously it changes size as you change screen resolutions, right? (think monitors with different resolutions). What I mean is that if the *size of the pixel* changes, that's another story! So, if you say that you want it to be invariable in INCHES (or millimeters), then in theory wouldn't inches be the unit of measure you want, instead of pixels? Taking a quick look via Google I found this "OGC OWS-6 Symbology Encoding (SE) Changes" document (from 2009) portal.opengeospatial.org/files/?artifact_id=33515 It seems to include inches (and millimeters, and some other stuff) as valid Units of Measure. So I guess that would be the way to go if you want things to always show up with the same apparent size, regardless of DPI issues (if that's what you want). As a final note, I still think that stating a size in meters should keep the symbolizer proportional to the remainder of the map (as I believe it does now) Cheers Milton Andrea Aime wrote: > Milton Jonathan ha scritto: >> Hello Andrea >> >> I don't have any code around me right now, but I can tell you my >> understanding of this topic: >> - DPI should affect the pixels/meter ratio (map scale). >> - Symbolizers given in meters should not change apparent size when DPI >> varies, as the size of the map in meters also remains the same. In >> this situation, when DPI increases the sizes in pixels of both the map >> and the symbolizers should increase proportionately. >> - Symbolizers given in pixels should have a SMALLER apparent size if >> DPI increases: the same number of pixels now represent a smaller size >> in the real world (more dots in the same inch) >> >> That said, I don't think that a new rescaling step should be >> necessary. My feeling is that the DPI setting should affect the map >> scale (pixels/meter) passed over to the UomRescaleStyleVisitor. >> >> Of course, it could be ME who is missing something :P > > Right, my understanding is different than yours. > Think you want to generate an image that you need to send to a printer > doing 300dpi. Your screen is 100dpi or something like that instead. > > The dpi is just an accident of the display technology, but you want the > symbolizers to have the same size. However on the screen 50 pixels > are long X, whilst when printed the are long just X/3 because the priter > can cram a lot more pixels in the same space. > > You want the output to look the same, but to do so, you need to generate > a symbolizer that's 3 times larger in terms of pixel, to preserve its > size in cm. > > So no matter if you are sizing in pixels or in meters, you need to > compensate for the DPI change by rescaling everything by > targetDpi/standardDpi > > Makes sense? > > Afaik this is what uDig does for printing (looking for confirmation > on this one) > > Cheers > Andrea > -- Milton Jonathan Grupo GIS e Meio Ambiente Tecgraf/PUC-Rio Tel: +55-21-3527-2502 ------------------------------------------------------------------------------ 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
