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

[Vadim Zeitlin]

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> > On 2018-11-28 00:24, Vadim Zeitlin wrote:
GC> >> On Tue, 27 Nov 2018 19:12:02 -0500 (EST) Greg Chicares <address@hidden> 
wrote:
GC> >> 
GC> >> GC> branch: master
GC> >> GC> commit 4ecd4fe5c5721c1fac41bd72f069008c216a3efc
GC> > 
GC> > [...NAIC illustration reg pagination, N = page count excluding cover page:
GC> >  (A) old XSL-FO: [cover page], 1 of N-1, ... N-1 of N-1, unnumbered 
attachment
GC> >  (B) yesterday : [cover page], 1 of  N,  ... N-1 of  N , unnumbered 
attachment
GC> >  (C) today     : [cover page], 1 of  N,  ... N-1 of  N , N of N
GC> [...]
GC> > Ultimately, we'll probably instead want:
GC> > 
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.
GC> 
GC> I've done some work toward this end on new branch 'odd/foliation', and
GC> would like to ask several questions about it:
GC> 
GC> Why is 'using base_class::base_class' required? Is this just a modern
GC> way of "inheriting" the signature of the ctor?

 Yes, exactly. It's also the only way of inheriting the ctor, so there is
no other alternative except for just duplicating the base class ctor(s),
which has all the obvious drawbacks.

GC> Given:
GC>   class A {public: virtual void foo();};
GC>   class B : public A {};
GC>   class C : public B {public: void foo() override;};
GC> If the implementation of C::foo() requires calling the base foo(),
GC> should it invoke
GC>  - A::foo(), which can readily be found; or
GC>  - B::foo(), which doesn't exist--on the theory that if B::foo() is
GC>    ever implemented, then C::foo() should most likely call it?

 Personally I believe B::foo() is the best answer because calling it can't
be wrong, while calling A::foo() can and sometimes will be.

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.


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.

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.
Unfortunately, wxHTML has nothing like sizers (amusingly, modern CSS
preferred layout mechanism does look a lot like wxFlexGridSizer, but wxHTML
has no support for it, of course), so we can't easily define the layout we
want, with the bottom aligned marketing name footnote and logo. So the best
way I see to make the cover page adapt to any height automatically is to
split it into cover_top.mst and cover_bottom.mst and then insert as much
vertical space as needed between the top and the bottom halves in the code.
This shouldn't be too bad, so IMO it counts as "reasonable", doesn't it?


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.

GC> In order to implement (D) for all ledger types except one, is there
GC> any simpler way than retaining the original class under a new name
GC> such as 'cover_page_legacy', with inline comments describing how to
GC> remove it when we implement (D) for 'mce_finra' as well (as is bound
GC> to happen later this year)?

 I'd probably call it finra_cover_page for consistency, but other than this
nitpick, I don't see any better way to do this.


 Sorry if my reply is not very useful, but you seem to have already found
all the right answers anyhow, so there is not much I can do to help.

 Regards,
VZ