Re: Unicode console font

[Andries.Brouwer@cwi.nl]

    From ydirson@multimania.com Wed Sep 15 00:58:54 1999
    From: Yann Dirson <ydirson@multimania.com>


About vcs:

    Anyway, I think having /dev/whatever0 meaning "current whatever", when
    all whatever's are already designated as /dev/whatever<n>, is not very
    far from brain-damage.  I'd say using just /dev/whatever is far less
    confusing (doesn't 0 mean "first of the array" in C convention ?)

Maybe you don't know, but /dev/vcs0 is not at all equivalent
with /dev/vcs5 when that shows the current console.
The difference is that when scroll back is used /dev/vcs0
shows what you are looking at, while /dev/vcs5 just shows
the screenbuffer for console 5.




     >     o Added message in screendump telling when trying ioctl; previously existing
     >           messages alone were too confusing IMHO.
     > Hmm. It is really long ago (1.1.91) that TIOCLINUX was willing to
     > dump a console. Instead of printing messages it is no doubt better
     > to delete this part entirely.

    Well, screendumps perfectly works for me (as root only, though) using
    2.2.12.  Did I misunderstand your statement ?

Yes. Anyone with read permission on /dev/vcsN can use screendump
to make a screenshot. However, before 1.1.92 there was an alternative
way of doing so, namely using function 0 of TIOCLINUX. Today that
would just return EINVAL, but when I wrote this screendump code
some people had /dev/vcs* and some had TIOCLINUX, so I made screendump
try the ioctl when the device file failed.
Today it is almost certain that the ioctl will fail, so it is useless
and only confusing to print error messages mentioning the ioctl.



     >     o Fixed validity check on "--charset" option in ksyms.c::set_charset(),
     > Hmm. What was wrong? Current code looks OK to me.
    The strcmp() test for "unicode" is reversed,
Ah, yes, you are right. Fixed.



     >     o Fixed bug in lib/miscutils::open_a_console()
     >           (fd wasn't closed).
OK - I see what you mean now. Fixed (although nothing was wrong).



     >     o setfont.c::saveoldfont() is now robust, and doesn't produce
     >       invalid files when all data isn't available.
     > Hmm. If getfont fails it may produce an empty file, I suppose.

    IIRC the problem was with failing to get the Unicode map/SFM after
    writing the font data, which can cause creating a PSF mode 1 or 3
    without the SFM - much worse that just empty file, but don't know if
    this is relevant to kbd.

Ah, I see. Not saveoldfont() but saveoldfontplusunicodemap().
Yes, that is relevant. Fixed.



    Also note that "showfont" causes a name conflict: Xfree86 also has
    such a command, hence the name change in console-tools.

Yes, I know - there is /usr/bin/showfont and /usr/X11R6/bin/showfont.
showcfont? I'll think about it.



    you may want to have a look at showcfont in consoletools,
    which uses a more simple method.

fprintf (f, "\030\032" "\r\357\200\240" "\033[6n\033D");
Simple, you said? It is terrible, dirty, wrong.
If there is no easy way to ask the kernel whether it is
in UTF8 mode, then we must add an ioctl, preferably a nice
generic one, so that we won't have to add one every week.
But not write terrible code like this.
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.



     >     o Fixed unimap-misc.c::kernel_get_unimap() to handle the case where
     >       the unimap is considered invalid by the kernel.

    This function is directly derived from getunimap.c

Hmm, possible. But I don't know what was wrong.
Moreover, it seems console-tools does not have a kernel_get_unimap()
or unimap-misc.c either anymore.



     >     AFAIK kbd still checks for file-types by extension only,
     >     and not by magic-number, which I consider to be a bug.
     > 
     > Where would you test for magic?

    Ah yes, PSF is tested.  But it seems CP files are only checked
    by data length, which is not a bullet-proof heuristic.

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?



     > So, I extended the psf format so that for a single glyph
     > there may be one or more Unicode sequences describing it.
     > You will see the result in kbd-1.0 to be released very soon

    Well, that may be a nice feature, but I think the current drivers
    cannot make use of them ?

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.

The current kernel idea is that basically all symbols have
a Unicode value, but that is not at all true, and a rewrite
of console.c needs something more general.
(Markus wants to do much more again, specifying how accents
should be combined with basic letters, but I am not yet ready
to put bitmap manipulation into the kernel. But loading a font
of which some characters consist of a basic symbol adorned
with some vowel symbols or diacritical marks and describing
the font positions with the Unicode decomposition sounds
like a reasonable thing to do.)



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