Jody Garnett ha scritto: > 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)
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. > 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? > 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) 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 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. > - 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
