[rfc-i] [IAB Trac] #266: Requirement for "Clear Printing"
rja.lists at gmail.com
Mon Feb 18 16:56:07 PST 2013
On 17 Feb 2013, at 03:17 , Brian E Carpenter wrote:
> Earlier, Joel Halpern wrote:
>> The underlying requirement we are discussing is for printability.
>> It does seem to me that we need a clear requirement tat things be
>> printable. That does not mean it has to have page numbers. It
>> does seem to me to mean that things should be printable on both
>> US Letter and A4 paper. (I doubt it means printable on any form
>> factor paper someone happens to have handy.)
> Well no, although a reflowable format could be printed on a wide
> variety of paper sizes. But to me, a requirement for printing on
> both A4 and US Letter only has meaning if you require the same
> pagination on both; otherwise, why bother? And that means that
> there are page numbers, either printed or implied.
This is what I was trying to get at, albeit I was not expressing
myself as clearly as Brian is. If something prints "equally well"
on A4 and on US-Letter, that does imply that the pagination
would be the same on either paper size, whether that pagination
is explicit with printed numbers or implicit in how the unnumbered
pages get printed out.
As a publication series with global scope, I think RFCs
ought to print "equally well" on both US-Letter and A4
paper sizes. Anything less puts one or another part of
our community on unequal ground, which seems very undesirable.
We've avoided that particular inequality problem for a long while
now, which seems like a huge feature to me.
> Let's be clear, once we allow non-ASCII art and variable width
> fonts, this no longer has anything to do with the number of
> lines on a page or characters per line.
I can accept that:
- RFCs might have multiple file formats. In fact, they
already have multiple file formats. RFC-1305 is a great
example. So that is not an issue in my mind.
- RFCs that have a more complex file-format (e.g. PDF,
Postscript, or similar) will be able to display some
things (e.g. artwork, equations) in a more readable
(or perhaps more pretty) way than RFCs. Again, RFC-1305
is a great example. The equations are MUCH more readable
in PDF than in text/plain ASCII. So again, this is not
an issue in my mind.
- RFCs might be offered in more than one text/plain format.
So if the RFC Editor chose to have more than one text/plain
format, that's fine with me.
- Some format other than text/plain might be "preferred",
whatever that word might might mean.
- The RFC Editor might choose to support a broader character
set than US-ASCII (i.e., ANSI X3.4) -- for example some
might want ISO-8859-* or ISO-10646 in order to be able
to print people's names more accurately -- provided it
is a standard character set.
> We could have a fun conversation about fonts, point sizes and kerning.
I'd rather avoid that swamp, if possible.
I definitely don't want to make sophisticated assumptions
about "all printers" supporting variable fonts, variable
point sizes, or kerning -- at least for the text/plain
format that I'd like to see.
>> Is it sufficient that there be a printable form? Should we require that
>> all forms be printable? What other constraints go with "clear"?
> IMHO it is necessary and sufficient that the canonical form prints
> reproducibly on A4 and US Letter using widely available font(s).
I am still thinking about how to more crisply and clearly
specify what I mean by "clear printing". So what follows
might change a bit after I read more and think more. I'm
not yet confident enough to use the word "sufficient",
but I have a draft definition for "necessary" below.
I believe my definition (below) is consistent with Brian's
intended meaning, but perhaps I am misunderstanding him.
I think it is necessary that any future RFC be available
in a text/plain format that prints:
* equally well on either A4 or US-Letter paper,
* using a dumb line printer (i.e., making no assumptions about
availability of either variable-width fonts or variable fonts
or vector graphics or HP PCL or Adobe Postscript in the printer),
* without using complex print layout/page layout/formatting commands
(e.g., commands present in ISO-646 values 0 through 32 --
such as CR, LF, FF, VT, HT, NUL -- would continue to be fine),
* with ordinary commonplace *command-line* printing tools
(e.g., the CLI "Print" command  on Windows, lp or lpr 
on Unix-like systems)
I definitely would not want to follow the path of another
organisation where documents are PDF-only, in US-Letter
paper format, with US-Letter paper margins, one has to have
a PDF tool to view or to print the documents, etc.
More information about the rfc-interest