[rfc-i] [IAB Trac] #266: Requirement for "Clear Printing"
paul.hoffman at vpnc.org
Fri Feb 15 08:22:35 PST 2013
On Feb 15, 2013, at 7:54 AM, RJ Atkinson <rja.lists at gmail.com> wrote:
> On 15th Feb 2013, someone wrote, in part:
>> this was discussed at length on the list earlier, ...
> That earlier discussion, which I watched, was about
> something a bit different from my proposal -- pagination
> as an absolute requirement.
> There is a significant difference in my proposal
> (summary: keep line-length and pagination, but ONLY
> for the text/plain .txt format), which means that the
> earlier discussion isn't terribly germane, whatever
> the consensus might have been.
You are mixing two things here: line-length and pagination. Further, you are assuming (incorrectly, I hope) that there will be only one plain-text format.
Keeping the current 72-character line length restriction has a significant impact on the kind of ASCII art that can be included. Expanding that to, say 90 columns would still allow plain-text output that is viewable in non-VT52 systems and likely to be printable, but would allow *much* more expressive ASCII art, if that is the kind of art the author wants to use.
The RFC Editor currently allows ASCII art to cross page boundaries, so the "pagination" issue you bring up is not related to ASCII art, but to printability. You say "the text/plain .txt format", but there has been many requests on this list for multiple plain-text formats, both with and without pagination.
Assume that an RFC with a lot of ASCII tables and art is being discussed among some developers. I would prefer to discuss the non-paginated one in my discussion and I would refer to things by position within sections and tables; you would probably prefer the paginated one so you can point to page numbers and line numbers within the page. It is trivial for the RFC Editor to produce both types from the canonical source.
More information about the rfc-interest