Re: [lmi] Group quotes: empty footnotes

[Vadim Zeitlin]

On Sat, 10 Oct 2015 04:29:33 +0000 Greg Chicares <address@hidden> wrote:

GC> They have different footnote requirements:
GC> 
GC>     footer_           =
GC>                           
escape_for_html_elem(ledger.GroupQuoteIsNotAnOffer   )
GC>         + "<br><br>"    + 
escape_for_html_elem(ledger.GroupQuoteRidersFooter   )
GC>         + "<br><br>"    + 
escape_for_html_elem(ledger.GroupQuotePolicyFormId   )
GC>         + "<br><br>"    + 
escape_for_html_elem(ledger.GroupQuoteStateVariations)
GC>         + "<br><br>"    + escape_for_html_elem(ledger.MarketingNameFootnote 
   )
GC> [above: state regulation--all products]
GC> [below: federal regulation--some products]
GC>         + "<br><br><b>" + escape_for_html_elem(ledger.GroupQuoteProspectus  
   ) + "</b>"
GC>         + "<br><br>"    + escape_for_html_elem(ledger.GroupQuoteUnderwriter 
   )
GC>         + "<br><br>"    + 
escape_for_html_elem(ledger.GroupQuoteBrokerDealer   )
GC>         ;
GC> 
GC> We laid it out that way so that the two families' PDF files are pretty
GC> much indistinguishable except for the extra footnotes at the end. For
GC> the first family (state regulation only), the last three footnotes are
GC> present but invisible, because they're empty strings. Their associated
GC> <br> line breaks are also unconditionally present, simply because I
GC> didn't put enough thought into the design when I added them.
GC> 
GC> A problem arises if, in the future, we rearrange footnotes. Suppose
GC> we move the second one to the end. Then the PDF has an unsightly gap
GC> due to the unconditional <br><br>, and we'd like to eliminate that gap.
GC> I.e., if a footnote is an empty string, then its <br><br> should not be
GC> written at all. (The criterion really is string::empty(); we will not
GC> specify any all-blank strings.)
GC> 
GC> Vadim, would you please put this aside for a couple weeks at least,
GC> and then propose a patch?

 Hello,

 Here is a patch that fixes the problem by replacing all the expressions of
the form

        footer_ += <tag> + string;

with the calls to a helper function:

        footer_ += wrap_if_not_empty<tag>(string);

IMO using such helper is better than explicitly writing

        if(!string.empty())
            {
            footer_ += "<tag>" + string;
            }

many times because it eliminates the risk of stupid errors due to testing
one string and then outputting another one and also seems more readable to
me.

 But it does make the code longer, so ideally, I'd like to write just this
instead:

        footer_ += tag << string;

with operator<<() taking care both of omitting the empty tags and of
closing the tag if necessary before converting the result to string. I.e.
the real code could then look like this:

        footer_ +=
            html::tag::br
                << html::tag::br
                    << html::tag::b
                        << html::text_if_not_empty(invar.GroupQuoteProspectus)
        ;

 I didn't implement this because I didn't know if you would agree to do it
like this, but I think it would be worth doing and I'd also like to change
the rest of the already existing code for HTML generation to use this
approach instead of just manipulating the raw strings, with all the
concomitant dangers (e.g. forgetting to escape something or escaping
something twice).

 For example, the following snippet

    html_table += wxString::Format
        ("<td nowrap align=\"right\"><b>%s%s&nbsp;&nbsp;</b></td>"
         "<td>%s&nbsp;&nbsp;&nbsp;&nbsp;</td>"
        ,escape_for_html_elem(name)
        ,(value.empty() ? "" : ":")
        ,escape_for_html_elem(value)
        );

could then be rewritten as

        html_table +=
            (html::tag::td
             << (html::tag::b
                    << html::text(name)
                    << html::text(value.empty() ? "" : ":")
                    << html::nbsp << html::nbsp
                )
            )
            <<
            (html::tag::td
                << html::text(name)
                << html::nbsp << html::nbsp << html::nbsp << html::nbsp
            )
            ;

which is, admittedly, still longer, but provides compile-time safety (i.e.
a typo in "nbsp" or lack of closing tag would be detected) and is arguably
more clear as well.

 Do you think it would be worth writing HTML generation code like this?

 Of course, even if you do, it will take a bit longer, so in the meanwhile,
the attached patch could still be applied to fix the problem at hand.
Please let me know if you see any problems with it that I should fix. FYI,
I tested it by manually editing sample.policy and commenting out the
corresponding entries and it seems to work as expected.

 Regards,
VZ

0001-Don-t-output-unnecessary-empty-footnotes-lines-in-gr.patch
Description: Text document