> Florian Weimer wrote:
> > There are a few other characters which simply can't be displayed
> > properly using single-width glyphs, for example:
> >
> > U+222D TRIPLE INTEGRAL
> > U+24A8 PARENTHESIZED LATIN SMALL LETTER M
> > U+FB03 LATIN SMALL LIGATURE FFI
> > U+FB04 LATIN SMALL LIGATURE FFL
> > U+2473 CIRCLED NUMBER TWENTY
> > U+2487 PARENTHESIZED NUMBER TWENTY
> > U+24DC CIRCLED LATIN SMALL LETTER M
Then don't use them in fixed-width plain text. It's that simple.
Markus Kuhn writes:
> I see actually no big problem to make all the circled and parenthesised
> numbers and letters doublewidth in the standard wcwidth, or even the EM
> DASH. It would just mean that the definition of wcwidth becomes an
> actual design issue, and not just like it is at the moment a function
> rather strictly derived from a Unicode database property.
Then it's won't be a standard wcwidth any more, it will be Markus'
private use wcwidth.
When we want to use vim's, readline's or emacs's display engine across
an rlogin or ssh connection, we have to rely on
1) the use of the same locale on both sides - the user is
responsible for this,
2) the same wcwidth definition on both sides - we are responsible
for this.
It will even be necessary to put the wcwidth definition in the kernel,
for the tty backspace/tab editing problem.
Therefore there needs to be a consensus about wcwidth across OSes and
applications.
Note that is actually the only purpose of wcwidth: use for tty based
applications.
Robert Brady writes:
> The return value of libc's wcwidth() is locale-dependant, and should be
> right for the terminal - as long as you honour this, noone has cause to
> complain.
wcwidth is locale dependent, and in the UTF-8 locale, we adhere to UAX
#11. It doesn't give you the freedom to define the width of "TRIPLE
INTEGRAL SIGN" arbitrarily.
Bruno
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
