Re: [Linux-fbdev-devel] fonts

[Geert U. <ge...@li...>]

On Wed, 15 Jan 2003, James Simmons wrote:
> > > The cfb_imageblit() function exhibited the same behavior.  I think we
> > > both made the wrong assumption that all monochrome bitmaps are packed. I
> > > think the rule is:
> > > 
> > >     The first pixel on the next scanline is always at the next byte from
> > >     the last pixel of the current scanline.  
> > > 
> > > So a 12x22 font has 16 bits per scanline but only 12 are usable, and the
> > > last 4 are used as padding.  It's worse with a 4x6 fonts where the
> > > 4-bits are just duplicated in the other nibble.
> > 
> > Yes.
> 
> All the font data should be packed and byte padded at the end of each 
> scanline worth of data. Also most accel engines expect the data to byte 
> packed.

What do you mean with `each scanline worth of data'? Data for one character, or
data for the whole font (i.e. all characters)?

Currently we use the former, while e.g. AmigaOS used the latter and stored
fonts like this:

  - First line: concatenated bit string of the first lines of each character
  - Second line: concatenated bit string of the second lines of each character
  - and so on

I.e. each line looked like

    aaaaaaaaaaaabbbbbbbbbbbbccccccccccccdddddddddddd...

with a table to map between characters and starting bit index.


The former has the following advantages:
  - Character data always starts at a byte boundary
  - It's easy to store fonts in a common format (i.e. the same for both little
    and big endian, currently fonts are stored big endian)

The latter has the following advantages: 
  - Less memory waste if fontwidth % 8 != 0
  - Easy to support proportional (variable width) fonts

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds