Print: Part of layer doesn't get printed as expected

[jacobwod]

Describe the bug
It seems that some layers - I'm still unsure what distinguishes them - don't print as expected.

I'd like to stress that I'm not sure whether it's a bug with the print plugin, or some failing configuration on the WMS-side.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://karta.halmstad.se/?m=ext&x=105216.62641218647&y=6282585.614277525&z=7.406143810225275&l=58%2Ch91wc9%2C100&p=print and activate the Print plugin
2. Set print scale to 1:1000. You will see that there's a layer selected that contains some text labels. Those are now visible in map (also if you zoom the map to 1:1000), so you'd expect them to be printed when you select the same scale.
3. Print.
4. Open the resulting PDF. You will see that only some of the text labels are visible. It seems like the bigger labels get printed but the smaller won't.

Screenshot and PDF
See attached PDF and compare it to the screenshot below.

[jesade-vbg]

This can sometimes happen when you set visibility i GeoServer. In some occations we've had to change visibility levels in GeoServer for crucial printing scenarios.
To ba able to print at specific DPI (lets say 300), requests are sent to geoserver to get higher res images. In this case a diffrent scale is triggered and the layer visibility changes. If you have scale 1:1000 and print 1:1000 with xxxdpi you will perhaps get scale 1:500 from GeoServer, if the layer isnt visible at that scale it wont get printed.. Basically, what you see is Not what you will get. Please correct me if I'm wrong @Hallbergs.

[jacobwod]

That's sounds reasonable but I thought I compensated for this in my checks before writing this issue (I tried with 72, 150 and 300 DPI - all with the same result). But I'll check once more, more carefully. Thanks.

[jesade-vbg]

Maybe I'm wrong. It was just my initial thought

[jacobwod]

This is extremely unreliable. Another browser this time and all DPI options actually show the labels. Using the same print settings. I don't get it. 🤯

[Hallbergs]

I was just about to comment that i could not reproduce, haha. (Chrome).

[Hallbergs]

I would suggest to look at the requests created when printing. Do they include the correct dpi etc?

[jesade-vbg]

disable cache and test again

[jacobwod]

Just examined the requests. I think I see what the problem is: we ignore the zIndex from OpenLayers.

I want to print a combined image, consisting of three layers. Here's what I see:

So far so good.

---

When I print, we see 3 requests, as expected:

If you want, you can try out the requests in your own browser (just expand the section below):

Details

1: LAYERS=digiplan_grans

2: LAYERS=digiplan_anvbest_text%2Cdigiplan_egenbest_text

3: LAYERS=digiplan_anvbest%2Cdigiplan_egenbest

---

But how does the composed PDF look like? Like this.
Kartexport - 3_22_2023, 12 50 14 PM.pdf

To me, it looks as if we ignore the zIndex and just use the order in which the requests return from server. Since at least one of those layers is fully opaque, we don't see anything below (which happens to be our labels).

What's your take on this? 🤔

[Hallbergs]

Im currently in a meeting, will look later today. Might have missed the z-index tbh! That theory fits well with the fact that the result differ from time to time.

[Hallbergs]

I've just had a look at the code running when generating the prints...
Check this out:

When we print, we hide all original layers, and create "exchange layers" (copies basically) so that we can mess with their loader functions instead of the "real" loader functions.

The z-index is missing from the created ImageLayer! Instead i (for some reason) check where in the layer array the original layer was placed, and add the "exchange layer" at the same place. I think the issue would be solved if the original z-index is added to the new one. I guess i thought that the placement in the array would be enough (or that the z-index would be on the source - and that it would be added when i spread the original properties on the exchange source).

[jacobwod]

Good find! I think that we should respect OL's current zIndex value. It gets especially important now when we have the Active layers tab in LayerSwitcher. I'll see if I manage to get a look into it this week, thanks!

[Hallbergs]

Yes of course! It's a miss by me!

[jacobwod]

Doesn't matter! 😄

[jacobwod]

You're correct. Take a look at the last 2 entries in this debug:

It's clear that the text layer should, according to the zIndex be placed on top of the last one. But the calculated layerPlacement tells otherwise and we end up with polygons covering the texts.

I'll see what I can do about it.

[Hallbergs]

const layerOpacity = layer.getOpacity() ?? 1;
const layerZIndex =  layer.getZIndex(); "<------"
// Then we can create the new image-layer with the new image-source.
const imageLayer = new ImageLayer({
  opacity: layerOpacity,
  source: imageSource,
  zIndex: layerZIndex, "<------"

});

Should do the trick!? :)

[jacobwod]

Yes, pretty much - see ba33524 😉