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

Dearlove, Christopher (UK) chris.dearlove at baesystems.com
Mon Jun 30 10:01:20 PDT 2014


Giving me a hard time for using a linguistic discussion in an informal posting when that's nothing to do with the subject is completely inappropriate. Repeating it, more than doubly so. Go fight that war somewhere where it matters. The fact that you've decided to spend effort on that rather than anything of substance is telling.

Furthermore you can't even read what I've been posting when you say " I would encourage you to stop focusing on how you personally would use plain text, though"

I've been focussing on printability, not plain text per se. I'll just note that Brian Carpenter thinks documents should be printable. I think I can probably leave him to make it happen.

Your whole discussion or reflowability is also beside my point. I'm not trying to impose nothing flowable on you.

I see no point in continuing to discuss this with you.

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance 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: Ted Lemon [mailto:mellon at fugue.com] 
Sent: 30 June 2014 15:03
To: Dearlove, Christopher (UK)
Cc: Riccardo Bernardini; Julian Reschke; rfc-interest at rfc-editor.org; Heather Flanagan (RFC Series Editor)
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 Jun 30, 2014, at 4:56 AM, Dearlove, Christopher (UK) <Chris.Dearlove at baesystems.com> wrote:
> Now that's just an attempt to discredit when arguments have failed.

Why do people make assumptions about my motivation?   I am not attempting to discredit you.   I'm giving you a hard time for using a linguistic construct that I would like to see forgotten, but that doesn't mean I think you are a bad person or want anyone else to think you are a bad person.   I would just like to see people stop using the generic masculine, and so when someone uses it I hassle them.   That's how I got out of the habit: by being hassled.   I meant no disrespect.   That comment wasn't intended to be an argument about the topic of plain text at all.

I would encourage you to stop focusing on how you personally would use plain text, though.   It's important that the solution that we implement work in general, not just for individual use cases, and it's difficult to weight your own use case accurately, because it feels a bit too real.

The reason we are where we are is because the current RFC toolchain doesn't support re-flowable text, and re-flowable text is very desirable in this modern age.   People with good eyesight can read PDFs or full-sized text on their tiny devices, but I can't, and many consumers of RFCs can't.   So re-flow is necessary.

Given that as a starting point, numbering pages simply doesn't work, and so page breaks don't make sense as a canonical thing.   That doesn't mean that you can't format an RFC with page numbers if you want, if that's how you prefer to read RFCs. But you can't use those page numbers in the way you would use information from a canonical document, and there is no practical way to make that work without getting rid of reflow.

E-books currently tout a feature called "real page numbers," but this isn't really all that useful, because a "real page" in an e-book typically spans multiple e-book pages, and typically ends in the middle of an e-book page.   So it's sort of useful for pointing to a general area of text, but useless for the user of an e-book when trying to describe precisely where on the page any given comment applies.

Suppose you wanted to have pagination and numbers.   Why not put the number of the paragraph that's split at the beginning of the page, or that begins the page, where the page number now goes.   You would no longer see page numbers increase by one--they'd increase by paragraph count.   But you'd still have a number to refer to, and have interoperability with people who are using different reflow schemes; indeed, you could choose a paper flow scheme according to your particular preference, e.g. A4 rather than 8.5x11", and have it come out nicely, instead of having bad margins and a ton of unnecessary whitespace as is the case now.   You could even have a TOC that refers to the numbers at the bottoms of pages.   It'd take some getting used to, but I think not very much.


********************************************************************
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