[rfc-i] draft-rfc-editor-rfc2223bis-08.txt

Bruce Lilly blilly at erols.com
Mon Jan 24 11:32:18 PST 2005

On Sun January 23 2005 17:18, Keith Moore wrote:

> >> The lines aren't going to break in the same places either because  of 
> >> proportional spacing, which means that text that's at the bottom of 
> >> page X in one document will be at the top of page X+1 in the next.
> >
> > Indeed, and the question that I'm raising is whether it's wise to 
> > force that to be the case by requiring the number of lines of text to 
> > be different in text and PostScript versions.
> That is going to be the case anyway, unless you are producing a 
> PostScript version solely to produce a PDF to make it easier for people 
> who use brain-damaged operating systems that can't print plain text 
> properly.   (those operating systems can't print PostScript either, but 
> these days almost everybody has a PDF viewer).

That isn't the sole reason to produce PostScript (another is for
improved rendition of diagrams), but given the sheer number of
such "people who use brain-damaged operating systems", it's a
valid consideration, and a very good reason to ensure that page
breaks occur consistently with the text version, so that a
reference to RFC 9999 page 17 (e.g. in errata or in comments
in response to a RFC) really does refer to page 37 in both
versions and not page 19 in one version.

I note that the PDF versions that the RFC Editor produces for
just such a purpose do have page breaks consistent with the
text version, and (necessarily) do NOT have the 1.0 inch top
margin that the RFC Editor's PostScript version requires (and
those documents are evidently produced from PostScript, by
the "enscript" program followed by Ghostscript to generate
PDF from PostSCript; at least that's what the information in
the PDF files suggests).

I'm simply suggesting that rather than have rules which the
RFC Editor intentionally violates in order to produce
consistent PDF documents, that the rules be revised to
conform to that practice.  Whether that means balanced
(for 8.5x11 paper) 2/3 inch top and bottom margins or
1.0 inch bottom and 1/3 inch top margins or some other way
of splitting the 1 1/3 inch difference between the 58 line
(@ 1/6 inch = 1 Pica = 12 points per line) text version and
11.0 inch paper height is a detail. [2/3 inch, however, is
very close to the 0.65 inch horizontal margins which would
allow 7.2 inch content on 8.5 inch wide paper]

Alternatively, line spacing in the PostScript version
could be reduced to 11 points, yielding 58 (and a fraction)
lines in 9.0 inches.  But that would screw up diagrams
(details below).

> >> And  one of the reasons you want to use PostScript is to include 
> >> figures you can't adequately represent in plain text, which is also 
> >> going to change
> >> page breaks.
> >
> > Not necessarily; if one uses pic (grap, dformat, etc.) for simple 
> > diagrams and chooses object dimensions carefully, diagrams can be the 
> > same size in text and PostScript versions.
> That's _way_ too much trouble for a very dubious benefit.

If I want a diagram showing connection between a client
and server, and I'm using troff (or nroff) for document
production, it's much LESS trouble to use pic:
box "Client" ; line right ; box "Server"
than to fiddle around with ASCII characters (which
won't render properly in a proportionally spaced
font anyway).  The default height for pic boxes is
1/2 inch, which is exactly 3 lines in nroff and,
well, 1/2 inch in troff.  It is therefore desirable to
have vertical spacing consistent (which the specified
12 point spacing achieves, but a change e.g. to 11
point spacing would destroy).

> >>> Line length also differs, which can be a problem for diagrams, etc.  
> >>>  8.5 inches page width with 1.0 inch left and right margins leaves a 
> >>> line length of only 6.5 inches.
> >>
> >> Which is probably longer than it should be for good readability.
> >
> > Feel free to argue for reducing the text version line length below 7.2 
> > inches, as it has been for ages.
> Readability has more to do with the number of characters per line than 
> the actual length of the line.  6.5in * 15cpi is almost 100 characters 
> versus 72 characters for the text version.

I would have no problem with a restriction on the
number of characters per line in the PostScript version,
so long as it permits at least 72 characters per line.

But to accommodate diagrams, which obviously could be
as wide as 7.2 inches in the text version, I would
prefer to see the left/right margin requirements
relaxed to permit uniform width for diagrams in both
versions (i.e. to permit 7.2 inch width in the
PostScript version), independent of any such restriction
on the number of characters per line.

> If you want to use 10pt  
> type on 8.5in x 11in paper, there's a good argument to be made for 2 
> column text.

RFCs are not formatted for 2 column text.  Again, feel
free to propose such a change if you think it's necessary,
but it would be a major departure from 3 decades of
practice.  It would also pose serious problems for
diagrams in text versions, unless you want to allow
switching back and forth between one- and two-column
text on a page (which introduces additional issues). It
would also be a problem for URLs, which are sometimes
too long to fit in a 72-character line.

More information about the rfc-interest mailing list