Follow-up Comment #8, bug #65108 (group groff): [comment #7 comment #7:] > One additional comment on the proposal: > > [comment #3 comment #3:] > > Only codes in the range 00-1F and 80-FF are accepted in > > [`\[u00XX]`] syntax; those in the range 20-7F are ignored with a > > diagnostic advising the user to deobfuscate their inputs. > > I realize there's no good reason for a user to type "\[u0045]" instead of "E"
There may in fact be one. It could be a means of obtaining an ordinary character (or the handful of special characters in Unicode Basic Latin) when said characters in their conventional forms are at that time subject to `tr` translation. I don't know if this is feasible, as I still haven't mastered the character-to-glyph resolution process. [https://www.gnu.org/software/groff/manual/groff.html.node/Using-Symbols.html#Using-Symbols It's one of the more complex aspects of the formatter.] > ... but at the same time there seems no reason for groff to object to it. It's ugly but not ambiguous or any harder to parse than the accepted ranges; if anything, a diagnostic seems to complicate the code, which could otherwise handle every \[u00XX] the same way. > > Even if you're wedded to the diagnostic, I'd say at least process the character. Ignoring it seems needlessly punitive. I have a very tall prescription pad. But I'll hold my fire for now. :) > (Taking ticket out of "Need Info" assuming comment #5 addressed your questions; let me know if I've overlooked anything.) That's fine. I think this is just waiting on me now to start implementing and decide: A. what to do about `\ ` in GNU _soelim_ and _troff_. B. whether to accept `\[u0021]` (or `\[u0020`?) through `\[u007E]` (or `\[u007F]`?) C. if the answer to "B" is "yes", whether to warn about them _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?65108> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
