[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unicode console font
Andries.Brouwer@cwi.nl writes:
> 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.
Aha, nice feature... from which I infer there is no "current vcs" that
would be strictly equivalent to eg. /dev/vcs5, and that a program has
to find out the tty number and construct the /dev/vcs%d name. I guess
this can cause problems when running in an environment like
splitvt(1), where the running process' tty is not a console device,
but a pty... but maybe there's an ioctl for finding the console number
? Will have to RTFM ...
> Today it is almost certain that the ioctl will fail, so it is useless
> and only confusing to print error messages mentioning the ioctl.
ACK. I had not read the code too carefully before answering to this
one :(
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.
> 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?
"simple" here refered to showcfont.c, not to the implementation of
is_in_UTF8_mode().
> 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).
"wrong": I can't tell what can go wrong. Can you elaborate on 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.
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.
> > 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.
I did a naming-coherence pass some time ago. See
lib/console/kernel-sfm.c
> > 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?
In the doc/fonts/fonts.magic file in console-data, I have:
======
#
# CPI fonts
#
# MS-DOS
1 string FONT\ \ \ MS-DOS Code Page Information,
>23 uleshort x %u fonts
>41 uleshort x (CP %u,
>31 uleshort 1 screen
>31 uleshort 2 printer
# try to optimize display...
>37 byte 32 driver
>>33 string >\0 %.4s
>37 byte >32 driver
>>33 string >\0 %.8s
>49 ulelong 0 )
>49 ulelong >0 ; ...)
# DR-DOS
1 string DRFONT\ DR-DOS Code Page Information.
#
# CP fonts
#
6 string \001\000EGA\ \ \ \ \ CP font for Linux's setfont(1) (
>0 leshort 28
>>30 uleshort 3
>>>32 uleshort 9746 maybe not
>0 byte x unusable )
6 string \001\000VIDEO\ \ \ CP font for Linux's setfont(1) (
>0 leshort 28
>>30 uleshort 3
>>>32 uleshort 9746 maybe not
>0 byte x unusable )
======
in doc/file-formats (in console-tools, not -data), I described what I
could understand about those CPI and CP formats. You may be
interested in that, and you may want to comment on these. You'll note
how much I dislike CP, anyway :|
> > 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.)
Well, hpa would probably answer that such a functionality would better
be found in a user-mode driver, I guess.
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/