Werner LEMBERG wrote in <20180802.162932.2121529583718521640...@gnu.org>: |> There appears to be specific code in groff to explicitly *BREAK* the |> return value of wcwidth(3). Actually, egregious mishandling of |> wcwidth(3) is a quite common error in application programs, so groff |> is certainly not alone here. | |Well... :-) | |> I'm not familiar with groff internals either (except for the manual |> page macroset implementations), but i had a quick look and instantly |> identified at least three places where wcwidth(3) handling is |> obviously broken, see the patch below. That patch is *NOT* intended |> for commit, but merely for giving others some hints in which areas |> to look. | |Thanks. Unfortunately, I don't have time to delve into the code, |sorry.
Well if i recall the situation then that GNU library which is now linked into the build provides a function that actually offers wcwidth() specifically for UTF-8, which is what groff would need. Even if setlocale() has never been called that is, or called with "C". I have reported this in 2014 i think, unfortunately i still have no running fork. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)