On 17/06/2010, at 5:37 PM, Andrea Aime wrote: > Jody Garnett ha scritto: >> 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) > > I kind of expected that as well, but it's not happening. You increase > the DPI and the width specified in km do not change.
That sounds like a bug; are we using the unit of measure code to convert from km to pixels? Or do we perform our own conversion... >> 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. > > That's the same need I'm expressing. People want the printout > to look like the screen. I suggested to call it DPI setting, but > it seems people don't agree with that. How should I call it? Yeah it is a separate setting (used to provide a screen correction for mapping screen sizes to inches) so you can then go and apply the DPI of the final target device. That is starting to treat data pixels as a normal UOM like all the others with a conversation ratio to convert it into device pixels. Outline for rendering 300 dpi: - DPI gives us pixels per inch; allowing us to convert from any data UOM to output pixels - Font size converted from pt to 300 dpi (may need to go by way of Java2D 72dpi assumption) - data pixels (ie data provided with pixels as UOM) converted 1:1 to output pixels Outline for SCREEN_CORRECTION=72 at 300dpi (The setting of 72 dpi matching Java2D documentation) - DPI gives us pixels per inch; allowing us to convert from any data UOM to output pixels - Font sized in pt; Java 2D renders to strokes; and then strokes output at 300 dpi - data pixels (ie data provided with pixels as UOM) converted from 72:300 to output pixels > Nope, you cannot. SE 1.1 allows for meter and feet, but they > are intended as real world units, not as screen ones. > The document Milton references to describes new units that > will be interpreted as display units instead: > > urn:ogc:def:uom:se::px > urn:ogc:def:uom:se::mm > urn:ogc:def:uom:se::in > urn:ogc:def:uom:se::pt > urn:ogc:def:uom:se::percent > > Whislt the following two should be the replacement for ground units: > > urn:ogc:def:uom:se::gm > urn:ogc:def:uom:se::gft > > That is, assuming the document recommendations will be integrated in SLD 2.0 That answers my email I had half typed up....the conflict between what stage a measure it to be applied at: For a single conversation renderer: - a line symbolizer width provided in "km" I expect is adjusted by the current map scale; this will produce the same visual regardless of DPI - a line symbolizer width in pixels I trust is in device space; this will produce a different visual depending on DPI For a two conversion renderer: - as above for stage 1 resulting in a series of shapes we need to draw - for a font size in points I expect a conversion based on DPI for the same visual regardless of DPI - a line symbolizer width in mm I expect to be in device space; and adjusted by DPI so I get the same visual regardless of scale > There is also a mention of the meaning of "pixel" in printing: > > --------------------------------------------------------------------- > > In SVG, the pixel is considered to be a relative unit of measurement. The SVG > authors > recommend it to mean an angle of view of about 0.0227 degrees. For a normal > display, it > corresponds to about 0.28mm, which is the value that SE uses. For material > printed on a > laser printer, it corresponds to about 0.21mm, since one normally holds a > sheet of paper > closer when reading it. > In SE, there is confusion when a map is rendered into an image that is to be > printed on a > high-resolution printer. Lines measured in pixels will be very thin unless > some kind of > compensation is applied. > > --------------------------------------------------------------------- > > This is exactly the topic of this thread: I want to give the user > a way to specify such compensation. Got it - please do it as a separate "pixel correction" setting, rather then DPI. If possible get them to describe the size of a pixel in real world units; rather then in terms of dots. >> - 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) > > That you can do already on trunk (and soon on 2.6.x as well if I backport > that functionality) > > Cheers > Andrea > > > -- > 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
