DPI-parameter not taken care of properly while printing (IMAGE-WMS)

[Hallbergs]

In the print-plugin, we allow the users to select in what DPI they want the map the be printed. If the user selects 300 DPI the plugin does in fact create an image with higher picture quality than if 150 DPI was selected, all good so far.

It seems like we have forgotten to provide proper DPI-details in the requests to the WMS-servers though, making the WMS-styles be incorrect in the print.

This is solved for tiled WMS, but should be solved for image (single-tile) WMS as well.

[Hallbergs]

I think i've gotten this sorted. My solution checks if the print-plugin is trying to load tiles bigger than a maximum tile-size (set in admin, defaults to 4096px), and if a the plugin tries to fetch a bigger tile (height or width bigger than the maximum tile-size) i apply a custom loader that splits the request into smaller tile-requests, so that the WMS-server can handle them.

The custom-tile-loaders also adds the DPI-parameters to the requests (Example for 300 dpi: DPI=300, FORMAT_OPTIONS=DPI:300, and MAP_RESOLUTION=300).

There will be an admin-setting where the administrator can choose if they want to enable 'custom-tile-loaders' or not. They will also be able to select a maximum tile-size (my guess is that 4096 is a good max value).

[Hallbergs]

The solution mentioned above works well, but during testing we found that tiled WMS-services had some strange behavior when printing. The tiled WMS-services seemed to load a lot of unnecessary data when creating the print (around 3x more tiles than necessary were fetched).

After alot of work i think i've finally managed to come up with a working solution for both tiled and single-tiled sources. The solution consists of replacing each tiled source with a single-tile source during the print-process, and use the custom loaders to make sure that the WMS-servers can handle the requests. When the printing is completed (or canceled) we remove the new sources and add the old ones again.

I am seeing drastic changes in how fast high-dpi images are created, and the images seems to be created with the correct styling, very nice!

[jacobwod]

The results are fantastic!

[jesade-vbg]

Looks great! But I think I noticed that layers with opacity set to less than 100% (In my case 0% opacity) gets opacity 100% when printing.

[Hallbergs]

Looks great! But I think I noticed that layers with opacity set to less than 100% (In my case 0% opacity) gets opacity 100% when printing.

Oh damn. Yes i've missed to take the current opacity into consideration. Will take a look when i get a chance.

[Hallbergs]

Looks great! But I think I noticed that layers with opacity set to less than 100% (In my case 0% opacity) gets opacity 100% when printing.

Oh damn. Yes i've missed to take the current opacity into consideration. Will take a look when i get a chance.

Should be fixed in develop now via 15c9c65

[Hallbergs]

Just added another commit (0328862) to develop. Now hidpi layers are handled correctly as well. The commit contains a lot of changes since i managed to simplify the logic quite a bit.