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

Dearlove, Christopher (UK) chris.dearlove at baesystems.com
Fri Jun 27 06:18:04 PDT 2014

Agreed, keep together is not always the right answer. Although if human inserted, the human might have a clue. The question then is how much you trust that the human will have only used it sensibly?

The (incomplete) algorithm I indicated partly covers that. It doesn't allow the text to move onto the next page if that then messes up the table. What it (and I think nothing) can handle is the "if you do this here to avoid a slight nasty, ten pages later something nastier happens". Rare, but possible. (I once deleted some text from Word and the document got longer - that was, IIRC, down to turning a four line paragraph, split 2+2, into a 3 line paragraph, which to avoid a widow or an orphan split 0+3. Then the extra line rippled forwards to eventually causing an extra page of several lines.)

If the table breaks (and at the least, that will happen if it's more than a page long)  a heading rows repeat feature is good. Assuming we can flag what is the heading (maybe just <ttcol> elements?). And ideally, also disallow some breaks in table (which could be done by putting keep on a <c>, for example, or a structure above <c>).

(I need to look into <preamble>.)

Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove at baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke at gmx.de] 
Sent: 27 June 2014 14:03
To: Dearlove, Christopher (UK); Heather Flanagan (RFC Series Editor); rfc-interest at rfc-editor.org
Subject: Re: use cases for page breaking hints, Re: [rfc-i] Update on the plain text thread(s)

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.

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.

Best regards, Julian
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.

More information about the rfc-interest mailing list