OSDev.org

There has been a bit of discussion on system fonts lately. Especially since newer hardware and firmware no longer allows you to use the 0xB8000 method to write to the screen.

Therefore, you have to create a font simply to display text to the screen as your OS boots, displays debug information, etc. This font can be a simple bitmap, a set bit indicating to display a pixel, a clear bit indicating to show the background.

However, making this bitmap is a big task in it self.

For those that don't know, the CDROM included with Volume 6 of my books is freely available and contains a font creator. This font creator allows you to easily create a font using a GUI Application and then writing this bit stream to a file.

I have created a page that discusses this in a little bit of detail. It contains a 32-bit and a 64-bit Windows version of this utility. (source not included, but see below)

It will allow you to create this bitmap you need to feed to your OS font engine to display fixed sized fonts.

As for the source code which is included in the .ISO file linked above. It is for Window 32-bit only (and an older version at that), but does not use MFC, so I believe that it should compile for other platforms. For example, I have not programmed for Linux, but from what I have gathered, Linux can compile a Windows app as long as it does not use MFC.

If there is anyone here that can elaborate on this subject, I can send you the latest code if you will modify and compile it for Linux, then get back with me here to allow me to included it on my page(s).

Thank you,
Ben

Your code is written directly against the Windows API, which is not portable (unless you count Wine).

well, if purists started to argue... unless not counting Whine, one may count ReactOS. and why do you think WinAPI is not portable? actually, it's all documented, and not forbidden to implement, right? so every platform implementing it, could run programs written for it, just like with anything else.
and honestly, if "not counting" bloated "toolkits", there is no really "portable" API, that provides the functionality comparable to what WinAPI does. I hate when some lil by its intended function program is made into a huge bloat, thanks to "portable" QT or alike staffed into. overhead, bloat, and not a bit easier for the programmer, than learning to use freaking native API for every platform they want to port to. kudos to Ben for using native interfaces, instead of hoggy wrappers.

@BenLunt: looks great! Do you use some standardized font format, or is it your own? I like that it has per glyph metric information, which I really much lack from PSF2.

I think that Octocontrabass was commenting on "I believe that it should compile for other platforms. For example, I have not programmed for Linux, but from what I have gathered, Linux can compile a Windows app as long as it does not use MFC."

This is plainly incorrect.

iansjack wrote:I think that Octocontrabass was commenting on "I believe that it should compile for other platforms. For example, I have not programmed for Linux, but from what I have gathered, Linux can compile a Windows app as long as it does not use MFC."

This is plainly incorrect.

Yes, it is incorrect. Furthermore, maybe I missed something, but I believe BenLunt hasn't released the source code for his editor. This means you can't compile it under any OS. But even if you could, porting Win32 API to POSIX + X11 calls is not a trivial task, and I don't know any C source-level Win32 API wrapper under Linux. If anyone knows one, please let me know, I'm interested.

Cheers,
bzt

bzt wrote:@BenLunt: looks great! Do you use some standardized font format, or is it your own? I like that it has per glyph metric information, which I really much lack from PSF2.

It is completely a format of my own. Since it is solely designed to give me a system font used at boot up and terminal windows, etc., it only needs to be a bitmap of a character. For example, the letter 'A' needs to have a bit stream of: If the bit is set, draw a pixel. If the bit is clear, show the background pixel.

This allows me to have a text output system very early in the booting process.

As far as this is concerned, I could have stopped at that point. There is no need to move on. However, since my code is not dependent on the font used, nor the width or height of the font, I can now add many more fonts to the system. The few "metrics", as you called them, are added so that my GUI can now use the font as well. For example, in the Lucidia font, I show on the page I mentioned before, especially with the shown 'W', the next character drawn would look like there was a space between the 'W' and the next character. With the "metrics" of the font, I can override the width *after* the drawing of the character and have the next character drawn closer to the 'W'.

Again, all of this is simply a bitmap. It doesn't use glyphs as yours does. Yes, one could draw it larger or smaller, simply scaling the bitmap, but it does not use glyphs describing each part of the character. This was simply to allow me to have a text based font from the start of the boot process, just as my kernel takes over. All the kernel needs is the screen mode to be set, the information about the current screen, and the Linear Frame Buffer of the screen. Any font could then be used from that point on, giving me debug information to the screen, instead of to the serial or parallel ports.

The reason for all of this comes back to the use of UEFI. As you all know, if you are using a Legacy boot, you can simply draw characters to the screen using a 16-bit value and the 0xB8000 method. The BIOS prints to the screen using this method (most likely), along with your different stages of your boot code, and finally your kernel, before it actually moves to a graphics screen. It was quite simple.

However, as soon as you use UEFI, this method most likely is no longer available. The UEFI system has its own method to draw to the screen (most likely a very similar method I use above), but just as soon as the UEFI is exited, your code is stuck, having no way to write to the screen.

When I first started using UEFI, I couldn't figure out why my kernel wouldn't write to the screen, until I read that a UEFI system most likely will not have the hardware to support legacy screen access. This font system came out of necessity, because of this.

bzt wrote:Yes, it is incorrect. Furthermore, maybe I missed something, but I believe BenLunt hasn't released the source code for his editor.

As for the code, yes it is available from the ISO from Volume 6 linked half way down the page.

Octocontrabass wrote:Your code is written directly against the Windows API, which is not portable (unless you count Wine).

As for compiling for other platforms, again, I have never programmed for Linux, nor have I looked into it. I was once told that if I don't use MFC, one could modify the code a bit to run on Linux. Maybe they meant that it would have to be ran with Wine or something else. I don't know. I didn't pursue it any further.

Anyway, if someone decides to use this format with their system, please send me a link to your created font. I would like to include it within my collection of fonts.

Thanks,
Ben

BenLunt wrote:It is completely a format of my own.

Well done!

BenLunt wrote:As far as this is concerned, I could have stopped at that point. There is no need to move on. However, since my code is not dependent on the font used, nor the width or height of the font, I can now add many more fonts to the system. The few "metrics", as you called them, are added so that my GUI can now use the font as well.

Exactly the same reasons for my fonts! Btw, I call those "metrics" because it looks like all font-related software and documentation use that phrase. Take a look at FontForge for example, or at the freetype2 docs.

BenLunt wrote:Again, all of this is simply a bitmap. It doesn't use glyphs as yours does.

Actually my fonts can store bitmaps too, and exactly for the same reason why you invented your fonts.

BenLunt wrote:As for the code, yes it is available from the ISO from Volume 6 linked half way down the page.

I've missed that, cool! Great it's Open Source after all!

Cheers,
bzt