groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] groff.1: enhance documentation for device utf8.


From: Bernd Warken
Subject: Re: [Groff] groff.1: enhance documentation for device utf8.
Date: Sun, 3 Aug 2014 14:06:21 +0200

> Von: "Ingo Schwarze" <address@hidden>
>
> 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)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]