[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:21:15 PDT 2014

Sure, there are bad cases. But there are also good ones. Do we prohibit someone from doing something that makes his document better, because someone else might use those tools to make his document worse?

And we could always have a mode that goes "ignore what the user said about this".

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: Riccardo Bernardini [mailto:framefritti at gmail.com] 
Sent: 27 June 2014 14:17
To: Julian Reschke
Cc: Dearlove, Christopher (UK); Heather Flanagan (RFC Series Editor); rfc-interest at rfc-editor.org
Subject: Re: [rfc-i] use cases for page breaking hints, Re: 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 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,
> Best regards, Julian
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
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