Re: [lmi] Generating pages with tables in the new PDF generation code

[Greg Chicares]

On 2017-08-15 23:01, Vadim Zeitlin wrote:
> 
>  I've finally finished writing and tidying up code for generating pages
> with tables in the new PDF generation code and would like to hear your
> feedback about it if possible.

Is your new code yet capable of producing actual PDF output, so that
we could test it ourselves? It doesn't matter whether it's complete
or polished.

>  First, I couldn't find any acceptable way to define the tables in the
> external Mustache template files, so the tables themselves are implemented
> entirely in code, even if the fixed part of the page before the table can
> still come from the template. This is not ideal because any changes to the
> table require editing C++ code and rebuilding it but, again, I just don't
> see how to specify the table structure externally in anything that could
> still be qualified an HTML templating language.

Presumably an HTML templating language that could do that would require
arrays and would not be simple.

[This is such a big project that I'll write questions in a stream of
consciousness, and perhaps answer some of them later myself.]

What does this system look like from the top level? Is there some prime
mover that invokes template-processing code for narrative sections, as in
this simple example...

>  To make this more concrete, here is how the template for the "Tabular
> Detail" page looks like:
> 
> https://github.com/vadz/lmi/blob/97ddfb2e7532a49b4ac367b6e8b7e3f2d96e9f4c/tabular_details.mustache
> 
> (notice that it has no trace of the table in it)

...and invokes C++ code (example below) for the tables? If that's a
correct guess as to the top-level flow, then how does it know how to
interleave narrative and tabular data? Is the interleaved pattern
hard coded?

Alternatively, would it be possible to generate HTML tables as you're
doing now, and treat them as data that might be passed into a mustache
template? IOW, does mustache permit blobs of already-formatted HTML,
sort of like XML CDATA, so that the whole page could be represented as:

{{>header}}

<p align="center">Tabular Detail</p>

<p align="center"><font size="-1">
Values shown are in {{#HasScaleUnit}} {{ScaleUnit}}s of {{/HasScaleUnit}} 
dollars </font></p>

{{HtmlBlobRepresentingOnePageOfTabularData}}

<br></br>

> and here is the code
> responsible for actually generating the table:
> 
> https://github.com/vadz/lmi/blob/97ddfb2e7532a49b4ac367b6e8b7e3f2d96e9f4c/ledger_pdf_generator_wx.cpp#L1850
> 
>  This code on its own probably doesn't make much sense, but hopefully it
> does become clearer if you look at the definition of
> page_with_tabular_report class at
> 
> https://github.com/vadz/lmi/blob/97ddfb2e7532a49b4ac367b6e8b7e3f2d96e9f4c/ledger_pdf_generator_wx.cpp#L1715

Okay, I had already paged up and read that. I see nothing daunting here;
it doesn't seem essentially different from the group-quote code, where
HTML is composed via C++ strings.

> first. This class basically implements both "Tabular Detail" and "Tabular
> Details, continued" pages at once and avoids code duplication between them
> (and other similar pages in other illustrations) at the price of some extra
> complexity due to another level of indirection.

That sounds good. Code that formats these tables has to be fairly
complex, but probably the only difference between one table and
another is the particular columns it contains.

>  As I said in the beginning of this email, I'd welcome your comments, both
> generally, i.e. if you accept the idea of creating tables in the C++ code,
> at least for now, and any more precise remarks about the code at the links
> above.

It'll take a while to read all this code, but I think I've read
enough to guess the answer to a question I posed above. Seeing
this, beginning at line 910 in the '.cpp' file:

text header_html = interpolate_html
        (R"(
{{#IsInforce}}
LIFE INSURANCE IN FORCE BASIC ILLUSTRATION
{{/IsInforce}}
{{^IsInforce}}
LIFE INSURANCE BASIC ILLUSTRATION
{{/IsInforce}}
)"

I'm guessing that the driver is C++, which occasionally defers
to mustache for economy of expression. But I'm probably missing
something, because 'tabular_details.mustache' is a separate file
that isn't referenced in the C++ code. If you could explain the
top-level code structure in a few sentences, that would greatly
help me understand the context of these source files.