[mapserver-dev] Better resolution handling for printing

[Brent Fraser]

Dan,

  I'm salivating too!  I've made a minor enhancement (not checked in) to the Cairo code (in the sandbox/graphics branch) to specify the page size, map position and scale:

  OUTPUTFORMAT
    NAME Cairo_pdf
    DRIVER 'CAIRO/PDF'
    MIMETYPE "application/x-pdf"
    FORMATOPTION "PAGE_WIDTH=2448"          # page points (72 per inch)  34 inches
    FORMATOPTION "PAGE_HEIGHT=1728"         # page points 24 inches
    FORMATOPTION "MAP_MARGIN_LEFT=144"      # page points
    FORMATOPTION "MAP_MARGIN_BOTTOM=144"    # page points
    FORMATOPTION "SCALEDENOM=50000"    
  END

And here's the output http://139.142.13.163/Download/Mapserver/topo_cairo_082H04.pdf

I'd love to see it working with GeoMoose's PDF output.

Maybe we need a plan to move the Cairo code out of "pre-alpha" into alpha or beta...

Brent


Dan Little wrote:
> In my mind, we should strive to have a reasonable vector output that can be scaled to large resolutions easily.  My first thought is PDF, which is actually why I'm salivating at the chance to dedicate some time to improving the PDF renderer.  Of course,
>  when bitmap inlays are used (symbols, water-marks, etc.) there's still going to be an issue as they do not scale "up" nice.
> 
> 
> 
> ----- Original Message ----
>> From: Bob Basques <Bob.Basques at ci.stpaul.mn.us>
>> To: szekerest at gmail.com; dmorissette at mapgears.com
>> Cc: mapserver-dev at lists.osgeo.org
>> Sent: Wednesday, February 11, 2009 5:39:35 PM
>> Subject: Re: [mapserver-dev] Better resolution handling for printing
>>
>> Completely off topic, but . . . .
>>
>> . . . . Oooh,  I like that idea, what about adding in an extention that allows 
>> for detailing an area of interest in a Magnified mode and embed that into a 
>> single output image, sort of like a embedded scalebar.
>>
>> Ok, maybe not so off topic, with the ability to control the label scaling and 
>> such, this might look kind of interesting as an output option.  I know I have a 
>> use for static (map) reporting processes right now.
>>
>>
>>
>> bobb
>>
>>
>>>>> Tamas Szekeres 02/11/09 4:19 PM >>>
>> 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 
>>
>>> 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
>