Re: [lmi] PDF pagination

[Greg Chicares]

On 2018-02-20 16:07, Vadim Zeitlin wrote:
> On Tue, 20 Feb 2018 16:02:26 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2018-02-20 14:33, Vadim Zeitlin wrote:
> GC> > On Tue, 20 Feb 2018 13:48:30 +0000 Greg Chicares <address@hidden> wrote:
> GC> [...]
> GC> > GC> Thus, addressing your question quoted above:
> GC> > GC>   "... If the headers were the same for all the pages ..."
> GC> > GC> we'll work to make them the same for all pages (though they'll still
> GC> > GC> differ by ledger type). We won't do that now: it's better to test
> GC> > GC> everything thoroughly first, before changing such details.
> GC> > 
> GC> >  I agree that it's best to do it like this, but what should be done for 
> the
> GC> > overflowing explanatory notes?
> GC> 
> GC> Fix now, because it's a blocking issue.
> 
>  This is what I thought, thanks for confirmation. But I still don't see any
> other way to do this, right now, without adding per-page header templates.
> So should I start doing it like this or do you see any other way to do it?

I believe the mce_nasd format uses the same header and the same footer
for all pages, no matter what their content (except for any unnumbered
cover page)--so the question wouldn't arise for that ledger type.

The mce_ill_reg format seems to do the same thing, but with the further
exception of its "Narrative Summary (Continued)" and "Column Headings..."
pages. If (as I suspect) it's easiest to use the same headings for those
"further exceptions", then please do that. (That will make the XSLT and
MFT output differ, but that's okay; we really don't want to make parallel
changes to both unless they're utterly trivial, like the commit I have
queued up that removes one stray character.)

Then, as for the 'reg_d*' formats, just do what the others do.

>  Also, I wonder if we should allow overflowing on all pages or only on some
> selected/specifically marked ones? In principle, as long as we implement
> support for pagination anyhow, it's not more difficult (and probably even
> easier, although also longer, in execution time terms) to do it for all
> pages and not just the notes ones, but I wonder if it's really desirable or
> if it would be better to give an error if some other page overflows
> unexpectedly?

(1) Always use extra pages to avoid overflowing. This is what FOP
appears to do everywhere, and nobody has ever objected to it.

(2) Never fail to produce an illustration because of a problem
that (1) would have solved.

(3) Never show the end user an error message that (1) would have
made unnecessary. If you really want to issue a diagnostic, write
it to std::cerr or std::cout only--never show a messagebox.

I don't think any overflow diagnostic is going to help in any way.
If we saw one, what would we change? Move some footnotes onto
another page? No, (1) does that already. Shorten the text? No,
it's prescribed and cannot be changed just to make pages shorter.