[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] [lmi-commits] master 4ecd4fe: Print a page number on the dupli
From: |
Greg Chicares |
Subject: |
Re: [lmi] [lmi-commits] master 4ecd4fe: Print a page number on the duplicate signature page |
Date: |
Thu, 25 Apr 2019 18:29:23 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
On 2019-04-24 17:47, Vadim Zeitlin wrote:
> On Tue, 23 Apr 2019 16:29:15 +0000 Greg Chicares <address@hidden> wrote:
[...]
> 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.
But see `git show e30ab034bdd149`, which suggests that this mechanism
doesn't actually validate any such thing. I believe that branch commit
demonstrates that the last_page_number_ assertion does nothing if
start_numbering() is called only on the last line of the function, and
fails only if it's never called at all.
Thus, this mechanism seems to enforce only one loose condition: that
start_numbering() is called somewhere for every illustration that
contains numbered pages. But all illustrations contain numbered pages,
does the {last_page_number_, start_numbering()} mechanism actually
serve a useful purpose?
---------8<--------8<--------8<--------8<--------8<--------8<--------8<-------
@@ -2841,8 +2885,13 @@ class pdf_illustration_finra : public pdf_illustration
// Add all the pages.
add<cover_page>();
// PDF !! For the moment, don't number this format's cover page.
- numbered_page::start_numbering();
+ // Well, that was the dream--that the finra cover page wouldn't be
+ // numbered if we "start numbering" only after we "add" that page.
+ // But it's numbered even so.
+// numbered_page::start_numbering();
add<finra_basic>();
+ // Calling start_numbering() again doesn't re-start the numbering.
+// numbered_page::start_numbering();
add<finra_supplemental>();
add<standard_page>("finra_column_headings");
add<standard_page>("finra_notes1");
@@ -2859,6 +2908,18 @@ class pdf_illustration_finra : public pdf_illustration
{
add<standard_supplemental_report>("finra_supp_report");
}
+ // In fact, it's enough to "start numbering" after we "add"
+ // the last page. These statements appear not to be executed
+ // in sequence. Presumably add<> merely signals an intention
+ // to include a page, and there's an implicit step elsewhere
+ // that "really" adds the pages, so start_numbering() can
+ // be called anywhere in the present function.
+ //
+ // First last_page_number_ is initialized to zero, then it
+ // must be initialized by start_numbering() before it's
+ // actually (implicitly) used, or else an assertion fires.
+ // Does that complex mechanism serve any worthwhile purpose?
+ numbered_page::start_numbering();
}
--------->8-------->8-------->8-------->8-------->8-------->8-------->8-------