OSDev.org

Hi, I am reading the article on the wiki about VGA fonts, and am a little confused as to how to set it up properly and use it. How do I get the bitmap of a specific character? And is there a way to use GRUB to do this?

Caffeine wrote:How do I get the bitmap of a specific character?

What format is your font stored in?

Caffeine wrote:And is there a way to use GRUB to do this?

You can tell GRUB to load any file as a kernel module alongside your kernel. One of those files can be your font, if you like. (Although for a simple boot-time bitmap font, you might embed it directly into your kernel.)

Octocontrabass wrote:

Caffeine wrote:How do I get the bitmap of a specific character?

What format is your font stored in?

Caffeine wrote:And is there a way to use GRUB to do this?

You can tell GRUB to load any file as a kernel module alongside your kernel. One of those files can be your font, if you like. (Although for a simple boot-time bitmap font, you might embed it directly into your kernel.)

I was planning on loading it in as an array as I do have a working filesystem yet.

Caffeine wrote:I was planning on loading it in as an array as I do have a working filesystem yet.

Firstly, I suspect that a "not" has gotten lost somewhere in that sentence. Secondly, that does not answer the question of what format the font data will be in. OK, you want to bake it into the kernel, that is certainly a way to go, and I would do the same in your position (and also not change it after the file system works, because the built-in font is something you always have available, while a font loaded from FS can fail, and then you kind of have no way to tell the user what just broke), but what will the data actually mean? If you have an ordinary 8x16 bitmap font, then each character is already an array of 16 bytes, but how you map those arrays to code points, how you organize all of that, is left entirely up to you. You can try key-value pairs, you can try hash tables, the world is your oyster.

nullplan wrote:

Caffeine wrote:I was planning on loading it in as an array as I do have a working filesystem yet.

Firstly, I suspect that a "not" has gotten lost somewhere in that sentence. Secondly, that does not answer the question of what format the font data will be in. OK, you want to bake it into the kernel, that is certainly a way to go, and I would do the same in your position (and also not change it after the file system works, because the built-in font is something you always have available, while a font loaded from FS can fail, and then you kind of have no way to tell the user what just broke), but what will the data actually mean? If you have an ordinary 8x16 bitmap font, then each character is already an array of 16 bytes, but how you map those arrays to code points, how you organize all of that, is left entirely up to you. You can try key-value pairs, you can try hash tables, the world is your oyster.

Yes I meant not, my bad. Awesome! Any way you recommend? And any external recourses on how to do that?

The simplest possible method is to have the character value itself be the index of the bitmap in the array. This works well when all of your bitmaps are the same size and your character set is something like ASCII or code page 437.

My understanding of your situation is that Grub has placed you in a graphics mode and now you want to display text to that mode, and you are going to have to display the pixels of each character yourself.

If this is the case, have you seen the thread where this is discussed?

You have to have some form of a bitmap stream.

My reply in that thread links to a page that shows you to make your own font with a 96-byte header, a 12-byte info block for each character, then a bit stream of these characters. You can hard code this "file" in your kernel (which was suggested and I agree with the comments about doing so), or once you get a file system up and running, you can load as many as you wish.

The thread mentioned above also has other suggestions. bzt points you to the PSF2 format that Linux use(d).

Anyway you do it, you will need to have some kind of bit stream, a bit indicating whether to show a pixel or bring the background through.

Ben

P.S. I just recently updated the format and source code for that font I use in that post.

BenLunt wrote:My understanding of your situation is that Grub has placed you in a graphics mode and now you want to display text to that mode, and you are going to have to display the pixels of each character yourself.

If this is the case, have you seen the thread where this is discussed?

You have to have some form of a bitmap stream.

My reply in that thread links to a page that shows you to make your own font with a 96-byte header, a 12-byte info block for each character, then a bit stream of these characters. You can hard code this "file" in your kernel (which was suggested and I agree with the comments about doing so), or once you get a file system up and running, you can load as many as you wish.

