Re: Unicode console font

[Andries.Brouwer@cwi.nl]

    From ydirson@multimania.com Thu Sep 16 00:33:22 1999

    This also explains why I can't get screendumps as simple user, as
    login does not seem to chown the vcs* devices together with the tty*
    on my machine...  This sounds like a bug.

The login from util-linux does, so I expect that things
are fine on RedHat. Maybe not on Debian or SuSE?



     > fprintf (f, "\030\032" "\r\357\200\240" "\033[6n\033D");
     > It is terrible, dirty, wrong.

    "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.

    "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.

     > And my old code did not need this stuff. What was wrong with it?
     > I see - I did ESC ( K - also ugly, but not as bad as the above.

    Well, maybe more pleasing to the eye, but it changes the state of the
    current VT and does not (cannot) restore it.  This is IMHO a bug.

Yes.

     >>     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.)


     > I know of two types of .cp files. One type is bare fontdata
     > (with three fonts inside). One type is the DOS type, with a header
     > with precise format differing between MSDOS/DRDOS/PCDOS.
     > Is there a magic number there? I thought there wasn't.
     > What is your magic test?

    In the doc/fonts/fonts.magic file in console-data, I have:

<ugly info deleted>

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


     > I have a small program cattib.c that reads a Tibetan font in
     > extended psf, loads it and then prints my tibetan texts on the
     > console. It is suitable as an output filter.
     > This is only a plaything, on the one hand because I needed it,
     > on the other hand to collect some experience. The code is
     > fairly simple - it is not inconceivable that it could be put
     > into the kernel.

    Well, hpa would probably answer that such a functionality would better
    be found in a user-mode driver, I guess.

Yes, maybe. Anyway, this was to explain the use of the
extended psf format - regardless of whether it is used
by kernel or user-mode driver.

Andries
-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/