> Von: "Ingo Schwarze" <[email protected]> > > Bernd Warken wrote on Sat, Aug 02, 2014 at 03:25:24PM +0000: > > > +This mode has the most useful fonts for TTY mode, so it is the best > > +mode for TTY output. > > Hum, that doesn't make much sense to me. > > ISO-latin vs. UTF-8 is *not* at all a question of which one is > absolutely better.
For reading groff_char.7 UTF-8 must be used, otherwise all non-Latin characters will be ignored. > If your terminal or output device only supports ISO-latin or is > configured for ISO-latin or some other narrow character or non-UTF > locale, shoving UTF-8 down its throat will not make you happy but > result in gibberish. Actually, there is too much software already > wrongly assuming that "everything can handle UTF-8". Everything without UTF-8 is old-fashioned. But because of compatibiity the old stuff must be supported as well. I do that with groffer, all groff possibilities are used. But it seems to be quite strange when the most useful stuff (like UTF-8) is not made into default. > To handle UTF-8 output, your terminal needs to be specifically > configured for UTF-8. That may not be possible for all terminals > and in all situations, and certainly many users don't do it. And? All modern PCs support Unicode. For example, `man groff_char' displays all characters in this man-page, so it automatically uses UTF-8 as well. > Regarding defaults, switching groff from ISO-latin by default to > UTF-8 by default is certainly something that shouldn't be attempted > in a casual commit without a discussion. I'm not sure you are > driving into that direction, but your recent groffer commit might > indicate that you might be - or it might not, i'm not sure. That default switch occurs only in the documentation. It replaces archaism from above by intelligence and reason. > If a specific output mode is requested from a program (for example > with options like -Tascii or -Tutf8), that mode must be used. > If no specific mode is requested and the program has to decide > which mode to use as a fallback, inspecting the user's locale(1) > environment variables, in particular LC_CTYPE, is a good way to > proceed, while blindly falling back to UTF-8 is a bad idea. > Actually, strictly speaking, if LC_CTYPE, LC_ALL, and LANG are > unset, software ought to fall back to the C/POSIX locale, which > is even less than ISO-latin. In practice, falling back to ISO-latin > is often convenient (for people in western european countries and in > the english-speaking parts of the world), so some software has been > doing that in the past. Strictly speaking, it's not quite the > right thing to do, but it's widespread enough to rarely cause > outrage... No one is hurt by using modern stuff as default. Most people do not know how to use the `groff' command line, so they cannot use the `-T' option. So something reasonable must be done automatically, such as with `groffer'. I did not change anything within the `groff' program. ##### next email >> Would it make sense, to add `groff -n' for running `nroff' in text mode >> instead of strange `groff' commands - also maybe change `grog'. > Parse error... You are right, such a new option would not be reasonable. > It looks like you are dabbling in an area unfamiliar to you (locale > handling is not among my strong points either, but i know enough > about it to recognize you seem somewhat lost here). Before trying > to improve what groff and groff support programs do with respect > to locales and charsets, i guess you ought to read up on some > basics with respect to these subjects. You are correct, This local stuff is quite new for me, I'm a bit guessing. Nothing like guessing is left after 25 April 2014 - at that time, everything from `above' (strange voices in the head) was terminated. So some intelligence without dull voices would be very welcomed. Bernd Warken (http://7dim.org)
