Julian Reschke wrote:
On 14.03.2010 19:45, Phillip Hallam-Baker wrote:
Since the preferred submission formats are XML or nroff, I see no reason
that the HTML version could not be generated from the XML.
Are there numbers available from the RFC Editor about the
use of XML vs nroff for document subissions during the past 1/2 years?
I would not be surprised if the prefered document format would
also vary with the document size, and might be related to some
authors desire to publish the content elsewhere as well.
The net effect appears to be that there is no HTML version available,
even if the authors exclusively used HTML for the production process.
Hence, what I consider to be entirely justified anger on this point.
I think we should encourage the future RFC-Editor to publish the (X)HTML
version as well, when available (*).
For some documents, there seems to be an alternative version of the
document available, at least in PDF format. tools.ietf.org should probably
add a URL for a "floating" HTML version in addition to the floating PDF
version when an alternative document format is available.
Compare http://tools.ietf.org/pdf/rfc2616
with http://tools.ietf.org/pdf/rfc2817
If you look at the floating PDF for rfc2616, it has some formatting flaws
(like a missing non-breaking space in the expression "(STD 1)" at the
very beginning of the document and defective spacing in section 1.4
around the "ascii arts" diagram. Problems that do not exist in
the plain text ASCII version of that RFC.
So the big plus for the ASCII document version is that an author can
spend his time entirely on the content and doesn't have to worry
as much about formatting as with XML/HTML with arbitrary output
page sizes and font sizes. And a document format that does not,
by default, limit the line length to at most 100 chars should
*NOT* be used. The most preferred line length is ~75 chars per line.
(the printed copy of ISO-C 9899:1990 that I have on my desk uses 96 cpl).
And I firmly believe that the RFC Editor should continue to provide
RFCs preformatted in the original ASCII text format so that they can
still be displayed and used without any kinds of tools in the exiting
environments, and contents of RFC can be copied into source code
comments without any reformatting.
And just for the sake of the fun of it, I just sent a plain RFC
to our laser printer here (HP M5035MFP) with netcat (nc).
The printer honours the Formfeed just fine!
The left margin is a little narrow, but that's an easy one
Unix: sed 's/^/ /' < rfcxxxx.txt | nc -w 1 hp-net-printer 9100
Cygwin: sed -b 's/^/ /' < rfcxxxx.txt | nc -w 1 hp-net-printer 9100
One thing that is odd, though: the RFC Editor seems to constantly
produce incorrect length title pages. The lines with the form
feed are at lines (59,115,171,227), which means that there are
two excessive CR+LF on the title page.
Printing the documents with Microsoft Word is not that difficult.
Load it as .txt, remove two newlines at the beginning of the
title page, select page margins at 1"/1" left&right, font
courier new and font size 10 throughout should work on A4 paper.
Printing them 2-up probably makes sense, and may be easier to your
eye that a free-floating 1-column printout of an HTML-version
of the document.
And on something like an iPhone, with a screen resolution of 320x480,
a traditional ASCII RFC should display just fine in fullscreen landscape
mode. "xterm -fn fixed -geometry 80x24" creates a window, which, according
to xwininfo has a size of "484x316" pixels (i.e. a 6x13 pixel font with
a one-pixel border all around).
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf