[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Unit test for PDF get_extra_pages_needed() function
From: |
Greg Chicares |
Subject: |
Re: [lmi] Unit test for PDF get_extra_pages_needed() function |
Date: |
Mon, 12 Feb 2018 13:55:58 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 |
On 2018-02-12 13:02, Vadim Zeitlin wrote:
> On Mon, 12 Feb 2018 10:59:18 +0000 Greg Chicares <address@hidden> wrote:
[...use case: print PDFs for a census with a cell that lapses immediately...]
> GC> Expected outcome: a PDF is created for each cell, and another one for the
> GC> composite. The first cell's PDF reflects its immediate lapse, somehow
> GC> (there may be some freedom in how we do that), but that doesn't prevent
> GC> the other cells from running or the composite from being generated.
> GC>
> GC> Running with '--pyx=only_old_pdf' produces the desired outcome. The first
> GC> cell's PDF has zero data rows: it's like a PDF with one data row, except
> GC> that it has no data rows.
>
> I.e. we still want to produce a table, with row headings, even if it
> doesn't contain any rows? This seems a bit strange to me, even if
> definitely still better than the current behaviour.
Maybe--see below.
> GC> Running with '--pyx=only_new_pdf' produces only one PDF, for the first
> GC> cell only, and that PDF consists of a single blank page; because this
> GC> assertion in pre_render()
> GC> LMI_ASSERT(extra_pages_ >= 0);
> GC> fails, processing stops, and no PDF is created for the second cell,
> GC> even though that second cell is valid.
>
> This is one problem: error reporting is very poor and I need to improve it
> by giving an actual, user-readable error, saying that the PDF generation
> failed and, probably, also removing the incomplete output PDF (I'm not sure
> about the latter part, what do you think?).
Those are good questions too, but see below.
> GC> I'm not sure exactly what we should ideally do for the first cell.
> GC> The '--pyx=only_old_pdf' behavior is acceptable because it has been in
> GC> production for decades and nobody has complained about it. Probably we
> GC> should copy that behavior. As an enhancement, maybe there should be some
> GC> indication that it lapsed (we'll have to see what end users think).
>
> Please let me know if you'd prefer to wait until we know what this
> indication should be or whether I should modify the code to output empty
> tables.
We've reached a decision. You have two choices, so please pick whichever
produces the cleanest, most maintainable code in the end:
(1) Do exactly what the production system does, as described above for
'--pyx=only_old_pdf'.
(2) If there are zero data rows, print a special PDF file containing
only a string like this:
"No illustration produced: lapsed in month %s of the first year."
plugging in the actual month on the current basis, similar to the way
lapse year is used in 'reg_numeric_summary.mst':
{{#LapseYear_Current_LT_MaxDuration}}
<p>
Additional premium will be required
in year {{LapseYear_Current_Plus1}}
or contract will lapse based on current monthly charges
and interest rate.
</p>
{{/LapseYear_Current_LT_MaxDuration}}
except that this would use LedgerVariant::LapseMonth instead of
LapseYear, and would be done for all ledger types (not just for
the one that uses the "reg_*" templates).
Whichever option you choose, show no diagnostic in the zero-rows case:
IOW, it's not an exceptional condition. Accordingly, do not delete the
PDF file.
> GC> However, I don't think we can throw an exception and stop processing
> GC> the census. If the 900th of 1000 cells lapses before the end of the
> GC> first year, end users will have to alter the input to prevent that,
> GC> in order to get PDFs for the last 100 cells; but the input file might
> GC> be exactly what they want, such that they won't want to alter it.
>
> This would seem to imply that write_ledger_as_pdf() shouldn't throw any
> exceptions at all, but how should it report errors then? Alternatively,
> either ledger_emitter::emit_cell() or emit_ledger() could catch any
> exceptions and show them, but it's still not clear how should error
> reporting work.
I'm not sure that I can answer this question in the general case right
now, or that an all-encompassing answer is needed immediately. But in
this specific case is that zero rows is not exceptional.