Hi Branden, G. Branden Robinson wrote on Fri, May 27, 2022 at 05:50:51PM -0500:
> I want to prevail upon man page authors to choose correct glyphs in > their documents--so we can get a consistent experience on all output > devices. Ouch. Those special rules for manual pages allowing to write plain ASCII "-" on the input side to get plain ASCII "-" on the output side were *device specific* (same for the other four characters), which means that this text i wrote four years ago in mandoc_char(7) was never accurate - right? In roff(7) documents, the minus sign is normally written as `\-'. In manual pages, some style guides recommend to also use `\-' if an ASCII 0x2d "hyphen-minus" output glyph that can be copied and pasted is desired in output modes supporting it, for example in -T utf8 and -T html. But currently, no practically relevant manual page formatter requires that subtlety, so in manual pages, it is sufficient to write plain `-' to represent hyphen, minus, and hyphen-minus. When considering PDF and HTML output, that was anpparently never true (except with mandoc(1)), plain "-" on the input side always gave you a hyphen in PDF output even in manual pages, right? Now *making* that device independent would not be an improvement because then manual page authors would have to write The --foo option can\(cqt be used together with a non\(hyzero bar argument. which is clearly not easier than having to write The \-\-foo option can't be used together with a non-zero bar argument. Consequently, using these five glyphs unescaped on the input side in order to get the five ASCII output characters was always wrong even in manual pages (not sure how i managed to fail to realize that until now, or more likely forget it again). I think the argument "this was always wrong and only worked on some output devices at best" is stronger than my argument "but manual page authors have become used to it and some style guides including my own actively recommended it". So i think i have to retract my objection. Yes, it causes a lot of work including in OpenBSD, but when something is actually broken, calling that a "make-work project" is not really fair. Note that i can only retract my part of the argument; John might still have points that are not invalidated by this mistake i made. Yours, Ingo
