Hi Mike, Mike Bianchi wrote on Sat, Feb 02, 2019 at 09:53:43AM -0500:
> ... build a generalize tool where the choice of font or device implies > a set of desirable (to me) character substitutions and renderings that > can easily be changed via a personalized configuration file. Say > .grofftool-txt.rc > where txt is a font name or dev (or both?). Absolutely not, i very strongly oppose that idea. Groff already has far too many competing mechanisms to translate input character codes to output glyphs - i'll refrain from enumerating them here. Also it has sufficient mechanisms for personal customization. The way to deal with decade-old design mistakes like the ambiguity of the ASCII 0x60 code point and that have been resolved long ago (in this case, by Unicode) is definitely not to introduce yet another mechanism for user customization. Customization is often a premature answer and hence the root of many evils. Besides, customization cannot contribute to solving any part of the problem at stake, which is that the traditional rendering of \(oq to ASCII looks odd according to modern usage of ASCII (which is why the groff error messages and parts of the documentation were changed lately). This is about how stuff looks *by default*, not about user customization. You are already welcome to do in your .troffrc whatever you want. [...] > troff. In the 1970s (my youth) there were so-called "daisy wheel" > printers/typewriters/terminals where the font was implemented via > an easily substitutable part. Sure, the first computer-attached printer i used was a daisy-wheel printer. Even though it was a quality HP product, the individual glyphs broke off often, and once the first petal of the daisy fell of, the whole wheel had to be replaced. Sometimes, we avoided using the broken character to make it last a bit longer. [...] > Programmers had their favorites; document writers theirs. That is no reason to treat the meaning of ASCII characters as a matter of personal preference in 2019. Yours, Ingo
