Skip to content

PB-111: Fix print spec send to the print service #727

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 20 commits into from
Apr 3, 2024

Conversation

ismailsunni
Copy link
Contributor

@ismailsunni ismailsunni commented Mar 21, 2024

Test link

Copy link

cypress bot commented Mar 21, 2024

Passing run #1432 ↗︎

0 170 22 0 Flakiness 0

Details:

PB:111: Update geoblocks/mapfishprint for a WMTS matrix size fix.
Project: web-mapviewer Commit: c8560ea895
Status: Passed Duration: 04:57 💡
Started: Apr 3, 2024 3:24 AM Ended: Apr 3, 2024 3:29 AM

Review all test suite changes for PR #727 ↗︎

@ismailsunni ismailsunni force-pushed the feat-PB-111-fix-print-spec branch 2 times, most recently from dcd4ce4 to c76f625 Compare March 26, 2024 03:01
@ismailsunni ismailsunni marked this pull request as ready for review March 26, 2024 06:28
@ismailsunni ismailsunni requested review from ltshb and pakb March 26, 2024 06:28
@ltshb ltshb changed the title Feat PB 111: Fix print spec send to the print service PB-111: Fix print spec send to the print service Mar 28, 2024
@ismailsunni ismailsunni force-pushed the feat-PB-111-fix-print-spec branch from 39ff8cc to 234ae53 Compare March 28, 2024 06:47
Comment on lines 189 to 190
* @param {String[]} [config.excludedLayers=[]] List of layer names to exclude from the print.
* Default is `[]`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would either pass AbstractLayer instances, or rename this param excludedLayerOlNames to make it clear what it contains

If I understand correctly you will filter layers based on the name we have given them in the OpenLayers context, right?
Might be better to find a way to filter things out based on the layer ID we have in the store (we give each OL layer the same ID as the layer ID in the store, most of the time)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I change it to filter by ID, since I guess it's more common to have ID than name. So, I change the param with excludedLayerIDs to make it more clear. Is that ok?

