OSDev.org

hi there,

i'm working on the gui for my operating system. for those of you that already implemented some gui: how does your os render text? do you just use bitmap-fonts? freetype? something different? why? what should/could i use? advantages, disadvantages? do you know anything about the performance of font-rendering? how would you implement font-rendering in a microkernel-os? a font-server? inside the gui-server? shared lib?

my os is written in pascal. i didn't port gcc or libc so far.

regards,
simon

I'm currently intending to use the concept of an outline font (with the concept of "strokes" and cubic splines for the curvy parts), for all my fonts. At any one size, bitmap fonts and outline fonts are mathematically identical, but outline fonts scale better. But there is a chance I may change it all to entirely using strokes, instead.

Brendan has argued that you should implement as much graphics stuff as possible in the driver. That way, the commands that can be accelerated in video hardware (line drawing) can be passed to the GPU in an acceleratable form (not as bitmaps).

But that means that font rendering could look different depending on the graphics driver. That sounds undesirable.

I just read about HarfBuzz (http://freedesktop.org/wiki/Software/HarfBuzz) and Pango (http://www.pango.org/). Text layouting looks very complicated to do right... Does your system support non-latin scripts? Should it?

Well, honestly, I agree with you. I'd say that most font drawing should be done in the GUI manager. Curvy stuff can't be accelerated -- it has to be passed to the graphics card as bitmaps. Also, lines with varying widths cannot be accelerated either. So it is only some portions of (mostly) latin alphabets that are straight enough to benefit from acceleration at all.

And if you do font rendering in the GUI manager, it will be consistent over the system, and there won't be any code duplication. Generally, a "glyph" is small enough that it seems like a waste of time to try to break it down into smaller (acceleratable) sub-pieces, too.

And yes, I don't see any way around supporting the concept of non-latin character sets. Your word processor is going to need to do "dingbats" and math symbols, and your network browser is going to want to support a full UTF encoding.
However, your system can certainly have a preferential support for latin fonts -- so that they are "built-in", or more efficiently encoded.

Hi,

bewing wrote:Well, honestly, I agree with you. I'd say that most font drawing should be done in the GUI manager. Curvy stuff can't be accelerated -- it has to be passed to the graphics card as bitmaps. Also, lines with varying widths cannot be accelerated either. So it is only some portions of (mostly) latin alphabets that are straight enough to benefit from acceleration at all.

I'd have a "font server" - you tell it what you need and it generates an "alpha bitmap" that you can use to determine if each pixel should be foreground or background (or in-between, for anti-aliasing purposes) .

More specifically, the GUI tells the video driver everything it needs and the video driver is responsible for drawing everything (including asking the font server to convert character data into "alpha bitmaps" and drawing the alpha bitmaps, if necessary), so that the video driver can cache these alpha bitmaps and potentially draw them using hardware accelerated "videoMem -> videoMem" bit blits.

bewing wrote:And if you do font rendering in the GUI manager, it will be consistent over the system, and there won't be any code duplication.

That depends on the OS I guess - if your OS supports many GUIs (e.g. KDE and Gnome on the same system) then fonts may not be consistent over the entire system and you'd get code duplication. Then there's full screen applications that don't use a GUI (e.g. something that uses SVGAlib instead).

bewing wrote:And yes, I don't see any way around supporting the concept of non-latin character sets. Your word processor is going to need to do "dingbats" and math symbols, and your network browser is going to want to support a full UTF encoding.

Probably the hardest thing for a font engine to support would be languages that are written "right to left" (instead of left to right), where characters are linked (e.g. like "cursive" for latin characters). Arabic is just one of these languages, but there's many of them.


Cheers,

Brendan

bewing wrote:Well, honestly, I agree with you. I'd say that most font drawing should be done in the GUI manager. Curvy stuff can't be accelerated -- it has to be passed to the graphics card as bitmaps. Also, lines with varying widths cannot be accelerated either. So it is only some portions of (mostly) latin alphabets that are straight enough to benefit from acceleration at all.

And if you do font rendering in the GUI manager, it will be consistent over the system, and there won't be any code duplication. Generally, a "glyph" is small enough that it seems like a waste of time to try to break it down into smaller (acceleratable) sub-pieces, too.

And yes, I don't see any way around supporting the concept of non-latin character sets. Your word processor is going to need to do "dingbats" and math symbols, and your network browser is going to want to support a full UTF encoding.
However, your system can certainly have a preferential support for latin fonts -- so that they are "built-in", or more efficiently encoded.

Hi,

Not quite - "curvy stuff" can be accelerated by most cards. Whether you have hardware acceleration or not is a different matter though...