Board.KolibriOS.org

What about using a program like this http://www.angelcode.com/products/bmfont/ to capture bitmaps from a font like this http://dejavu-fonts.org/wiki/Main_Page ?

Advantages of such a system is that it's easy to create the bitmap fonts from existing truetype fonts.

• There is at least 8bpp grayscale.
  Font is not monospaced.
  Easy to use PNG compression for the bitmaps themselves (and we have PNG decoder as KolibriOS library)
  Easy to use (binary) font description file which tells what glyph is located where and how large it is etc.

An example, captured from dejavusans.ttf (With all Latin and Cyrillic symbols)

Em... 8bpp is 8 times bigger than 1bpp, and can not be converted. Even this compressed tiny set of symbols takes hell a lot.

8bpp has the advantage that every pixel takes exactly one byte (easily addressable).
Compressed glyphs in png for all 5633 glyphs from dejavusans take 106kb (with 14 pixels high font)
The binary map file takes 120kb but compresses to 39kb with simple zip compression.
For comparison, the original TTF file takes 740kb.

Uncompressed glyphs in memory + their map will take about 512kb.

The suggested program can create 1bpp as well, by selecting 'use TTF outline', but the resulting font looks awful.

Do I understand correctly that one of the problems with this 8bpp is that it's harder/impossible to resize the glyphs?

BTW, once upon a time there was a project to add Unicode support to menuetos, but the implementation was horribly slow and never made it into the main project. See https://web.archive.org/web/20101129194 ... tu/mos/uc/ and http://mermaja.act.uji.es/docencia/is37 ... ernel_dev/ for the files.

Maybe something can be learned. (even if the thing to be learned is how not to do it...)

List of free pixel fonts http://www.alvit.de/blog/article/25-bes ... pixelfonts

EDIT: Most of these are very limited in number of glyphs; no Cyrillic and full Latin support.

I think, it's possible to resize 8bpp, but much more complicated. It will be the opposite to smoothing process, to dissociate gray to black and white in the right direction. Lets say, that is another story, to be told another time.

Nice bitmap font, with fully complete Unicode set: http://unifoundry.com/unifont.html

EDIT: After a lot of googling, I believe this is the best font to base our system on.
16 pixels height, 1bpp, not mono-spaced, crispy, all Unicodes available.. And it's GPL licensed.

By using another PNG compressor (PNGOUT plugin in irfanview for example), the bitmap can be compressed even better (about 75% of previous filesize.).
Also, the characters can now be placed in 16x16 tiles without sacrificing much of the total filesize. (Seems easier to work with.)

Looks like, there is not much difference. They even almost mono-spaced, what means just additional problems.
So, you need UTF-8. And UTF-16? Little-endian, big-endian?

UTF-8 is the most important for me. Later, one can add UTF-16.
Maybe it makes sense to use UTF-32 internally? (and thus also support UTF-32 from external sources).
x86 is little endian, so I believe it makes sense to follow this convention.

Итак, я много экспериментировал, но сейчас ЭЛТ монитор не позволяет мне оценить результат. Сравните 4 варианта масштабирования.

Извини, но все ужасны.
Возможно, лучше добавить несколько размеров ожного шрифта.

лучше kf шрифты добавить в систему, меньше заморочек, больше возможностей

В каком смысле ужасны?
Здесь речь идёт о юникоде. Вся суть в том, чтобы использовать один шрифт, иначе будет огромный размер.