lmi
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]