Hi John, John Gardner wrote on Tue, Dec 18, 2018 at 11:06:56AM +1100:
> I don't really see what the problem is. Documentation offers readers one > language at a time. Sure, multilingual authors might split each page into, > say, English or French. But unless it's crippling lack of Unicode/UTF-8 > support which stops Groff from embracing the UCS > <https://en.wikipedia.org/wiki/Universal_Coded_Character_Set> in both its > syntax and output, So far, groff is doing surprisingly little wide character and multibyte character processing indeed. Unless i botched grepping the source tree - which is hindered by the noise from gnulib - basically the only wide character interface used right now appears to be wcwidth(3). All the same, UTF-8 output works quite well. So no, there is no crippling lack of UTF-8 support. > then I fail to see why we're even considering > locale-specific anything.... The return values of the towupper(3) function are mildly locale-dependent, even if only for a handful of characters like the Turkish i. Using that function would prevent groff from having to deal with any locale(1) dependencies. Tadziu explained why one might hesitate using towupper(3), while i think its complexity is comparable to wcwidth(3), or at least not much worse. *If* we want to avoid use of that function, then we have to do some language-specific macro development. I think using towupper(3) is actually simpler, but there are no doubt arguments both ways. Yours, Ingo
