Subject: [xml2rfc] Line Wrapping Algorithm

From: "Jim Schaad" <[email-masked]>
Date: Sun, 10 Nov 2013 22:17:53 -0800

I have found an issue that I would like to get some input from you on how to
go about solving it.

The current wrapping algorithm is imported from lib/textwrap.py and thus is
a standard algorithm.  However the algorithm does not support a feature that
we need to correctly do line wrapping for the nroff case.  Specifically it
does not allow us to define a specialized string length function.  For the
nroff case the string " \\abc <file:///\\abc> " is a four character long
string and not a 5 character long string.

I see two different ways to address this:

1.       Copy the lib/textwrap.py file into our code and add the specialized
length function as a parameter

2.       String the funny quoting characters from the string before doing
the wrapping, and then try and figure out where to put them back in on the
wrapped output.

The first means that if there are future updates in the code, we would not
see them.  However it also makes it easier to get the correct changes and in
a way that is simple.  The second method means that we keep the current
wrapping code and get the updates, however it is a bit harder to get the
correct strings back and is potentially more open to error.

Do you have other suggestions or do you have preferences on the method to
use?

Jim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Nov 2013 10:16:18 +0100

On 2013-11-11 07:17, Jim Schaad wrote:
> I have found an issue that I would like to get some input from you on
> how to go about solving it.
>
> The current wrapping algorithm is imported from lib/textwrap.py and thus
> is a standard algorithm.  However the algorithm does not support a
> feature that we need to correctly do line wrapping for the nroff case.
>   Specifically it does not allow us to define a specialized string
> length function.  For the nroff case the string “ \\abc” is a four
> character long string and not a 5 character long string.
>
> 1.Copy the lib/textwrap.py file into our code and add the specialized
> 2.String the funny quoting characters from the string before doing the
> wrapping, and then try and figure out where to put them back in on the
> wrapped output.
>
> The first means that if there are future updates in the code, we would
> not see them.  However it also makes it easier to get the correct
> changes and in a way that is simple.  The second method means that we
> keep the current wrapping code and get the updates, however it is a bit
> harder to get the correct strings back and is potentially more open to
> error.
>
> Do you have other suggestions or do you have preferences on the method
> to use?
>
> Jim

No specific opinion, but a reminder: we are working on getting rid of 
the nroff step in RFC production. Is it worth spending time on this anymore?

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 11 Nov 2013 12:39:28 +0100

Hi Jim,

> correct strings back and is potentially more open to error.

I think this can be made accurately.  The idea: remember the location(s) where
an additional '\' will have to be re-inserted, then walk through the initial
and wrapped text and note every place a newline + whitespace has been inserted.
(this is easy, since the textwrap interface we use returns a list of lines,
rather than a wrapped paragraph).  That will let you correctly calculate the
new location(s) where '\' will have to be re-inserted.

> Do you have other suggestions or do you have preferences on the method to

The latter, with the indicated approach.

(I think Julian's comment regarding deprecation of nroff is valid, but the
decision to stop supporting nroff isn't a technical one we can make, it's up
to the RFC-Editor staff to signal when they feel we can dispense with it.
Since they are filing bugs against the nroff writer, I think we should fix
them.)

Best regards,

	Henrik

---

From: Tony Hansen <[email-masked]>
Date: Mon, 11 Nov 2013 09:27:21 -0500

> The latter, with the indicated approach.

I don't know if this would help, but instead of adding additional '\'s,
consider modifying each '\' into '\e'. '\e' is always the current *roff
"escape" character, that is, the backslash. Thus "\e\eabc" would be
printed as 5 characters. I'm not sure how the python code will handle
escape characters that *it* doesn't recognize, but if it treats it
properly, you're set.

If not, another option is to convert to a different escape sequence that
*is* recognized by python, say \a (audible bell), do the text wrapping,
and then convert the \a to \e after wrapping.

> Since they are filing bugs against the nroff writer, I think we should fix

Agreed, they should be fixed. The RFC production center folk *really*
want to get off of using V1; they do not feel that they can move off of
V1 until they can reliably use V2. Yes, it's an interim step, but IMHO
needed.

    Tony

---

From: Alice Russo <[email-masked]>
Date: Mon, 11 Nov 2013 12:31:22 -0800

> V1 until they can reliably use V2. Yes, it's an interim step, but IMHO

Per the RSE, the RFC Production Center will 

- use v2 to convert any documents for which an XML file was submitted (and stop using v1 as soon as possible)
- keep archiving nroff as the source file for all RFCs until the transition to the "v3 format" at some point in the future

so that's why the RPC has filed bugs against v2 nroff output.

Thanks,

Alice 
for the RFC Production Center