[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