[lmi] Cover-page simplification [Was: master 4ecd4fe: Print a page number on the duplicate signature page]

[Greg Chicares]

On 2019-04-24 17:47, Vadim Zeitlin wrote:
> On Tue, 23 Apr 2019 16:29:15 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2018-11-28 17:45, Greg Chicares wrote:
> GC> >  (D) ultimately: cover page = 1 of N, 2 of N, ... N-1 of N, N of N
> GC> >    where N = page count =
> GC> >            1 numbered cover page
> GC> >        + N-1 other numbered non-duplicate pages
> GC> >        +   0 i.e., zero duplicate signature pages
> GC> 
> GC> The full original posting is here:
> GC>   https://lists.nongnu.org/archive/html/lmi/2018-11/msg00045.html
> GC> 
> GC> We want to implement (D) now--but to exclude the 'mce_finra' ledger type
> GC> because it would require a regulatory filing.

'mce_finra' is still treated the old way for now, but today we've
achieved (D) above for two of the other three ledger types (and
the fourth already had the (D) behavior).

> GC> Or would it be better to refactor this as
> GC> 
> GC>   class A {
> GC>     protected: virtual void do_foo(); // overridable part
> GC>     public: void foo() // not virtual
> GC>       {
> GC>       // code that must be done first
> GC>       do_foo(); // call virtual
> GC>       // code that must be done last
> GC>       }
> GC> 
> GC> ?
> 
>  Yes, I think it would (FWIW this is called "template method" pattern,
> which is confusing to C++ programmers because it has nothing to do with C++
> templates, but you have to remember that the word "template" does also have
> a meaning in languages other than C++, such as English). I'm too lazy to
> hunt for the exact reference in the archives, but I'm pretty sure that I've
> proposed something like this a couple of times in the past but you found
> that it introduced unnecessary complexity (I do agree that this version is
> more complex, I just think that in many cases its advantages outweigh the
> extra complexity), so I've been trying to avoid using it unless the
> alternative was really unpalatable.

That's what "template method" is supposed to mean? It's just polymorphism,
and the minimal snippet above illustrates the obvious (and probably the
only correct) entirely general way to override virtual functions, so I
have no objection to it where it's appropriate.

However, perfect generality, if even achievable, is costly. It's hard or
impossible to know in advance which virtuals will need to be elaborated
this way.

> GC> Should cover_page derive from standard_page rather than numbered_page,
> GC> in the hope that numbered_page::get_extra_pages_needed() will DTRT for
> GC> the cover page?
> 
>  get_extra_pages_needed() definitely should DTRT, but the problem is that
> we can't define the cover page contents using just the HTML template,
> precisely because of the rectangle mentioned below. So as long as we keep
> this rectangle, we can't derive cover_page from standard_page.

Now, we can, because we've removed that rectangle. (Except for
'mce_finra', but we'll remove that last special case in due time.)

> GC> Is there any reasonable way to make the big rectangle on the cover page
> GC> adapt to the height of any footers we might add there? (If that's not
> GC> easy, then we might ask whether that rectangle is truly worthwhile.)
> 
>  The rectangle on its own is not a problem, as it's just drawn around the
> cover page contents. The problem is the ugly hack in cover.mst adding just
> enough of <br> tags to make the cover page contents fill up the page area.

Today I was very glad that you'd mentioned that, because with the
changes committed a few hours ago I had to remove some of those
<br> elements.

> GC> Is the {last_page_number_, start_numbering()} mechanism worth keeping?
> 
>  If we're never going to have unnumbered pages before the first numbered
> one, things could be simplified, of course. I'm not sure how safe such
> assumption would be however and adding this mechanism back if we need it
> again would be much more complicated than just keeping it in the code even
> if we don't use it.

All pages should be numbered sequentially--that's the goal that
must be reached; and, once it's reached, we will never, ever go
back and re-add this mechanism. When it's been reached, we'll
return to this question.