TOC - review calculation

[svamaa]

No description provided.

[peterschaer]

This issue is about checking the calculation of the size of the table of contents (i.e. number of pages) made in

pyramid_oereb/pyramid_oereb/contrib/print_proxy/mapfish_print/toc_pages.py

Line 8 in ec86cb5

class TocPages():

The number of pages that the table of contents needs is used in mapfish_print.py to be compared with the actual length of the table of contents in the PDF. If the two numbers do not match, the PDF is created a second time to correct the page numbers in the table of contents. The most accurate calculation possible prevents the PDF from being created a second time and therefore increases performance.

[peterschaer]

First of all, I looked at some parcels in the canton of Bern to see whether the PDF would be generated a second time. I looked at the following examples:

• Parcel with only one topic: https://www.oereb2.apps.be.ch/extract/pdf?egrid=CH368946357207&lang=de
• Parcel with two hits (but 3 subtopics): https://www.oereb2.apps.be.ch/extract/pdf?egrid=CH743546874207&lang=de
• Parcel with 5 topics (incl. 4 subtopics): https://www.oereb2.apps.be.ch/extract/pdf?egrid=CH368746359439&lang=de
• Parcel with 5 topics (incl. 4 subtopics): https://www.oereb2.apps.be.ch/extract/pdf?egrid=CH643546232754&lang=de

In all these cases, the length of the TOC is two pages. In no case will the PDF be generated a second time. In our current constellation, there is no plot in the canton of Bern that generates a table of contents of more than two pages, so that in our case at least, the PDF is only ever generated once.

@svamaa @michmuel @voisardf @lopo977 Are there examples in your cantons where the PDF is generated twice? I can't really test this from the outside.

[lopo977]

First of all, I looked at some parcels in the canton of Bern to see whether the PDF would be generated a second time. I looked at the following examples:

* Parcel with only one topic: https://www.oereb2.apps.be.ch/extract/pdf?egrid=CH368946357207&lang=de

* Parcel with two hits (but 3 subtopics): https://www.oereb2.apps.be.ch/extract/pdf?egrid=CH743546874207&lang=de

* Parcel with 5 topics (incl. 4 subtopics): https://www.oereb2.apps.be.ch/extract/pdf?egrid=CH368746359439&lang=de

* Parcel with 5 topics (incl. 4 subtopics): https://www.oereb2.apps.be.ch/extract/pdf?egrid=CH643546232754&lang=de

In all these cases, the length of the TOC is two pages. In no case will the PDF be generated a second time. In our current constellation, there is no plot in the canton of Bern that generates a table of contents of more than two pages, so that in our case at least, the PDF is only ever generated once.

@svamaa @michmuel @voisardf @lopo977 Are there examples in your cantons where the PDF is generated twice? I can't really test this from the outside.

In Tessin, both in the worst and best case, we have a table of contents of 2 pages.
There is also no parcel that generates a table of contents of more than two pages

[svamaa]

Extracts with wrong calculation (results in second print request):

https://api.oereb.bs.ch/extract/pdf/?EGRID=CH198970136775
https://api.oereb.bs.ch/extract/pdf/?EGRID=CH516710897827 (only one theme concerned)

We always have 2 pages table of contents. But I could not find a case where the calculation was correct.

[michmuel]

PDF computation in BL:

• 1x

  • https://oereb.geo.bl.ch/extract/pdf?egrid=CH780507397978

• 2x

  • https://oereb.geo.bl.ch/extract/pdf?egrid=CH507859371772
  • https://oereb.geo.bl.ch/extract/pdf?egrid=CH227714824983
  • https://oereb.geo.bl.ch/extract/pdf?egrid=CH256982784938
  • https://oereb.geo.bl.ch/extract/pdf?egrid=CH507939960758

[voisardf]

Computation of the TOC length is mostly incorrect in our case. One of the few examples it is ok:

• https://sitn.ne.ch/crdppf/extract/pdf/?EGRID=CH485599127923

2 calls:

• https://sitn.ne.ch/crdppf/extract/pdf/?EGRID=CH927912974658

In our case, as soon as there are two concerned themes (which is the default for us) and the title for restrictions touching the real estate needs two lines, the computation is wrong by default.

My best guess would be that we need to also calculate the wrapped text length for the concerned themes header, as depending on the municipality name and the 'Grundbuchkreis' there is a line break leading to a wrong computation.
An other guess would be that the default height of one of the elements changed and was not adapted accordingly in the computation. - I need to check that in the templates

[peterschaer]

In my opinion there are several issues with the calculation:

1. Line Breaks in the concerned themes header are not taken into account by the calculation (as mentionned by @voisardf )
2. the calculation does not include the qr code block. This is mentionned as a TODO in the code:

   pyramid_oereb/pyramid_oereb/contrib/print_proxy/mapfish_print/toc_pages.py

   Line 61 in ec86cb5

   # TODO: compute height when QR-Code is integrated

   )
3. The whole block of text (including general information, disclaimers and qr code) is not allowed to have a page break (according to the spec). The calculation does not take this into account. There will be many cases where the calculation comes to the conclusion that the TOC only has one page. In the PDF, however, there are two pages because this text block may not be wrapped and is placed on a new page.
4. There are some small differences in the item heights between the templates and the calculation code. I will put them together.

[voisardf]

thanks @peterschaer

I opened the template and can already confirm the first point: d1 is set to a fixed height of 77px in the computation though it should also be computed.

Here are the screen shots of the template allowing also a better understanding of the code in
https://github.com/openoereb/pyramid_oereb/blob/ec86cb5af4671edd850d5a26c37b5c71dc03ad3b/pyramid_oereb/contrib/print_proxy/mapfish_print/toc_pages.py

One real estate info line in d1:

Two real estate info lines in d1:

In conclusion: d1 should also be computed using the compute_length_of_wrapped_text function

For point 2: QR-Code height is 56px by default

[michmuel]

Thanks @peterschaer for updating the branch. I think we will be able to narrow down the remaining issues next week.

Here some information from the logs from BL using the latest version:

• 1x

  • https://oereb-dev.geo.bl.ch/extract/pdf?egrid=CH780507397978 (TOC=1 --> calculation ok)

    d1 total_size: 77
    d2 total_size: 63
    d3 total_size: 361
    d4 total_size: 44
    d5 total_size: 15
    d6 left total_size : 88
    d6 right total_size : 78
    d6 total_size: 88
    TOC total page length : 726
    disposable height: 772
    number of pages: 1
    

  • https://oereb-dev.geo.bl.ch/extract/pdf?egrid=CH507859371772 (TOC=2 --> calculation ok)

    d1 total_size: 77
    d2 total_size: 148
    d3 total_size: 331
    d4 total_size: 44
    d5 total_size: 15
    d6 left total_size : 88
    d6 right total_size : 78
    d6 total_size: 88
    TOC total page length : 781
    disposable height: 772
    number of pages: 2
    

• 2x

  • https://oereb-dev.geo.bl.ch/extract/pdf?egrid=CH227714824983 (TOC=2 --> calculation not yet ok)

    d1 total_size: 77
    d2 total_size: 80
    d3 total_size: 346
    d4 total_size: 44
    d5 total_size: 15
    d6 left total_size : 88
    d6 right total_size : 78
    d6 total_size: 88
    TOC total page length : 728
    disposable height: 772
    number of pages: 1
    

  • https://oereb-dev.geo.bl.ch/extract/pdf?egrid=CH256982784938 (TOC=2 --> calculation not yet ok)

    d1 total_size: 77
    d2 total_size: 46
    d3 total_size: 391
    d4 total_size: 44
    d5 total_size: 0
    d6 left total_size : 88
    d6 right total_size : 78
    d6 total_size: 88
    TOC total page length : 739
    disposable height: 772
    number of pages: 1
    

  • https://oereb-dev.geo.bl.ch/extract/pdf?egrid=CH507939960758 (TOC=2 --> calculation not yet ok)

    d1 total_size: 77
    d2 total_size: 63
    d3 total_size: 376
    d4 total_size: 44
    d5 total_size: 0
    d6 left total_size : 88
    d6 right total_size : 78
    d6 total_size: 88
    TOC total page length : 741
    disposable height: 772
    number of pages: 1
    

[michmuel]

Are topMargin and bottomMargin possibly relevant as well (just a thought)?
https://github.com/openoereb/pyramid_oereb_mfp/blob/8d9da5ab3a8d1a8469fd693e4f86c5870ee9f6dc/print-apps/oereb/toc.jrxml#L3

[peterschaer]

Yes, topMargin and bottomMargin are relevant but not yet included in the calculation. Thanks for the hint.

I included those two values. Could you test again?

[michmuel]

Now, it is close. One example misses the correct value (one or two pages) by 2.

These (<box bottomPadding="">) are not relevant in any case?

• https://github.com/openoereb/pyramid_oereb_mfp/blob/533eed468eeefda6f2a3c07b5031a9d84962cdf7/print-apps/oereb/toc.jrxml#L151C15-L151C23
• https://github.com/openoereb/pyramid_oereb_mfp/blob/533eed468eeefda6f2a3c07b5031a9d84962cdf7/print-apps/oereb/toc.jrxml#L205C5-L205C27
• https://github.com/openoereb/pyramid_oereb_mfp/blob/533eed468eeefda6f2a3c07b5031a9d84962cdf7/print-apps/oereb/toc.jrxml#L234