The thread mentioned above also has other suggestions. bzt points you to the PSF2 format that Linux use(d).

Anyway you do it, you will need to have some kind of bit stream, a bit indicating whether to show a pixel or bring the background through.

Ben

P.S. I just recently updated the format and source code for that font I use in that post.

Awesome! Thanks! I'll be sure to use this!

Either format, mine or the Linux PSF formats, each have an advantage and disadvantage.

Mine has the advantage of specifying a width for each character. For example, when using a fixed width font, there is a lot of space wasted between two characters when the i character is used. For example, look at the word "fixed". If this was a fixed font, there would be a bit of space before and after the i character. The disadvantage, this function adds meta-data to the font file, as well as each bitmap stream starts at a different byte-boundary.

The PSF format(s) have the advantage that each bitmap stream starts at a 'width' boundary, easily and quickly calculated. It also only has a four- or 32-byte header, nothing more as far as meta-data. The disadvantage, there is a lot of space between the 'i' character and other characters. Same for other characters, like ! ( ) | etc. It also wastes space in the file. For example, a 9-bit width character will waste 7 bits per horizontal line per character. A 9x16 character font, with 256 characters, will waste 28,672 bits (3,584 bytes) in the file. Nothing really, especially if the file system already allocated 4096 bytes, but still, waste is waste.

I recently updated the FontEdit app to allow loading and saving of PSF fonts as well. You can load a PSF font and save it as my font format, visa-vesa, or simply back as a PSF font. It is for Windows only, but source code is available. I haven't tried, but I am curious if it can be compiled on a *nix machine using Wine or something like that, or simply by re-coding it for *nix. If someone does, I would be more than happy to include the source on my page(s).

Ben

BenLunt wrote:Either format, mine or the Linux PSF formats, each have an advantage and disadvantage.

Mine has the advantage of specifying a width for each character. For example, when using a fixed width font, there is a lot of space wasted between two characters when the i character is used. For example, look at the word "fixed". If this was a fixed font, there would be a bit of space before and after the i character. The disadvantage, this function adds meta-data to the font file, as well as each bitmap stream starts at a different byte-boundary.

The PSF format(s) have the advantage that each bitmap stream starts at a 'width' boundary, easily and quickly calculated. It also only has a four- or 32-byte header, nothing more as far as meta-data. The disadvantage, there is a lot of space between the 'i' character and other characters. Same for other characters, like ! ( ) | etc. It also wastes space in the file. For example, a 9-bit width character will waste 7 bits per horizontal line per character. A 9x16 character font, with 256 characters, will waste 28,672 bits (3,584 bytes) in the file. Nothing really, especially if the file system already allocated 4096 bytes, but still, waste is waste.

I recently updated the FontEdit app to allow loading and saving of PSF fonts as well. You can load a PSF font and save it as my font format, visa-vesa, or simply back as a PSF font. It is for Windows only, but source code is available. I haven't tried, but I am curious if it can be compiled on a *nix machine using Wine or something like that, or simply by re-coding it for *nix. If someone does, I would be more than happy to include the source on my page(s).

Ben

Thanks for the tips! Your application worked great!

I don't think there is any need for specific formats or headers. You just decide how wide & high the characters are (using widths that are a multiple of , and then define an array (in C) or use db in assembly. There is no reason to scale these fonts, and so always using the same width & height makes most sense and is easiest.

I think you can define the graphics yourself. It's not that hard.

I use a 8x19 font that I embed in assembly both in the OS kernel and crash debugger.

For application fonts, I'd use TTF formats instead.

Caffeine wrote:Hi, I am reading the article on the wiki about VGA fonts, and am a little confused as to how to set it up properly and use it. How do I get the bitmap of a specific character? And is there a way to use GRUB to do this?

EDIT:
Here is what I did to easily store the font in an array.

I downloaded this Font Edit App: https://www.fysnet.net/fontedit/index.htm and dumped the System256.fnt font into a file using that application. Thanks for saving me so much time!