[rfc-i] Pagination requirements

Martin Rex mrex at sap.com
Tue May 22 16:13:44 PDT 2012

Tim Bray wrote:
> > Since printing with Web Browsers is still an open research problem,
> > the possibility of creating a paper printout of an RFC that will be a
> > close 100% match for printouts created by different people and
> > independent of whether I use "Legal" or "ISO A4" paper is also a
> > requirement.  Including a Table of Contents showing page numbers,
> > because that is how to navigate in printed copies!
> The "open research problem" remark is just not true; every browser I use
> can print beautifully, and deal with a variety of paper sizes depending
> where I am in the world.

I have not found two browser which produce the exact same printout for
a page, and I regularly run into problems where letters or words get
truncated in the printout or graphics misplaced.  The issue is much
worse on printouts than it is onscreen.

> As you note, doing this requires reformatting and
> reflowing, and I appreciate the work that went into the software.
> Pagination is an ephemeral artifact of a particular consumption scenario,
> and page numbers are intrinsically broken as a basis for location and
> reference.

For a 100+ page document, I may not want to print everything at once
all the time, so an option to print 20 pages today and print 20 more
pages in 3 weeks AND having the printouts FIT TOGETHER as if printed
in a single go, is a necessity.  This does work perfectly with the
existing RFC format.  And btw. I'm perfectly fine with the
nostalgic 80-columns fixed pitch format.  In 1996 I wrote myself a
small perl-script feeding into a2ps that puts I-Ds and RFCs 2-up with
pages borders and a prominent title line.  For reviewing and implementing
RFCs and I-Ds ans for reading I-Ds on the plane when travelling to IETFs.
I still use it occasionally, and still use some RFC printouts that are
10+ years old.  My last printouts were rfc2315 & rfc2630, about 6 month ago.


More information about the rfc-interest mailing list