lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] PDF pagination


From: Greg Chicares
Subject: Re: [lmi] PDF pagination
Date: Mon, 19 Feb 2018 22:11:17 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 2018-02-19 12:50, Vadim Zeitlin wrote:
> 
>  There are several problems with implementing real pagination in PDF
> generation code, but the first one of them is that there is simply not
> enough information to do it correctly currently: the template, such as
> reg_d_indiv_notes1.mst, doesn't contain anything that could be used to
> deduce what should be output in the beginning of the new page. In fact, I
> don't even know it myself, but I'm almost sure that the logo should be
> repeated on each extra page and I suspect that the "Explanatory Notes"
> header should be present on subsequent pages as well -- but there is just
> no way to tell, programmatically.

The XSLT implementation does what you suspect: it repeats the logo and
the "Explanatory Notes" heading. In principle, it is not wrong for the
new code to do the same as the old. In this particular case, it's
clearly okay.

>  Worse, I wonder if the subsequent pages don't need something like
> "Explanatory Notes (continued)" header which would be even more impossible
> to generate automatically.

That's not necessary. The XSLT implementation does no such thing. It
repeats the same heading (discussed above) and footer on each page,
and fills the space between with as much content as it finds room for.
Its algorithm for splitting that (non-footer, non-header) content
seems to treat it as a flat set of lines: e.g., if there are 100 lines
of content, and 47 lines on a page, then it'll put 47 lines on each of
two pages and (100-47-47) on the last--without regard to what those
lines contain.

Yesterday I mentioned a two-line definition that XSLT split across
two pages, and noted that that's not ideal. But it would also be ideal
to repeat the "Column Definitions" subheading, perhaps with "continued"
in parentheses. But then it would be ideal, too, to write "continued"
after only the lowest-level header that's repeated, thus:
  Explanatory Notes (continued)
if no subsection is split, but
  Explanatory Notes
  Column Definitions (continued)
if there's a split subsection--because writing "continued" twice is
ugly. The only limit on the precious refinements we might contemplate
is our power of imagination.

But computer-generated forms with variable-length content generally
aren't models of typographic art. I imagine most people don't even
look at these illustrations on physical paper--they're more likely
to examine them on a screen, where HTML would be more welcome,
because it scrolls better, than a series of PDF pages with sizeable
headers and footers. Thus, two millennia after the codex displaced
it, the rotulus has proved the more useful format at last. I don't
think we should spend any time making prettier text pages than XSLT.

>  So I think that we may need to change the 1-to-1 relationship between
> (logical) pages and their templates and have separate templates for the
> header and the body of every page and, if my suspicion about the need to
> use a different header for the continuation pages is correct, also another
> template for the headers of the extra pages. I.e. instead of just
> reg_d_indiv_notes1.mst, we'd have reg_d_indiv_notes1_header.mst,
> reg_d_indiv_notes1_body.mst and, maybe, reg_d_indiv_notes1_header_cont.mst.

Perhaps we can find a simpler solution that does everything we need.
Examining a small handful of XSLT-generated illustrations, I see a
common pattern:

---HEADER BEGINS---
[graphical logo]
[a single one-line heading, which might be a zero-line empty string]
---HEADER BEGINS---

where I'd hope the one-line heading might be a variable rather than
a separate template file (if the variable is an empty string, would
it print with zero height?); and

---FOOTER BEGINS---
[see note 1 below]
[a solid line across the page]
[see note 2 below]
---FOOTER ENDS---

Note 1: Some illustrations contain a line stating that they're not
complete "unless all pages as noted below are included". This seems
superfluous, as "page N of 10" surely makes that clear, but getting
permission either to remove it where it occurs, or to add it where
it doesn't, could be difficult in practice.

Note 2: This portion seems to be two lines that present different
permutations of the same handful of data in different columns.

In both the Note 1 and Note 2 cases--as suggested above for the
header--could we avoid an extra template by expressing the
contents in a variable?

Ideally, of course, we'd remove the gratuitous inconsistencies and
use a standard header and a standard footer for all "extra" pages
like these "explanatory notes".

I haven't analyzed this exhaustively, but I have an impression
that the footer might already be the same for all pages in any
illustration, so that, e.g., perhaps the existing 'nasd_footer*'
templates could be used for all pages in an mce_nasd PDF.

>  This is obviously rather heavy and inconvenient, but I just don't see what
> else can we do. If the headers were the same for all the pages, we might be
> able to use some <fixed_end/> pseudo-tag in the template and then split the
> single file into parts before and after this tag (although I'm not sure how
> to do it with wxHTML right now), but if the header needs to vary, even this
> wouldn't be enough.

Okay, tomorrow I'll ask whether we can make these headers and footers
invariant across ledger types.

>  Can you see any better approach or should I do it like this and start
> working on the pagination logic itself (which doesn't look like a very
> simple problem neither, but should be doable...)?

Alternatively, is it possible to work on the pagination logic first
(because no one has bothered to specify it in the past, and whatever
FOP did was deemed acceptable) while we look into simplifying the
headers and footers (which have been consciously specified, though
at different times and in different styles)?



reply via email to

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