@@ -84,6 +84,7 @@ async function printMap() {
try {
const documentUrl = await print(printGrid.value, printLegend.value)
if (documentUrl) {
console.log('documentUrl: ', documentUrl)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

little console log left 😉

@ismailsunni ismailsunni force-pushed the feat-PB-111-fix-print-spec branch 2 times, most recently from f70e028 to 06511db Compare March 28, 2024 09:36
@ismailsunni ismailsunni requested review from pakb and ltshb March 28, 2024 09:42
@ltshb
Copy link
Contributor

ltshb commented Mar 28, 2024

@ismailsunni the legend seems not to be printed anymore, at least with the public transport layer and hiking closure layer.

@pakb
Copy link
Contributor

pakb commented Mar 28, 2024

Maybe there's something wrong with how we build the legend attribute, if you have a look here https://github.com/geoadmin/service-print3/blob/develop/print-apps/mapviewer/requestData_legend.json it looks like it should be only one entry with all icons in an array.

We do that instead :

{
  "legends": {
    "classes": [
      {
        "icons": [
          "https://sys-api3.dev.bgdi.ch/static/images/legends/ch.bav.haltestellen-oev_en.png"
        ],
	"name": "Public transport stops"
      },
      {
        "icons": [
          "https://sys-api3.dev.bgdi.ch/static/images/legends/ch.swisstopo.swisstlm3d-wanderwege_en.png"
        ],
        "name": "Hiking trails"
      }
    ],
  "name": "Legend"
  }
}

TL;DR; it works fine with only one layer with legend, but with two it breaks 🙃

@ismailsunni
Copy link
Contributor Author

@pakb that's strange. I will check it why and add a unit test for it also. But I am pretty sure it was working fine with more than one legend.

@pakb
Copy link
Contributor

pakb commented Mar 28, 2024

@pakb that's strange. I will check it why and add a unit test for it also. But I am pretty sure it was working fine with more than one legend.

Maybe my fault when I moved and reworked the code 🙈

@ltshb
Copy link
Contributor

ltshb commented Mar 28, 2024

@ismailsunni @pakb @hansmannj the legend issue with the print might be also due to the service-print3 deployment of this morning, @hansmannj what is the difference of you local service-print3 image and the master and develop latest state ?

@ltshb
Copy link
Contributor

ltshb commented Mar 28, 2024

@ismailsunni @pakb @hansmannj the legend issue with the print might be also due to the service-print3 deployment of this morning, @hansmannj what is the difference of you local service-print3 image and the master and develop latest state ?

I just tried to revert on dev the deployment of service-print3 but the issue with the legend is still present.

@ismailsunni
Copy link
Contributor Author

@ltshb just curious, is it possible to revert the service-print deployment to some time last week? Just to make sure. Because the payloads sent are the same as before, even after refactoring.

@pakb
Copy link
Contributor

pakb commented Mar 28, 2024

@ltshb just curious, is it possible to revert the service-print deployment to some time last week? Just to make sure. Because the payloads sent are the same as before, even after refactoring.

As said, the issue arise when there's more than one layer with legend. If you, by any chance, didn't test that, but only added one layer extra (with legend) before printing, it might have gone under your radar (as mine 🙃 )

@hansmannj
Copy link
Member

hansmannj commented Mar 28, 2024

I'll check on the train in about half an hour.
If I remember correctly, we did not really touch any of the service configurations itself. The only difference should be, that the image is based on a different image tag of c2c.
Our new service-print3 release should be based on an c2c image, which includes some bug fixes which where discovered due to our load testing.
The service config files should not have changed.

Please correct me, if I have it wrong in my mind @LukasJoss

@hansmannj
Copy link
Member

And yes, probably we never had a test case so far, with more than one layer plus legend, might well be.

@hansmannj
Copy link
Member

Probably it is in the print payload.
I guess, this is how it should look like, when there's more than one legend entry: https://github.com/geoadmin/service-print3/blob/c69347869eb7f284886f5352a64aa8042e5f6979/print-apps/mapviewer/requestData_WMTS_legend.json#L226-L237

@hansmannj
Copy link
Member

Testing locally with the payload form the link in my last comment works and results in a PDF with two legends. So maybe there's something wrong with the payload sent by the viewer?

@ismailsunni
Copy link
Contributor Author

@hansmannj @pakb @ltshb
I found the issue. It's legend vs legends. The correct one should be legend. It's indeed very tricky to find, I need to compare with the one that has legend on the older version. I have added the test also for the legend spec. Below is a sample report with the test link above.
mapfish-print-report (49).pdf

Copy link
Contributor

@ltshb ltshb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One last issue that I've noticed, the scale and the disclaimer is always in german in the PDF, I could not find anything related to this in the print payload, @hansmannj is it something that has been hardcoded on the server side ?
image

@ltshb
Copy link
Contributor

ltshb commented Apr 2, 2024

@ltshb I guess that one is related to the service-print. There is this file that contains the disclaimer: https://github.com/geoadmin/service-print3/blob/c69347869eb7f284886f5352a64aa8042e5f6979/print-apps/mapviewer/Report.properties

@hansmannj how is it to translate the scale and disclaimer on the print ?

@hansmannj
Copy link
Member

@ltshb I guess that one is related to the service-print. There is this file that contains the disclaimer: https://github.com/geoadmin/service-print3/blob/c69347869eb7f284886f5352a64aa8042e5f6979/print-apps/mapviewer/Report.properties

@hansmannj how is it to translate the scale and disclaimer on the print ?

Dear all

Thanks for working on the fixes. Regarding the translations, I created this ticket: https://jira.swisstopo.ch/browse/PB-383.
Probably @marionb or @sbrunner could help out here?

Copy link
Contributor

@ltshb ltshb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok from my side this is good to go. The issue with the disclaimer and scale translation can be done later in a separate PR as it might require some backend work.

@ltshb
Copy link
Contributor

ltshb commented Apr 2, 2024

@ismailsunni I allow myself to rebase to develop your PR, @pakb could you eventually have a quick look and if everything is ok @ismailsunni can you merge it tomorrow ? I'd like to deploy on test.map.geo.admin.ch tomorrow and it would be great to have this PR merged before.

@ltshb ltshb force-pushed the feat-PB-111-fix-print-spec branch from 2293d86 to a59e753 Compare April 2, 2024 14:11
Copy link
Contributor

@pakb pakb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM as we will be dealing with the translation of the footer separately.
Also let's keep in mind we need to revert back to a more "stable" versioning of the geoblocks lib ASAP (as soon as it is published)

@ismailsunni ismailsunni force-pushed the feat-PB-111-fix-print-spec branch from a59e753 to c8560ea Compare April 3, 2024 03:21
@ismailsunni ismailsunni merged commit 466cbf4 into develop Apr 3, 2024
6 checks passed
@ismailsunni ismailsunni deleted the feat-PB-111-fix-print-spec branch April 3, 2024 03:29
@cypress cypress bot mentioned this pull request Apr 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants