Bug#700500: a CyrEo fontset, please?
>>>>> Anton Zinoviev <anton@lml.bas.bg> writes:
>>>>> On Thu, Aug 07, 2014 at 06:57:49PM +0000, Ivan Shmakov wrote:
>>> This doesn't happen when framebuffer is used.
>> Does that mean /dev/fb*, or rather the “kernel mode setting” (KMS)
>> facility?
>> The last time I’ve checked, – it wasn’t the case for KMS-enabled
>> text VTs. I wasn’t following this closely, though.
> All depends on the hardware mode of the videocard. If the videocard
> is in graphic mode (i. e. the text mode is emulated by the kernel),
> then there is no color limitation.
There’s no /hardware-imposed/ limitation. It’s still possible
that the kernel emulates this aspect of the traditional text
VTs, – which is, IIRC, what I experienced. Again, this may have
since changed.
> On the other hand, if the videocard is in real text mode and the font
> is loaded in the videocard itself, then inevitably there is a color
> limitation.
Yes.
[…]
>> That doesn’t seem like “supported” to me, as:
>> • /usr is generally reserved for dpkg-maintained files; the “custom”
>> ones belong to /usr/local instead;
> It is not difficult to add a support for /usr/local. But since
> console-setup already searches for files in /etc/console-setup/ and
> supports absolute file names, I suppose this isn't really necessary.
I’d generally avoid storing such files under /etc, either, but
given that a symlink may be used instead, – it seems like a
reasonable place. Thanks for the clarification.
>> • by “custom fontsets support” I mean, specifically, that the user
>> is provided a tool which locates user’s own fontsets (either in
>> /etc/console-setup or somewhere under /usr/local, or perhaps passed
>> via the command line) and generates the respective font files; alas,
>> I don’t seem to see any such tool provided by either console-setup,
>> console-setup-linux, or kbd packages.
> We shouldn't expect from the users to generate fonts. This is an
> experienced task that should be done developers.
Why?
> It will be much more convenient if the users use fonts prepared by
> more experienced people.
FWIW, I find none of the fonts provided really convenient.
Which is why I filed this bug report in the first place.
> Now, let as think from the position of the font developer. Do we
> require from him to prepare the fonts exactly according to the
> requirements of console-setup (codeset, fontface, fontsize)? Well, I
> think this is too much work and the benefits – only moderate
> considering that console-setup is able to use any non-standard
> console fonts. In fact, Debian already includes a few packages with
> non-standard console fonts (console-braille, psf-unifont, fonty-rg).
> None of these packages follows the standards of console-setup and
> there is no need for this – it is much more convenient to use a
> simple instruction FONT=... than to think in terms of codeset,
> fontface and fontsize.
To clarify, – the idea is not to force the console-setup
requirements onto a font designer, but to provide an easy way
for the user to tailor any font with more than 256 glyphs to his
or her own requirements.
Basically, instead of shipping .psf files, my suggestion is to
provide the source .bdf(s), along with the means to create – as
part of the package configuration – a .psf for any given “font
set” – either defined by Debian, or by the user him- or herself.
The resulting .psf files will then belong to /var/cache, and are
to be generated at the package configuration time.
This is not going to be much different to, say, how the
‘locales’ package currently behaves – as compared to
‘locales-all’.
One constraint worth of imposing on the user-defined font sets
is that all the 95 printable ASCII characters (U+0020 through
U+007E) are represented, – which leaves up to 161 font code
points for the user to define. Similarly to how the font sets
are currently dealt with at the package build time, the “unused”
code points are to be assigned to miscellaneous punctuation,
such as U+00AB, U+00BB («, »), U+00B7 (·), U+2020 (†), etc.
Other than that, the logic remains virtually the same.
It’s just that .psf generation is to happen when the package is
configured, – instead (or in addition to) when it’s built.
--
FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A
Reply to: