[rfc-i] use cases for page breaking hints, Re: Update on the plain text thread(s)
mellon at fugue.com
Mon Jun 30 07:02:45 PDT 2014
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.
More information about the rfc-interest