On Sat, 23 Jul 2016, Thomas Dickey wrote:
> On Sat, Jul 16, 2016 at 04:14:37PM -0400, Thomas Dickey wrote:
> > On Sun, Jul 10, 2016 at 03:45:39PM +0200, Mikulas Patocka wrote:
> > > Package: ncurses-base
> > > Version: 6.0+20160319-2
> > > Severity: normal
> > > Tags: l10n
> > >
> > > Dear Maintainer,
> > >
> > > *** Reporter, please consider answering these questions, where
> > > appropriate ***
> > >
> > > * What led up to the situation?
> > >
> > > Updating the ncurses-base package from 6.0+20160319-2 to 6.0+20160625-1
> > > breaks
> > > the iso-8859-2 locale.
> > >
> > > The reason for this bug is that the package 6.0+20160625-1 sends the
> > > characters
> > > "\e(B\e)0" when initializing a full screen program. The code "\e(B"
> > > breaks the
> > > iso-8859-2 locale. (the locale needs "\e(K" so that it uses the alternate
> > > map,
> > > "\e(B" resets this setting to use the incorrect iso-8859-1 map)
> > >
> > > The version 6.0+20160319-2 doesn't send the characters "\e(B\e)0" at
> > > initialization, so iso-8859-2 works there.
> >
> > It's not that simple.
>
> ...
>
> > That is, a hard reset would have the same effect, pointing G0/G1 to
> > the Latin1 and VT100 graphics tables. The "reset" program does this.
Do you want to change the Linux Console, so that the reset sequence "\ec"
doesn't reset the mapping table? It would be possible, but ncurses still
need to work with older kernels.
> I'd like to get this point resolved.
We just need to remove "\e(B" from the linux terminal description, that
would be sufficient to make iso-8859-2 setups work.
Or - if you want to parse the $LANG variable in ncurses and send "\e(B"
only if we have the iso-8859-1 locale?
> > It's a bit of a mess, but basically the old/new control codes don't work
> > together. (more later)
>
> ...continuing, I wrote a script to (attempt to) exercise the various
> character sets by writing all of the printable characters with each of
> the selectable fonts, and changed my console-setup file to use ISO-8859-2
> (both attached).
>
> Currently I have via infocmp comparing linux2.2 to linux2.6:
>
> comparing booleans.
> comparing numbers.
> comparing strings.
> acsc:
> '+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260i\316j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376',
> '++\,\,--..00__``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}c~~'.
> enacs: NULL, '\E(B\E)0'.
> rmacs: '\E[10m', '^O'.
> sgr:
> '\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;%?%p9%t;11%;m',
>
> '\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;m%?%p9%t\016%e\017%;'.
> sgr0: '\E[0;10m', '\E[m\017'.
> smacs: '\E[11m', '^N'.
>
> and (perhaps someone can point out where I'm missing it), the only difference
> I see (screenshots attached) is an odd glitch on the screen which seems to be
> unrelated to what I'm trying to investigate.
Your script uses the enacs value only for the leading 4 characters:
printf "\n" if ( $adj != 0 );
printf "%s%s", $rmacs, $enacs; --- use enacs according
to termcap
printf "%s%d: ", $scs[$SCS], $SI;
printf '%s', $SI ? $smacs : $rmacs, $SI;
printf "\033(%s", $scs[$SCS]; --- set enacs according
to the loop variable
printf "\033)%s", $scs[$SCS];
The terminal value is reset with printf "\033(%s", $scs[$SCS]; --- so the
terminal only makes difference for the first 4 characters.
You can see on the screenshot that lines starting with K0 and K1 are
correct iso-8859-2 charset and the other lines are incorrect.
Mikulas
