[rfc-i] Pagination requirements

Iljitsch van Beijnum iljitsch at muada.com
Wed May 23 14:45:10 PDT 2012


On 23 May 2012, at 23:22 , Joe Touch wrote:

>>  or by having alternative
>> print-ready versions published by the RFC Editor.

> 	we just as easily generate "display on a ridiculous device"
> 	formats for those who insist on wanting to read RFCs on
> 	4" smartphone displays too ;-)

The difference is that printing is a fairly deliberate process, while you could end up with an RFC on your (large or small) screen by following a link, and then having to backtrack and find a different format and look up the linked section is rather inconvenient.

The canonical version doesn't have to be all things to all people, but a format that prints reasonably and displays on small screens reasonably using standard tools is better IMO than a format that prints great but displays poorly or displays great but prints poorly. But if the choice is between the latter two, then printing poorly it is.

> Why is that good enough for printing HTML and not for viewing TXT in a browser?

Actually _viewing_ current RFCs in a browser on a big(ish) screen is pretty good considering. But you really do need a screen that is relatively large. Even an ebook reading device can't handle the current format very well.

> My concern is that over-optimizing for browsers is tossing the ability to print readable paper out the window - and it's a bit premature for that.

Can you explain a bit more your concerns about printing? Obviously a browser doesn't print as well as good type setting tools. But do we need the latter level of performance for RFCs? I'm trying to understand what the must-have features are for printing.


More information about the rfc-interest mailing list