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

Sean Leonard dev+ietf at seantek.com
Sat Jan 24 09:23:48 PST 2015

On 1/24/2015 12:32 AM, Carsten Bormann wrote:
> On 2015-01-24 07:27, Sean Leonard wrote:
>> An attribute to control page breaking within the element should be added.
> That is almost trivially true.
> I don't understand why we have the two keeps and not the third.
> This feels about like saying let's use only the letters a to q in order
> to not complicate the alphabet.
+1. That is the point.

It doesn't make sense to force "keep with next" and "keep with 
previous", if you're going to break the next or previous paragraph right 
after the first (or before the last) line. Presumably you want to keep 
both paragraphs together, and you want to keep both paragraphs (or at 
least one of the two paragraphs) intact. Therefore you need a "keep 
together" attribute.

Consider text that looks like this:

 > Vestibulum et ex euismod, interdum mi at, sagittis tellus.
 > In in dui velit. Etiam nec lectus a nisi molestie
 > luctus. Pellentesque molestie efficitur tempor.
 > ¶
 > That is the point: lectus a nisi.
 > ¶
 > Nulla a libero sapien. Curabitur sagittis leo nunc, ut
 > suscipit nibh aliquet non. Morbi sed eleifend tellus,
 > nec vulputate nisl. Lorem ipsum dolor sit amet,
 > consectetur adipiscing elit. Mauris eget sem nec
 > turpis pretium varius. [FIGURE X] phasellus sem ante, lacinia
 > a egestas malesuada, tincidunt sit amet leo. Integer
 > ullamcorper leo ac nulla congue, non sodales
 > nibh tristique, as shown in [FIGURE X] below:
 > Figure X: Caption related to [FIGURE X]
 > Postamble regarding [FIGURE X]
 > Subsequent text regarding [FIGURE X] or
 > other topics...

Suppose you want to keep Paragraph 1 with next, and Paragraph 3 with 
previous. Where are the appropriate page breaks? Well breaking up 
paragraph 1 across multiple pages doesn't make sense: it's too short. 
Paragraph 2 can't be broken because it's just one line. But, the 
processor may attempt to break within Paragraph 1 anyway. The processor 
is more likely to break Paragraph 3 (since it's bigger, just 
probability-wise it's a bigger surface area to cut in half), but maybe 
it's important to keep Paragraph 3 together or only cut it right in the 
middle before it starts talking about [FIGURE X]. That is why you need 
"keeptogether", and/or widow/orphan controls.

Then there's the relationship between Paragraph 3, [FIGURE X], and the 
subsequent text (caption, postamble, subsequent). It is reasonable to 
request that all of that stuff hang together. It's also reasonable to 
hint that certain areas are better for page breaking than others, e.g., 
between the "postamble" (which I understand is no longer a formal part 
of the v3 vocabulary, thus it looks just like a standard <t> paragraph) 
and the following text. Depending on the nature of [FIGURE X], it is the 
author's choice whether to allow or inhibit breaking the figure across 

> (OTOH, I don't think there need to be attributes for widow/orphan
> control; this is best left to the defaults.

The above examples illustrate not only keeptogether, but also 
widow/orphan controls. The broader point about widow/orphan controls is 
that in Western typography, "the defaults" should be at least 2, not 0 
or 1. Sometimes it might be 3. By having a non-zero default, you 
emphasize to paginated media processors that you need widow/orphan 
controls. It's more like an author has the option to opt-out, rather 
than opt-in.

>    I'm also not so sure about
> "always",

Always means "generate a page break here". Useful for separating 
sections in a forceful manner, which has the effects of a) clearing the 
air, and b) allowing a significant amount of space. This is useful, for 
example, when dealing with figures that will probably occupy a 
significant fraction of a page/view. "Figures" can include source code 
or other modules, such as collected ASN.1 or other modules found in 
appendices (see the lengthy discussion about that in Improvement #8.)

The current definitions have @keepwithnext and previous to be 
"true/false". That is not semantically correct. It is not possible to 
guarantee that all text will be kept with adjoining paragraphs if the 
joined paragraphs in total occupy more than a page length. Thus terms 
like "avoid" or "inhibit" are more appropriate.

> and even less about "left/right".)

Yes...I don't have much to say about left/right.


More information about the rfc-interest mailing list