Re: Unicode console font

[Andries.Brouwer@cwi.nl]

    From: Yann Dirson <ydirson@multimania.com>

    Andries.Brouwer@cwi.nl writes:
     > > I found some info on http://www.multimania.com/ydirson/en/lct/
     > 
     > Ah, interesting - thanks for the pointer!
     > I just looked for a moment and didnt find any specs for xpsf,
     > only the statement that it was being designed and that the
     > specs now are in docbook.
     > Do you have a more precise URL?

    I did not put it online yet, it's in a quite unconsistent state now,
    but you can have a look at it in the doc/file-formats/ dir in the
    console-tools (development) source tree.

OK - will look. I only made a small extension to the psf format:
Working with Tibetan last week or so, I constructed a font with
precomposed characters and noted that the symbols in the font
do not have a Unicode value; they are described by Unicode sequences.
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
(this week, maybe tomorrow).

Another thing: until now the program kbdrate has been part of
util-linux. But clearly it belongs in the kbd package.
So, kbd-1.0 will also contain kbdrate, while util-linux-3.0
will not contain kbdrate any more.


    the events which occurred during the last 2 years
    do not seem to tend towards a unified package...

Hmm. You said something else in your last letter.
And I wouldnt know why not. But never mind.


Thanks for the list of potential kbd bugs!
I just compared with current sources.
Below some comments and questions.


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

Hmm. Let me see..
mapscrn loads a screen map - no magic is defined
loadkeys loads a keymap - no magic is defined
setfont loads a font - it tests the psf magic to see whether it is psf
Maybe I forget something. Where would you test for magic?


    o Converted all distributed raw fonts to PSF, with SFM when I was sure
      enough I should be right.

Yes, I did the same - with Unicode map everywhere, if I recall correctly,
will check tonight or tomorrow night. (I just learned this week that
my Unicode map is your SFM. Somewhat confusing: people tell me that
it stands for Screen Font Map, which sounds more like screenmap, the
user-defined mapping table.)

    o Fixed vcstime so that it handles screens more than 127-chars wide.
Was fixed in kbd-0.95.

    o Told showkey that K_UNICODE exists (was "??UNKNOWN??").
Was fixed in kbd-0.96.

    o Fixed unimap-misc.c::kernel_get_unimap() to handle the case where the
      unimap is considered invalid by the kernel.
Sounds like a console_tools bug only.
There is no such file, and no such routine in kbd.

    o Reworked option-handling in showkey (distinguished between commands and
          options).
Sounds like a console_tools bug only.
There are no non-option arguments to showkey in kbd.

    o Fixed `showfont' to restore original UTF/byte mode on exit.
Sounds like a console_tools bug only.
Showfont never touches UTF/byte mode.

    o Fixed bug in lib/miscutils::open_a_console(), for when it'll be exported by
          the lib (fd wasn't closed).
Sounds like a console_tools bug only. Kbd uses
	fd = open_a_console("/dev/console");
and open_a_console() should certainly not close fd.

    o Fixed dumpkeys.c::usage() to display really-available charsets for
      "--charset" option.
Good. Fixed here as well.

    o Fixed deallocvt to deallocate all possible VTs, instead of exiting as soon
      as one deallocation failed.
Hmm. Sounds reasonable. Fixed here as well.

    o Fixed validity check on "--charset" option in ksyms.c::set_charset(),
      though still don't know what "unicode" is for here.
Hmm. What was wrong? Current code looks OK to me.

    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.
Sounds harmless. Just like doing "foo >file" which will give
an empty file if something is wrong with foo.

    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.

    o Made screendump without arguments look at /dev/vcs[a] instead of 
          /dev/vcs[a]0, which are not created by MAKEDEV.
----------------------------------------------------------------
Hmm. Depends on your version of MAKEDEV.
I created /dev/vcs*, wrote the kernel source, wrote the man page.
The man page says:
       /dev/vcs0  is  a  character device with major number 7 and
       minor number 0, usually of mode 0644 and  owner  root.tty.
       It refers to the memory of the currently displayed virtual
       console terminal.
The kernel source says:
       /dev/vcs0: the screen as it is being viewed right now
There is documentation all over the place, also embedded in
program texts, that mentions /dev/vcs0.
I know that hpa entered /dev/vcs0 into devices.txt as /dev/vcs -
don't know why he deviated from source, docs and usage.
Apart from this single occurrence of /dev/vcs I see no reason
to change. RedHat and SuSE have both /dev/vcs and /dev/vcs0.
----------------------------------------------------------------
As you can see, I regard replacing /dev/vcs0 by /dev/vcs a bad
idea (easier to change a single symbol in devices.txt).
But now that this confusion has been created, it may be
reasonable to try opening the other if the first doesnt exist.
Done.

    o Made "setfont" to load the default unimap when loading a default font.
Yes, that sounds reasonable. Added.


OK - so far for today.

Best wishes - Andries


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