[rfc-i] Fwd: New Version Notification for draft-flanagan-plaintext-01.txt

[rse at rfc-editor.org (Heather Flanagan (RFC Series Editor))]

On 7/3/14, 1:42 PM, Joe Touch wrote:
> 
> 
> On 7/3/2014 1:09 PM, Heather Flanagan (RFC Series Editor) wrote:
>> Hello all,
>>
>> I have posted a revised draft describing the requirements for plain
>> text.  As you'll see, some compromises were made.  I am particularly
>> interested in hearing from people that expect to continue to use the
>> plain text version after the format changes; of course, others are
>> welcome as well.
>>
>> Please note: new information, use cases, and arguments will be taken
>> into consideration.  Rehashing of old arguments is not helpful.
> 
> Sure. Some specific suggestions:
> 
>    o  The existing tools to create the text file are extremely
>       sensitive; manual manipulation is required in the final output.
>       In particular, handling page breaks for text is tricky.
> 
> This isn't true; I use the Word template and a subsequent Perl script
> pass, all of which is completely automatic and avoids widowing and
> breaking figures and tables without any manual intervention. It would be
> fair to say "Some existing tools...", but IMO that is a flaw of the
> tools used.

OK, I see your point.  I will consider how to rephrase that for the next
revision.  My understanding is that xml2rfc developers have had to spend
a great deal of time on widow and orphan handling, and one of the
reasons the RPC still uses nroff is to fill that need where xml2rfc
doesn't quite make it.

> 
>    Authors may continue to include figures drawn with ASCII characters.
>    If the canonical format includes figures or artwork other than ASCII-
>    art, then the plain text output must include a pointer to the HTML
>    version of the RFC to allow readers to see the relevant artwork.
> 
> I would suggest that the pointer be to the document DOI, and not to
> assume that the HTML version's artwork is preferred, e.g., to a PDF one.

My librarian background very much wants to point people to the info page
(which is where the DOI will point) for a document, so that a person can
choose the alternate format they prefer.  However, most of the engineers
I've spoken to hate that idea with the heat of a thousand suns, wanting
just one click to get to the information they need.  I don't have a good
answer for this one.

> 
>    ASCII art will have a character width limit of no more than 85
>    characters.
> 
> We've already raised this issue, but I still don't see sufficient
> justification for this line width in specific vs. the current of 72. The
> argument is presented later (next snippet), but I doubt the change from
> 72 to 80 (10%) will significantly impact screen width or page margin
> use. Given the impact on the existing toolchain, I would encourage use
> of the current limit instead.

My understanding is that this is not a big impact on the tool chain used
to produce RFCs.  You're talking about the toolchain used by individuals
within the community?

> 
>    Line lengths for both text and artwork, will increase to 80
>    characters in order to take advantage of wider screens and
>    unnecessarily wide page margins.
> 
> This requirement is in conflict with the earlier claim of 85 characters,
> and the issue of width increase benefit is raised above.

Rats, missed that.

-Heather