lmi
[Top][All Lists]
Advanced

[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-------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]