[mapserver-dev] Better resolution handling for printing

Alan Boudreault aboudreault at mapgears.com
Thu Feb 19 16:54:31 EST 2009


On February 19, 2009 03:32:50 pm Alan Boudreault wrote:
> Hi Tamas,
>
> I think the "magnification" concept could be good. I suppose that the
> resolution parameter will simply set internaly the magnification setting.
> What could be the behavior if the user use the magnification and the
> resolution? 

That's ok, i've just re-read you first mail.

> Is it a problem if we lost some precision with all integer
> values ? ie: if the magnification is set to "2.34", all interger values
> will be multiplied... but probably rounded after.
>
> Thanks for you thoughts!
> Alan
>
> On February 18, 2009 02:26:04 pm Tamas Szekeres wrote:
> > Alan,
> >
> > I think this issue is more about a theoretical than a technical problem.
> > It depends on how do we define the concept of the resolution related to
> > the size and sizeunit settings.
> > For example when we set sizeunit=MS_PIXELS and setting the symbolsize to
> > 8, I consider the every would expect to draw the symbol at exactly 8
> > pixels in width regardless of the actual resolution setting.
> >
> > On the other hand we could declare alternative concepts as well. For
> > example we declare that this is only the case when the resolution is set
> > exactly to 72.0 dpi and at any other setting the actual drawing width
> > will increase/decrease proportionately. If this concept is acceptable
> > then you could safely multiply the scalefactor with resolution/72.0 when
> > drawing the symbols/labels in the code.
> >
> > However you might want to allow the user to set this magnification factor
> > manually either by using this new parameter or the using
> > resolution/default_resolution concept mentioned by Daniel before.
> >
> > Best regards,
> >
> > Tamas
> >
> >
> >
> > 2009/2/18 Alan Boudreault <aboudreault at mapgears.com>
> >
> > > Tamas,
> > >
> > > I would like to add the resolution handling for printing transparently
> > > without
> > > the necessity to use another keyword. And if we decide to add the
> > > "magnification" keyword ulteriorly, we will probably be able to use the
> > > same
> > > code/functions.
> > >
> > > Any other thoughts about how could we achieve the better resolution
> > > handling?
> > > Else, i'll begin to check in code for the best way to increase/decrease
> > > all values dependently of the resolution value.
> > >
> > > Alan
> > >
> > > On February 11, 2009 05:19:10 pm Tamas Szekeres wrote:
> > > > Daniel,
> > > >
> > > > I would introduce a new parameter of the map called 'magnification'
> > > > which would be multiplied with the resolution when calculation the
> > > > scale. In addition the scalefactor should also multiplied with this
> > > > in
> > >
> > > msPrepareImage
> > >
> > > > to achieve the desired effect.
> > > > I guess it wouldn't be annoying for the user that by setting
> > >
> > >  magnification
> > >
> > > > = 2.0 would increase the width of the map elements 2 times.
> > > > magnification = 1.0 would be the default value.
> > > >
> > > >
> > > > Best regards,
> > > >
> > > > Tamas
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 2009/2/11 Daniel Morissette <dmorissette at mapgears.com>
> > > >
> > > > > Dev's,
> > > > >
> > > > > When using MapServer to generate a printable map at higher
> > > > > resolution than the default screen resolution, say 300dpi instead
> > > > > of 72dpi, it is not sufficient to update the map->resolution
> > > > > setting since all the
> > >
> > > label
> > >
> > > > > and symbol sizes as well as line widths also need updating if you
> > > > > want
> > >
> > > to
> > >
> > > > > maintain the same map appearance.
> > > > >
> > > > > This issue has been discussed a few times before and I even think
> > > > > some have worked on this at their end. We have a client who needs a
> > > > > fix for this so I'd like to open a discussion on this before we go
> > > > > ahead and prepare a RFC.
> > > > >
> > > > > The approach I was thinking of using is to add a new
> > > > > map->defresolution (better names welcome) that would be the default
> > > > > resolution of a given mapfile, that is the reference resolution for
> > > > > which all sizes in
> > >
> > > labels,
> > >
> > > > > classes and styles are set.
> > > > >
> > > > > In normal web browsing operation, map->defresolution should be set
> > > > > to
> > >
> > > the
> > >
> > > > > same value as map->resolution (e.g. 72dpi). When you want to print
> > > > > a 300dpi map, then you'd set map->resolution=300, and MapServer
> > > > > would automagically apply a factor of
> > > > > map->resolution/map->defresolution to
> > >
> > > all
> > >
> > > > > size values in the mapfile before rendering. For instance, if your
> > > > > mapfile is set for a defresolution of 72dpi and you request a
> > > > > output resolution of 300dpi, all size values would be multiplied by
> > >
> > > 300/72=4.16
> > >
> > > > > and labels, lines and symbols on the resulting map would have the
> > > > > same/expected relative sizes.
> > > > >
> > > > > I think I've read suggestions of setting resolution as an
> > > > > outputformat option before, but this may not work well with remote
> > > > > (e.g. WMS) services, we need something better integrated and with
> > > > > the proposed approach just passing a new vendor-specific resolution
> > > > > param in the WMS GetMap URL could do the trick.
> > > > >
> > > > > Does my explanation make sense? Has anyone worked on this problem
> > > > > already? Any thoughts on this before we start working on a RFC?
> > > > >
> > > > > Daniel
> > > > > --
> > > > > Daniel Morissette
> > > > > http://www.mapgears.com/
> > > > > _______________________________________________
> > > > > mapserver-dev mailing list
> > > > > mapserver-dev at lists.osgeo.org
> > > > > http://lists.osgeo.org/mailman/listinfo/mapserver-dev
> > >
> > > _______________________________________________
> > > mapserver-dev mailing list
> > > mapserver-dev at lists.osgeo.org
> > > http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev



More information about the mapserver-dev mailing list