[rfc-i] v3imp #2 Control over paginated output

Sean Leonard dev+ietf at seantek.com
Fri Jan 23 01:02:34 PST 2015


Improvement Need
#2 Control over paginated output

This improvement calls for greater control over hinting at paginated 
output. To make this improvement concrete, I advocate for including all 
of the pagination controls in CSS 2.1 Section 13.3: Page breaks 
<http://www.w3.org/TR/CSS21/page.html#page-breaks>. These include 
{page-break-before}, {page-break-after}, {page-break-inside}, {orphans}, 
and {widows}. Use that standard (or use the semantics underlying that 
standard) and be done with it.

To summarize what I read on the list thus far: a substantial number of 
contributors have called for this. A few detractors have stated that it 
is not necessary because the canonical format is not cognizant of 
pagination.

Personally, I am not as invested in this compared to Improvement #1. 
However I have a lot of experience with trying to force figures and text 
to appear on specific pages of the paginated output, most recently with 
draft-josefsson-pkix-textual-10.pdf. This experience informs this 
Improvement #2.

Here is the thing: maybe the canonical format is not cognizant of 
pagination, but people are. You have to look at this from the standpoint 
of *users* of IETF standards, which is variously: a) software 
developers, b) users of software that employ the standards, c) other 
SDOs and legal functionaries (the UN, courts of law, blah blah), and d) 
the general public.

None of these constituents with the possible exception of a) really give 
a crap about the canonical XML format. Users will be looking at these 
things on all sorts of output devices and media, but rarely in the 
original XML form. They're just not going to see it. Authors' wishes 
regarding where things do or don't break across output media is 
therefore critical for comprehensibility of the standards documents.

In the draft-josefsson-pkix-textual case, some text and figures are 
notably sensitive to arbitrary line or page breaks. Since the text 
specifically calls out the interoperability problems with arbitrary 
breaks, it would be grossly inappropriate to break the examples across 
multiple pages (or "views", for virtual pages). In 
draft-josefsson-pkix-textual I did not make non-conforming/lax examples 
that include arbitrary breaks; however, the converse argument can be 
made for forcing arbitrary page breaks in examples or spec-text to 
illustrate a point in other standards documents.

I am not advocating to include CSS in the canonical XML format—just the 
pagination semantics. Using attributes such as @page-break-after, 
@page-break-before, etc. would work all right.

Sean



More information about the rfc-interest mailing list