Subject: [rfc-i] Layout-affecting Unicode

From: "Martin Thomson" <[email-masked]>
Date: Thu, 29 Apr 2021 09:53:53 +1000

It seems like xml2rfc has a very narrow set of Unicode characters outside of the ASCII space that it preserves[1].  The way it does this is not great [2], but it seems like these all exist to support forcing formatting constraints.

Is the use of these layout-affecting characters something we have discussed and have consensus around?  The HTML world recognizes these characters[3], but I've seen more deliberate efforts to move layout choices into document structure so that it can be controlled with style directives.

A problem I have observed that arises from these is that they create unsearchable text in that their presentation does not reveal the specific characters.  The BCP 14 boilerplate inserted by kramdown-rfc2629 for example inserts a non-breaking space between "BCP" and "14".  Searching for "BCP 14" consequently fails to return anything.  The other items also confound searching in similar ways, which is why I personally prefer structural elements for controlling layout.  This searching problem is likely part of why the RPC have insisted on having these be visible through entity references (which gets us back to [2] again).

The next obvious question is a tired one, but I feel that it needs to be asked: why privilege these characters over other Unicode in the structure/mechanisms of the system rather than simply limit their use through editorial policy?

[1] The complete set being: non-breaking whitespace, zero-width space, non-breaking hyphen, line separator, and word joiner.
[2] https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/548 is the result of my most recent trials with this problem.
[3] At least I believe so; I haven't tested all of them.
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest