[udig-devel] dpi issues

[Adrian Custer]

Hey all,

This is a *great* issue to be raising but, from what I understand, we
are not going to solve it simply nor merely at the uDig level. This
needs to be conceptualized all the way through the library.

DPI affects more than rendering; it affects presence (generalization) as
well. The amount of information which can usefully be displayed on
screen is much less than the info which can be printed on a road map.
This issue needs to be thought through at the uDig and gtFeature level,
something we will do after first dealing with dpi in rendering.

High DPI rendering has all the issues you have already identified.
Dealing with resolution independent/dependent issues falls on the
display infrastructure. (72 actually probably does not come directly
from the point equivalence but on a design decision in Java Graphics 2D
which forces you to draw to a surface as if it were 72dpi and then takes
over from there to transform that to the real display). There's a chain
from original spatial defn in the feature, to homogenous 2D Coord. Sys.
Then from there there's a 2D chain all the way to the 'display' space.
In the end, the transforms are one long chain of affines.

We are just now getting to documenting out the transformation chain to
go from feature geometry to screen/print geometry. We are struggling
with getting good names and making sure that we explain what's going on
both conceptually and in the real gt library. Once we figure out how to
describe the chain, we're going to build a new geotools renderer. My
design requirement for that renderer, among others, is very much to
print good plots, eps for latex and pdf for plotters. It's a long road
but we hope to get there this year.

The only 2c I'll pitch in to your discussion which otherwise threatens
to become huge. Glad that you are paying enough attention to details to
pick up the issue and sorry we don't yet have a real display/plot
system.

all the best,
adrian

On Wed, 2008-03-26 at 16:36 -0700, Jody Garnett wrote:
> Vince Darley wrote:
> > At 21:20 26/03/2008, Jody Garnett wrote:
> >> I have been thinking a bit more about this; and I agree with you that 
> >> ApplicationGIS.drawMap() should "do the right thing" taking scale and 
> >> so forth into account as needed.
> > Great!
> Aside - my decision is not abitrary - udig guideline "Code for 
> Convenience" = principle of "least surprise" applies to developers as 
> well as users
> >> It sounds like the issue of printing (from BIRT or iText) may need 
> >> some additional control;
> > Of course it would eventually be desirable to allow udig to make use 
> > of BIRT's full 'device' capability which would enable 
> > device-independent & resolution-independent output to svg, pdf, etc, 
> > as well as image output.  This would mean providing a udig renderer 
> > which renders to the birt device api.  (see 
> > org.eclipse.birt.chart.device.(svg|swt|pdf|...))
> >
> > I don't know anything about udig rendering chain so have no idea how 
> > practical that is.  The results would be very impressive, however.  My 
> > little searching suggested that it would involve building a Graphics2D 
> > bridge on top of birt's device API (kind of the opposite of what 
> > org.eclipse.birt.chart.device.swing.SwingRenderImpl does).
> >
> > But this goes quite far beyond what I'm looking for at the moment, 
> > which is simply getting decent high-resolution output.
> Right; well the question becomes - is scaling a raster onto your advice 
> a good enough approximation?
> >> my gut feeling is we should make some of the MapBoxPrinter / 
> >> ExportMapToImageWizard functionality available for others to reuse as 
> >> a separate issue. I have confirmed that the Rescale code has only 
> >> been applied to trunk.
> > ok.  I keep thinking we should move to trunk, but I guess it's still 
> > not ready for much?
> Hard to know how to respond to that; I can only get paid to work on 
> trunk so that is where the action is for new development.
> Jody
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel