Re: [lmi] [lmi-commits] master 4ecd4fe: Print a page number on the duplicate signature page

[Greg Chicares]

On 2018-11-28 00:24, Vadim Zeitlin wrote:
> On Tue, 27 Nov 2018 19:12:02 -0500 (EST) Greg Chicares <address@hidden> wrote:
> 
> GC> branch: master
> GC> commit 4ecd4fe5c5721c1fac41bd72f069008c216a3efc

[...NAIC illustration reg pagination, N = page count excluding cover page:
 (A) old XSL-FO: [cover page], 1 of N-1, ... N-1 of N-1, unnumbered attachment
 (B) yesterday : [cover page], 1 of  N,  ... N-1 of  N , unnumbered attachment
 (C) today     : [cover page], 1 of  N,  ... N-1 of  N , N of N
...]

>  I'm almost certain (but admit not having tested this) that this used to be
> the new code behaviour in its initial version as well, but I must have
> broken it with some of the later changes and didn't even notice it.

I don't know; at some earlier time, it might have used scheme (A).

> GC>     It would alternatively have been okay to use that labelling scheme
> GC>     with wxPdfDoc illustrations,

IOW, (B) is undesirable because its last numbered page says "N-1 of N",
which makes it look like the illustration contains fewer pages than
intended. But either (A) or (C) is fine. And actually (C) was preferred
over (A) by the same insurance company for a recent vendor system.

These days, of course, the definitive illustration is a PDF file rather
than a paper printout stored in a physical file. If a physically signed
copy of a single page is wanted, one would simply print that single page.
There's no reason for a "detachable" duplicate inside the PDF file.
Ultimately, we'll probably instead want:

 (D) ultimately: cover page = 1 of N, 2 of N, ... N-1 of N, N of N
   where N = page count =
           1 numbered cover page
       + N-1 other numbered non-duplicate pages
       +   0 i.e., zero duplicate signature pages

But we aren't ready to do that; it depends, e.g., on potential regulatory
changes such as those proposed in this discussion draft:
  
https://www.naic.org/documents/cmte_a_liii_wg_exposure_draft_rev_to_model_582.pdf

>         but that would constitute a major
> GC>     change.
> 
>  I think it should be possible to change this without too much trouble
> (but, again, I haven't actually tested it yet), so if the original page
> numbering is preferable, I should be able to provide a patch implementing
> it.
> 
>  Please let me know if I should do this,

Not for now. (C) is as good as (A).

However, in the coming year we may want something else such as (D),
so I'd like to understand why this seems like a big change to me but
not to you. When I looked into this yesterday with the aim of changing
from (B) to (A), the relevant part of the inheritance tree was:

class logical_page
  class page_with_marginals : public logical_page    [headers, footers]
    class numbered_page : public page_with_marginals [page numbering]
      class standard_page : public numbered_page     [page layout in MST]
        class ill_reg_numeric_summary_page : public standard_page
          class ill_reg_numeric_summary_attachment : public 
ill_reg_numeric_summary_page

and my first thought was to make the last class derive only from
page_with_marginals, i.e.:

-  class ill_reg_numeric_summary_attachment : public 
ill_reg_numeric_summary_page
+  class ill_reg_numeric_summary_attachment : public page_with_marginals

because (A) needs headers and footers but doesn't need numbering.
However, that wouldn't easily allow using 'ill_reg_numeric_summary.mst'
for layout, AFAICS, because that MST capability is added in a different
inheritance layer, and layers come in a fixed sequence. IOW, we can have
  [headers, footers]; or
  [headers, footers] + [page numbering]; or
  [headers, footers] + [page numbering] + [page layout in MST]
but we can't have
  [headers, footers] + [page layout in MST] without [page numbering]
A lengthy inheritance chain, IOW, can be a very expressive way of
representing a deep permanent structure that can never change, but it's
like carving stone: changing that structure later is a really big deal.
The options I saw were:

(1) make the [page layout in MST] layer a mixin, which would be a
major change; or

(2) copy and paste the [page layout in MST] code for the attachment,
which violates the OAOO principle; or

(3) insert an unholy kludge to adjust the total number of pages in
this special case.

Is there an easier way that I'm not seeing?