Hi Andrea: I ran into this problem when rescaling maps for printing; one of the things I did (using the "resize" feature visitor as documented in the user guide) was rescale the font sizes. In doing research for that I seem to recall that font sizes were determined assuming a pixel was 1/72 of an inch. I think I was able to look up something more specific but it may of been using an SWT class called Display.
- http://www.developer.com/java/other/article.php/626051 - http://forums.sun.com/thread.jspa?threadID=5356290&tstart=0 Jody On Mon, May 11, 2009 at 8:51 PM, Andrea Aime <[email protected]> wrote: > Hi all, > making the MapServer/GeoServer performance comparison back in September > 2008 Steve Lime made me notice how GeoServer was rendering line widths > and fonts sizes differently than MapServer, and how MapServer was in > fact respecting the SLD standard better than GeoServer in that respect. > > In particular, GeoServer was rendering overly thin lines, and smaller > than expected fonts. I've attached to this mail a reference SLD, > the output the streaming renderer is currently producing, and the > expected one. > > The thin line is due to an optimization I put while back, before > antialiased rendering was even attempted, that I made optional > in 2.5.x and I'm going to remove in trunk. > > The font issue is that SLD specifieds font sizes in pixels, whilst > Java font sizes are specified in points. And points are generally > speaking smaller, so you say 14 in SLD and you get a font that's > 10 pixel high. > > Now, does anybody of you know of a reliable way to make the font > size conversion? I could not find anything specific online, > but the two following ways seem to work (assuming javaFont > is configured with the font size coming from SLD, and trying > to find a compensation for it). > > First way, render a capital M and see how big it really is, > compensate for the difference assuming a linear relationship > between point and pixel size: > > float size = ... // get from SLD > // configure java font so that it uses the sld size > float height = (float) > javaFont.layoutGlyphVector(graphics.getFontRenderContext(), new char[] > {'M'}, 0, 1, > java.awt.Font.LAYOUT_RIGHT_TO_LEFT).getVisualBounds().getHeight(); > javaFont = javaFont.deriveFont(size / height * size); > > What I don't like much about this approach is that it's > assuming the M is going to be representative, and with > symbol fonts it may not be. > > Another approach is using intrinsic properties of the > font given by its FontMetric, in particular its > ascent (distance between baseline and top of any > char), too bad the ascent is taking into account eventual > accents placed on top of capital letters... > I noticed that the descent (distance between the > baseline and the bottom of chars such as g,p,q) > is about the same size as the accent area, so the > following works too in practice: > > float size = ... // get from SLD > // configure java font so that it uses the sld size > FontMetri metric = // get the font metrics > float height = metric.getAscent() - metric.getDescent() > javaFont = javaFont.deriveFont(size / height * size); > > What I don't like much about this approach is that > it's completely empirical, there is nothing in the > Java API confirming it makes any sense. > > Anyone with a better solution? I looked around on > the net and in the java font handling APIs but could > not find any other. > > Let me know > > Cheers > Andrea > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK > i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
