[rfc-i] use cases for page breaking hints, Re: Update on the plain text thread(s)

Riccardo Bernardini framefritti at gmail.com
Fri Jun 27 06:17:16 PDT 2014


On Fri, Jun 27, 2014 at 3:02 PM, Julian Reschke <julian.reschke at gmx.de> wrote:
> On 2014-06-27 14:43, Dearlove, Christopher (UK) wrote:
>>
>> For the second case. (Apologies if some of this is grandmother
>> egg-sucking, but I wasn't sure where to stop assuming, so I have "explained"
>> things I'm sure you know better than me.)
>>
>> Well, the functionality is there in most word processors like Word.
>>
>> A typical simple use case is that I have an IANA section that goes
>>
>> Table 1 describes the A characteristic ...
>>
>> Table 1
>>
>> Table 2 describes the B characteristic ...
>>
>> Table 2
>>
>> Etc.
>>
>> Now suppose that the tables are kept unbroken. It's just cleaner and
>> easier if the text describing the table is above it on the same page, rather
>> than possibly on the previous page. Typically that costs no more pages, and
>> is just easier to read. And with the right capability, painless to do.
>>
>> (There are probably better examples, that will do for now.)
>
>
> In xml2rfc, you could use the <preamble> element.
>
>
>> So in Word etc. I'd tag the paragraph above the table with "keep with
>> next".
>>
>> I would guess this as an attribute of a <t> and maybe some other things.
>> There is however a problem compared to my example, which is that my example
>> the first thing is a simple paragraph. A <t> can have all sorts of
>> structure. There's typically another concept, keeping lines together, which
>> does make sense with a <t>. But do I have to have one without the other?
>> This is why I don't have anything like a fully worked out suggestion.
>>
>> I did once talk to the coder of an obscure word processor. The basic keep
>> with next concept for him was
>>
>> A is being kept together with B (we implicitly assumed A and B wouldn't
>> break - I realise that's the devil in the details)
>>
>> If A and then B will fit on the current page, do that.
>>
>> If not, but A and B will fit together on the next page, page break and do
>> that.
>>
>> If not, put A on this page and B on next (i.e. ignore keep).
>>
>> I think the basic keep together process is similar. It's the interaction
>> that's harder to define.
>
>
> The problem here is that "keep together" isn't always the right answer. If
> the result is that we end up with an almost empty page, I'd rather prefer
> the page break to appear between introduction and table, or even the table
> to be broken if it's sufficiently long.
>

Definitively +1.
I talk by experience.  I read some documents where this "keep the
table/figure here" option was active.  The result was that if there
was not enough space at the bottom of the page, the figure/table was
moved on the next one, leaving half page empty, giving the impression
that the chapter was finished.   Even worse, sometime the figure/table
would fill *almost* the remaining space, but not all; the result is
that just a line of text was positioned after the figure before going
to the next page.  At a first reading you did not notice the last
line, go to the next page and... discover that the sentence made no
sense; you do back and forth a couple of time and then you discover
the missing line...

In general, for a paginated medium, my experience is that having
"floating" figures and tables is the best option.  Actually, if you
just take any printed book you'll see that figures and tables are
almost always at the top or at the bottom of a page.

Best regards,
Riccardo
> Best regards, Julian
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest


More information about the rfc-interest mailing list