Please provide 256-glyph fonts with both Cyrillic and Esperanto
	glyphs (specifically: U+0108, U+0109, U+011C, U+011D, U+0124,
	U+0125, U+0134, U+0135, U+015C, U+015D, U+016C, U+016D.)

	One possible such fontset is MIME'd.  It is based on
	CyrSlav.256, and retains all its glyphs within the U+04xx range,
	adds the aforementioned Esperanto glyphs, U+00F7 DIVISION SIGN,
	while removing certain U+20xx (U+2013, U+2020, U+2021, U+2030,
	U+2039, U+203A) glyphs, and U+2122 TRADE MARK SIGN, arguably not
	all that valuable for Cyrillic-based typography.

	Dankon.

tags 700500 + wontfix
thank you

Hi and thank you for your contribution!

I am tagging this bug report as 'wontfix' for the following reasons:

1. The combination Cyrillic + Esperanto is supported by Uni2 and Uni3
   fontsets.

2. Small fontsets (256 glyphs) are for one language only.  Users who
   need multilingual support should use Uni1, Uni2 or Uni3.

Anton Zinoviev

[…]

 >> Please provide 256-glyph fonts with both Cyrillic and Esperanto
 >> glyphs (specifically: U+0108, U+0109, U+011C, U+011D, U+0124,
 >> U+0125, U+0134, U+0135, U+015C, U+015D, U+016C, U+016D.)

 >> One possible such fontset is MIMEd.  It is based on CyrSlav.256, and
 >> retains all its glyphs within the U+04xx range, adds the
 >> aforementioned Esperanto glyphs, U+00F7 DIVISION SIGN, while
 >> removing certain U+20xx (U+2013, U+2020, U+2021, U+2030, U+2039,
 >> U+203A) glyphs, and U+2122 TRADE MARK SIGN, arguably not all that
 >> valuable for Cyrillic-based typography.

 > Hi and thank you for your contribution!

 > I am tagging this bug report as 'wontfix' for the following reasons:

 > 1. The combination Cyrillic + Esperanto is supported by Uni2 and Uni3
 > fontsets.

	… However, these fontsets come at the price of the reduced color
	capability for the text terminals.

 > 2. Small fontsets (256 glyphs) are for one language only.

	That’s hardly the case; for instance, how do you explain that
	the CyrSlav fontset includes ñ?  Is it used in any languages
	that rely on the Cyrillic script?

 > Users who need multilingual support should use Uni1, Uni2 or Uni3.

	FWIW, I’d gladly accept a facility allowing the user to use
	custom fontsets for a fix to this issue.

This doesn't happen when framebuffer is used.  With modern kernels
framebuffer is more or less a requirement.

No, the letter ñ is not included in the CyrSlav fontset.  The symbols
from the file useful.set are included in the generated fonts by the
bdf2psf utility only when there are free positions.  The letter ñ is
listed number 109 in this file.

Yes, custom fontsets are supported.  One only has to put the
corresponding font in /usr/share/consolefonts and use an instruction
like FONT=CyrEo-Terminus16.psf.gz in /etc/default/console-setup.

Anton Zinoviev

 >> … However, these fontsets come at the price of the reduced color
 >> capability for the text terminals.

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

 > With modern kernels framebuffer is more or less a requirement.

	With xserver-xorg-video-vesa, – it surely isn’t.

	Unfortunately, “native” X video drivers are simply not supported
	for my hardware on Debian.  (Unless, of course, one considers
	firmware-linux-nonfree to be part of Debian, which it’s /not./)

 >>> 2. Small fontsets (256 glyphs) are for one language only.

 >> That’s hardly the case; for instance, how do you explain that the
 >> CyrSlav fontset includes ñ?  Is it used in any languages that rely
 >> on the Cyrillic script?

 > No, the letter ñ is not included in the CyrSlav fontset.  The symbols
 > from the file useful.set are included in the generated fonts by the
 > bdf2psf utility only when there are free positions.  The letter ñ is
 > listed number 109 in this file.

	I stand corrected.

 >>> Users who need multilingual support should use Uni1, Uni2 or Uni3.

 >> FWIW, I’d gladly accept a facility allowing the user to use custom
 >> fontsets for a fix to this issue.

 > Yes, custom fontsets are supported.  One only has to put the
 > corresponding font in /usr/share/consolefonts and use an instruction
 > like FONT=CyrEo-Terminus16.psf.gz in /etc/default/console-setup.

	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;

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

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

OK.

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.

We shouldn't expect from the users to generate fonts.  This is an
experienced task that should be done developers.  It will be much more
convenient if the users use fonts prepared by more experienced people.

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.

Anton Zinoviev

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