So I've finally managed to switch my kernel to UEFI, but along with this comes a difficulty: the UEFI framebuffer is not the VGA buffer where I could just write strings.
So now, I have to use font rendering of some kind, either using 8x8 fonts or full TTF rendering. I'm considering using fontdue (a Rust crate) to rasterize glyphs, but my confusion stems from the fact that I don't know how to write them to the buffer so they don't overlap or make other weird visual things that are unreadable. Even if I read the TTF font data manually, I imagine I'll still run into this problem. Can someone explain precisely how this exactly works?
TTF font rendering
Re: TTF font rendering
Full TTF rendering seems like a bit over your head. You should be happy with bitmap fonts, you won't stay at UEFI land for long.Ethin wrote:So I've finally managed to switch my kernel to UEFI, but along with this comes a difficulty: the UEFI framebuffer is not the VGA buffer where I could just write strings.
So now, I have to use font rendering of some kind, either using 8x8 fonts or full TTF rendering.
A simple way out is to use PC Screen Fonts (the same that Linux uses). My boot loader has some extremely minimal, dependency-free examples on how to display them in C and in Rust.
You can find a lot of free fonts in PSF format, they are already on your computer (if you're using Linux), or you can download many from the internet, for example this, and this etc.
That's exactly the job of the rasterizer. Vector fonts can't be displayed as-is, first they are rasterized into bitmap fonts (at a requested size), and after that, well, they act exactly like any other bitmap font.Ethin wrote:I'm considering using fontdue (a Rust crate) to rasterize glyphs, but my confusion stems from the fact that I don't know how to write them to the buffer
In theory, it is simple. First, you have to parse TTF font data and decode it into outlines, metrics and kerning information. Then you have to use those to rasterize a bitmap, and finally you can blit that bitmap to the screen. (Outlines define how each character should look like, metrics are the dimensions of the bitmap and pen adjustments, and kerning pairs are the relative distance between character combinations.)Ethin wrote:so they don't overlap or make other weird visual things that are unreadable. Even if I read the TTF font data manually, I imagine I'll still run into this problem. Can someone explain precisely how this exactly works?
But in practice, doing this correctly is EXTREMELY hard. The popular freetype2 library, which has been developed for decades, can't do it right. Also read FontForge's documentation, they are ranting pages over pages how incompatible MS and Apple fonts are, there's no standardized way to get all chunks from a TTF font reliably (specially when it comes to ligatures and character mappings). Then there's the problem of the hinting bytecode, you'll need to implement a virtual machine operating on geometrical data to interpret them. Here again, most fonts have bad, wrong or incorrect hinting bytecode, so you'll have to write that vm bullet-proof (tools that can create good hinting bytecode are patented and very expensive). Long story short, you don't want TTF, it s*cks big time, many very very experienced developers can't get it right for decades.
Cheers,
bzt