Re: [lmi] Discussion of using external templates for PDF generation

[Greg Chicares]

On 2017-07-24 17:31, Vadim Zeitlin wrote:
> On Mon, 24 Jul 2017 15:57:54 +0000 Greg Chicares <address@hidden> wrote:

[...switching from your first approach (write C++ code that writes HTML)
to the second (external HTML template files) seems preferable iff we can
figure out how to handle tables, which you haven't had time for yet...]

> GC> That is a real problem. We can't decide which approach is better until we
> GC> know whether both can handle tables adequately.
> 
>  FWIW I'm pretty sure that manual approach can handle tables adequately,
> but I didn't finish implementing them with it neither yet as it's not that
> simple there neither.
> 
> GC> > - The second problem with tables is even worse as I just don't know how
> GC> >   to solve it currently: it's about page breaks.
[...]
> GC> Page numbering is a crucial regulatory requirement
> 
>  Yes, I realize this and this is why I thought, from the very beginning,
> that it would be better to separate different pages from each other, and
> the current code is very page-oriented.

This leads to an idea that you've probably already thought of, but I hadn't,
so let me mention it here.

I originally thought that we'd be generating a single, monolithic HTML
stream (perhaps with tables somehow embedded) that would have to be
translated to PDF. However...the code is heavily page-oriented because
illustrations are (due to regulations)...so would it be useful to create
a separate HTML stream (string, or file, or whatever) for each page?
Then they could be combined into a single PDF.

That wouldn't be useful unless the HTML somehow knows how much space
it takes, so that it can split tables or sets of footnotes onto separate
pages.

> GC> Here's an idea that probably doesn't help: write the HTML without page
> GC> breaks (as HTML is normally written), and then break it into pages and add
> GC> page numbers when rendering it to PDF. That would work well enough for
> GC> breaking up the tables themselves, but we need headers and footers on
> GC> each page.
> 
>  And not all pages have headers nor do they all have the same footers (the
> cover page doesn't have one at all, the last one has "Attachment" in it
> instead of the page number).

Indeed.

> GC> I agree that it seems clearly better, provided that we can find good
> GC> solutions to the pagination and table issues; so isn't resolving those
> GC> issues the critical path that we must traverse before turning this strong
> GC> inclination into a final decision?
> 
>  Yes, hence the real question is whether I should try to implement this
> right now, before trying to complete the existing illustration generation
> code. This is basically the difference between the previously discussed
> approaches (1) and (2).

The principles in conflict are "don't throw good money after bad"
and "sunk costs are sunk". Idea Two seems so attractive that I'd
recommend suspending work on Idea One, instead addressing the
uncertainties (pagination, tables) in Idea Two. We know we want to
reduce those uncertainties anyway, so this is worth doing even if the
difficulties prove to be insurmountable. The only thing we'd sacrifice
is an earlier delivery of a substantially complete Idea One system
that we could begin testing as soon as we have it. However:

 - The delay is probably weeks at most, rather than months.

 - The expected result of testing is that we might find a small
   number of simple problems in your implementation, and innumerable
   grave flaws in the specification (i.e., in the XSL files).

 - The next, arduous phase is to puzzle out what the specification
   should be, and alter the new code to conform to the corrected
   specification. We certainly don't want to do that for Idea One
   only to switch later to Idea Two.

Therefore, yes, I recommend pursuing Idea Two (external templates)
now instead of spending time finishing an Idea One implementation.