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:
Code:
........
...1....
..1.1...
.11111..
.1...1..
.1...1..
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