[rfc-i] [IAB Trac] #266: Requirement for "Clear Printing"
pkyzivat at alum.mit.edu
Fri Feb 15 08:32:25 PST 2013
I guess individual custom does vary widely.
I'm not aware of anybody who uses paper versions regularly.
I think some people do print them to read on a plane, but technology is
rapidly rendering that irrelevant.
I am of an age that grew up on paper. I've been trying to get away from
it for years, and by now I nearly have. I can't remember the last time I
touched a paper copy of a draft.
OTOH, I do usually prefer either the plaintext form, or more often the
HTMLized version of the plaintext that the tools provide. (I really
don't like the HTML version generated by xml2rfc.)
I agree that all versions that are paginated should probably be
paginated the same way. But its less important that the number of lines
per page or characters per line be restricted to current limits. They
should probably be limited so that they can be scaled to fit an 8.5x11"
or A4 page and be readable. Otherwise I don't think it matters much.
On 2/15/13 10:00 AM, RJ Atkinson wrote:
> A key feature of the current RFC publication process is
> that a given RFC (or I-D) will have identical pagination
> -- regardless of whether it is printed on A4 paper,
> printed on US-Letter paper, or even viewed in a web browser
> (i.e., browser showing text/plain format, rather than
> a browser showing HTML format).
> This means that when working with colleagues, one
> can talk about some RFC (or I-D) and use the page
> number as a reference/anchor point in our discussions.
> Today, even folks working from an electronic copy
> (if using the text/plain ".txt" format, rather than the
> HTML format) also have that pagination visible to them.
> It would be a nightmare to have a colleague refer
> to (his/her) "page 4" and have that be "page 3" or
> "page 5" on my own copy. That would be a huge waste
> of a lot of folks' time, and seems easily avoidable.
> While I'm sure that individual custom varies, nearly
> all of the implementers that I know well normally work
> from a printed copy. Similarly, many reviewers of I-Ds
> and readers of RFCs find it more effective to work from
> a printed copy.
> Curiously, in my own (non-scientific) sample of people,
> there is no "generational" aspect to this. This practice
> of working from print when coding or designing an implementation
> seems as common among folks who are 20-something as it is
> with folks who are 40-something.
> While I have no objection to making RFCs available
> in other formats (e.g., HTML without pagination), I would
> be greatly obliged if a print-oriented format with existing
> fixed/predictable/consistent pagination and fixed/predictable
> line-length remained available for those who wish to continue
> to work from the decades-long text/plain (".txt") format.
> The 2 current text/plain format rules cause printing
> to work equally well with A4 and US-Letter paper sizes.
> So one can work trans-Atlantic or trans-Pacific and all
> be on the same page:
> * 58 lines/page
> * 72 characters (plus CR and LF)/line
> So my requested action is that Section 3.3. be revised
> to delete the "retirement" of the 58 lines/page and
> 72 characters (plus CR and LF)/line rules.
> I'd be quite happy if these 2 rules were scoped to apply only
> to the "text/plain" format of RFCs (and I-Ds), such that those
> 2 rules did NOT apply if one were generating an HTML format
> or some other format. Of course, this implies continuing the
> automatic generation of a print-oriented format (i.e., text/plain
> with ".txt" filename extension) that DOES comply with those
> 2 rules.
> This change to the RFC Format Requirements draft would retain
> the critical uniformity of pagination in the existing widely used
> printable format, while allowing flexibility in line-length and
> pagination in other formats (e.g, HTML).
> Ran Atkinson
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest