Re: [Rfc-markdown] [Tools-discuss] Tool to convert TXT to RFCXML

[Carsten Bormann <[e-mail]>]

On 17. Jul 2023, at 07:13, Julian Reschke <[e-mail]> wrote:
> 
> I agree that this is a problem. But that's also what the RFC Editor has
> been doing in the past (AFAIR).

The RFC editor can only express what RFCXML provides.
Since there is no <nobr in RFCXML, only character substitutions remain.
As Martin notes, there can be undesirable effects:

* xml2rfc can process these non-break character and replace them with basic characters when generating final form for plaintext rendering.
* Theoretically, it could to that for PDF, too, but that requires the use of tools that enable this.
* For HTML, it is the HTML renderer (browser) that has to react on the no-break characters, so xml2rfc has to leave them in.

Fortunately, there is some support for searching in the presence of no-break characters in browsers, so the HTML exception is not as bad.

We should

* find out more about browser support for searching in the presence of no-break characters
* make sure that our PDF support also generates text that allows useful copy/paste
* add <nobr or similar to RFCXML, so we don’t have to play the character substitution games.

I know that <nobr in HTML was a browser vendor invention that did not make it into HTML5, but that is because HTML5 enables representing the same information in style properties, which they instead did.  This doesn’t apply to RFCXML.  (Any argument that this *is* a style property and therefore should not be part of the RFCXML gamut is confused.)

(I re-added rfc-interest to rfc-markdown as, while markdown can help automatically doing the character substitution games, that is just a stopgap until RFCXML catches up — at which point we can just change the markdown processors to emit <nobr without a need to change the actual markdown.)

Grüße, Carsten