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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf