Re: Unicode console font

[Yann Dirson <ydirson@multimania.com>]

Andries.Brouwer@cwi.nl writes:
 > The login from util-linux does, so I expect that things
 > are fine on RedHat. Maybe not on Debian or SuSE?

Just sent a bug report for Debian.


 >     "terrible, dirty": yes, but nobody ever added an API for this trivial
 >     service into the kernel, although this functionality is included in at
 >     least 2 easily located unofficial kernel patches (one with ioctl
 >     interface, the other with ESC sequences).
 > 
 > I hope to be able to add it.

Great.  Let's hope it will make its way before 2.4 !  I think hpa is
the one reviewing console stuff before inclusion ?

Note: an ioctl will only solve the console case, and will not cover
the wide range of other tty's, for which a better solution may be ESC
sequences defined in terminfo db.


 >     "wrong": I can't tell what can go wrong.  Can you elaborate on this ?
 > 
 > No doubt there are all kinds of obscure circumstances
 > that can make this fail. Let me construct an example.
 > Suppose I use mapscrn and load a screen map.
 > The bytes \357\200\240 are fed to translate[] and produce
 > unicode values that are looked up by conv_uni_to_pc().
 > I can make sure that some of these return -1 or -2.
 > Then the current position will not be updated and
 > the routine will incorrectly conclude UTF8.

Well, cursor has to be in column 2 for "utf8" to be reported.  -1 is
reported for any column other than 2 and 4.

Ah ah, you mean when one of those chars map to a control char or a
zero-width space, do you ?  Yes, this seems to be a problem, although
I don't think zero-width spaces are much used in 8bit charsets.  A
more secure way can be, when in column 2, to lookup the char in column
1 and check against what we're looking for, although then it may fail
again because of a particular charset...

Maybe knowledge of the user-defined charset will help choose a
relevant UTF sequence to send, but that really begins to sound
complicated...


 >      >>     o Fixed unimap-misc.c::kernel_get_unimap() to handle the case where
 >      >>       the unimap is considered invalid by the kernel.
 >      > 
 >      > I don't know what was wrong.
 >      > And it seems console-tools does not have a kernel_get_unimap()
 >      > or unimap-misc.c.
 > 
 >     I did a naming-coherence pass some time ago.  See
 >     lib/console/kernel-sfm.c
 > 
 > Hm. Doesn't exist in console-tools-0.2.2 which I downloaded
 > yesterday or so. (Not from your site since it gave me
 > 30 bytes/sec, but from metalab, I think.)

Yes, metalab only hosts the last stable release, whereas dev releases
are only on this damn slow site.  I have to address this quite
rapidly.  lib/console/kernel-sfm.c is in 0.3.2, but has an equivalent
in 0.2.2 (lib/sfm-misc.c).


 > Yes, that is true for what we have in the data directories today,
 > more or less by coincidence. Not good solid magic.
 > But we might as well turn all of the .cp fonts into .psf

Yes, but that will somwhat loose the "grouping" info.  I was waiting
to have implemented XPSF before throwing those original CP files, but
XPSF is still some kind of vaporware...  Note that the draft specs for
XPSF in 0.2.2 are not up-to-date - those in 0.3.2 are.


Regards,
-- 
Yann Dirson                         |    Why make M$-Bill richer & richer ?
           <ydirson@multimania.com> |   Support Debian GNU/Linux:
debian-email:   <dirson@debian.org> | Cheaper, more Powerful, more Stable !
http://www.multimania.com/ydirson/  | Check <http://www.debian.org/>
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/