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

[Vadim Zeitlin]

On Mon, 24 Jul 2017 15:57:54 +0000 Greg Chicares <address@hidden> wrote:

[snip all the rest of the discussion, I might return to it later after
 rereading it more attentively, but for now I'd just like to
 concentrate on the most critical part]

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. In C++ code it's not
GC> >   really nice neither, but is doable because I know the height of the page
GC> >   and the height of each line of text, so it's just a question of tracking
GC> >   the number of lines and I do this already in 
group_quote_pdf_generator_wx
GC> >   code. But with external templates I am really not sure how to do it, I
GC> >   think it could involve modifying wxHTML again.
GC> 
GC> When I was young and foolish I proposed this:
GC>   http://trac.wxwidgets.org/ticket/5730
GC> My motivation was to generate illustrations as HTML that could be displayed
GC> and printed with wxHTML. I won't claim today that this patch was any good,
GC> but I just thought I'd mention it.

 Thanks, I completely forgot about it. I'll look at it but, just for the
record, wxHTML does support CSS2 <div style="page-break-before:always">
tags for manual page breaks. This is not enough for our needs here on its
own, however...

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.

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).

GC> A further complication is that we want spacing between consecutive sets
GC> of five table lines, without breaking any five-line group across pages.

 Yes, I'm aware of this but didn't implement this (even in the manual
version) yet.

GC> Another is that we could add a command to preview an illustration as
GC> HTML, in a wxHTML window: that could be a more-detailed optional
GC> alternative to the present calculation summary, and would be faster
GC> (I imagine) than any PDF preview.

 I expect PDF generation to become much faster with the new approach, but
it's true that not generating it at all can only be even faster...

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).

 Regards,
VZ