Re: [lmi] Handling page numbering in page classes hierarchy (was: Print a page number on the duplicate signature page)

[Vadim Zeitlin]

On Wed, 28 Nov 2018 17:45:28 +0000 Greg Chicares <address@hidden> 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> >  I think it should be possible to change this without too much trouble
GC> > (but, again, I haven't actually tested it yet), so if the original page
GC> > numbering is preferable, I should be able to provide a patch implementing
GC> > it.
GC> > 
GC> >  Please let me know if I should do this,
GC> 
GC> Not for now. (C) is as good as (A).

 OK, thanks for answering this.

GC> However, in the coming year we may want something else such as (D),
GC> so I'd like to understand why this seems like a big change to me but
GC> not to you.

 Because I immediately thought of a couple of hackish ways to fix it not
involving changing the classes hierarchy which would indeed be more
difficult.

GC> When I looked into this yesterday with the aim of changing
GC> from (B) to (A), the relevant part of the inheritance tree was:
GC> 
GC> class logical_page
GC>   class page_with_marginals : public logical_page    [headers, footers]
GC>     class numbered_page : public page_with_marginals [page numbering]
GC>       class standard_page : public numbered_page     [page layout in MST]
GC>         class ill_reg_numeric_summary_page : public standard_page
GC>           class ill_reg_numeric_summary_attachment : public 
ill_reg_numeric_summary_page

 Yes, this is the current situation. As any deep[er than one level]
hierarchy it's not very flexible, but it allows to reuse the code naturally
and concisely and so IMHO is not too bad here, especially because I didn't
expect the pages relationships to change often.

GC> and my first thought was to make the last class derive only from
GC> page_with_marginals, i.e.:
GC> 
GC> -  class ill_reg_numeric_summary_attachment : public 
ill_reg_numeric_summary_page
GC> +  class ill_reg_numeric_summary_attachment : public page_with_marginals
GC> 
GC> because (A) needs headers and footers but doesn't need numbering.
GC> However, that wouldn't easily allow using 'ill_reg_numeric_summary.mst'
GC> for layout, AFAICS, because that MST capability is added in a different
GC> inheritance layer, and layers come in a fixed sequence. IOW, we can have
GC>   [headers, footers]; or
GC>   [headers, footers] + [page numbering]; or
GC>   [headers, footers] + [page numbering] + [page layout in MST]
GC> but we can't have
GC>   [headers, footers] + [page layout in MST] without [page numbering]

 This is correct and to really do what you'd like, we'd need to extract
everything related to page layout in MST in a mix-in class or just a helper
object that could be included in the classes that need it. This would
definitely be more flexible than the current approach, but would also be
more verbose and, in some sense, more complicated, so I'm not sure if it's
worth it. But it definitely could be done and it wouldn't be at all
unreasonable to do it like this.

GC> A lengthy inheritance chain, IOW, can be a very expressive way of
GC> representing a deep permanent structure that can never change, but it's
GC> like carving stone: changing that structure later is a really big deal.

 Yes.

GC> The options I saw were:
GC> 
GC> (1) make the [page layout in MST] layer a mixin, which would be a
GC> major change; or
GC> 
GC> (2) copy and paste the [page layout in MST] code for the attachment,
GC> which violates the OAOO principle; or
GC> 
GC> (3) insert an unholy kludge to adjust the total number of pages in
GC> this special case.
GC> 
GC> Is there an easier way that I'm not seeing?

 I don't think so, but I don't believe (3) is that evil. The two
possibilities I thought about were:

(3a) Add numbered_page::end_numbering() similar to the existing
     start_numbering() and call it before adding the attachment pages.
     This makes attachments symmetric with the cover page and so seems
     rather appealing to me. The "unholy" part of this is that it could
     be used to remove numbers from non-attachment pages too (and it's not
     hard to imagine that this could happen accidentally), so maybe it's
     better to let the page itself determine whether it should count for
     the total pages number or not, i.e. do this instead:

(3b) Add virtual numbered_page::is_attachment() returning true by default
     but override it to return true in ill_reg_numeric_summary_attachment 
     and update numbered_page to take it into account. If we do it like
     this, it would make it somewhat redundant to override both this
     function and get_page_number() in this class, so in this case I'd make
     get_page_number() non-virtual and would just hardcode "Attachment"
     footer for the attachment pages.

 Again, I realize that we are not actually going to change anything at all
right now and if we're really going to use (D) in the future, all this code
could be simplified instead of complicating it further, but if we wanted to
restore (A), I think either (3a) or (3b) would be an acceptable way to do
it.

 Regards,
VZ