Re: [Linux-fbdev-devel] fonts

[Antonino D. <ad...@po...>]

On Wed, 2003-01-22 at 00:14, Geert Uytterhoeven wrote:
> 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)?

I meant for each row of bits representing a pixel in a bitmap, the start
index and the size of each row will be byte-aligned.  So, the padded
version.
> 
> 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
> 

The latter is very difficult to support by most common hardware as they
require the padding.  Actually, some, maybe most, cards require more
than a byte padding. 

If we do need to support both versions, then we need extra fields to
fb_image, such as clipx1 and clipx2, where: 

	image.clipx1 = starting index;
	image.clipx2 = clipx1 + width;

(Do we also need something similar for the y coordinate?)

Using a 12x22 font as an example:

In the first (padded) version, 

	image.width = 16;
	image.clipx1 = 0;
	image.clipx2 = 12;

whereas in the second (packed) version:

	image.width = 12;
	image.clipx1 = depends on the character;
	image.clipx2 =  image.clipx1 + image.width;

I can't really think of any other way if we need to support both types
of bitmap in a device and OS independent manner.

I think I'll let you and James decide on this :-) 

Tony