Proportional Bitmap Fonts

[flashjazzcat]

Before I start messing around with proportional fonts, I figured it would be a good idea to finalise the data structure and format for the character data. I don't fancy designing a load of proportional fonts in different point sizes, so I've been looking for a way to manufacture some in bulk.

 

There are many bitmap font generators on the internet, but I've just downloaded this one:

Bitmap Font Generator

 

At first sight, it looks as if the parser to deal with the program's output (see the links to code examples further down the page) could be implemented on the Atari, although a better solution would be a PC app which produces a special Atari font file. Not being a PC programmer, the latter is probably beyond my capabilities at the moment. This could be a really quick way of producing quality proportional fonts for the 8-bit.

 

Tutorial

 

The goal is to write a flexible rendering engine for proportional bitmapped fonts. I feel this is the logical starting point for a good quality GUI on the 8-bit.

[Rybags]

With VBXE, it will be easy - in the 160 and 320 bitmap modes you don't do any time-wasting bitshifts.

 

Of course, somewhat different in legacy mode. It's something I wanted to look into (Gr 8 stuff) for a while but of course it always sat at the back of the queue.

 

Data structure... hard to say. Representing character widths with 4 bits would mean an easy unpack. It could probably be done in 3 bits, given that you have a certain minimum character width and could represent it as an N+x type thing.

 

Generating the font and the data structures... least of your worries. At a pinch you could write a quick program that just uses fixed pitch data and generates widths based upon empty bitspaces at the right.

[flashjazzcat]

Generating the font and the data structures... least of your worries. At a pinch you could write a quick program that just uses fixed pitch data and generates widths based upon empty bitspaces at the right.

That's the approach I was originally going to take when bundling together a quick test system. Getting the font data converted is the time-taking part as far as I'm concerned. Data-structure wise, minimally we just need the dimensions of the byte matrix for the characters, a table of character widths, and probably a baseline value if that can be calculated (so the descenders on the large characters drop below those of the smaller ones). If I can parse the output of the Bitmap Generator program on the Atari, I should be able to generate the font files that way.

 

Rendering them - though hard to do efficiently - will be the fun part. The key is to have a system which is adaptable and will "accept" more fonts in different sizes when we add them later. The bit shifts are a definite pain in "legacy" mode, but I was playing around with doing the thing with look-up tables the other day and that should speed things up a bit. For example, we can have a table of all the possible bit shifted values of the byte masks (of which there are only eight at most) in each of the rotated positions. That's quicker than LSR, ROR in a loop. While flexible, the renderer also needs to be fast enough to draw the "system" font at high speed when drawing menus and dialogues. I've written a fast proportional renderer (on paper) for single-byte characters, but it will need extending to cope with larger fonts.

 

I've also thought a lot about a printf routine using proportional fonts. The field widths would be specified (I imagine) in pixels rather than character cells, and would need clipping to a fixed width and height region, although this introduces extra processing.

Edited November 28, 2009 by flashjazzcat

[Rybags]

Yep... definately go the tables for the pre-rotated stuff. So then all you need to do is the lookup, then the choice of 2 bitmasks depending on if you want to pull the left or right hand part of the chr data out when it's spanning 2 screen bytes.