[fbsplash patch] - text rendering.

[Michele Sanges]

Yann,
thank you for the comments.

Yann E. MORIN ha scritto:
>> Yes, but I think also that this feature could be easily put under
>> conditional compilation.
> 
> Yes, it should be a config option.

Ok, now the text rendering is under the FBSPLASH_TEXT_RENDERING option.


>>> The fontmap sounds like it could reside in RO, perhaps.
>> What you mean with RO? Read only memory? Isn't it hardware dependent?
>> Please, can you give me a more detailed description?
> 
> -static char fontmap[95][12] = {
> +static const char fontmap[95][12] = {

Uh, much more clear! Of course, done.


>> Also, the fontmap could reside in a external file with the applet that loads
>> one character at a time.
> 
> Yes please do so, this way people could have 'personalised' font maps.
> Still, offer a config option to hardcode the fontmap file.

With the new patch the text rendering is an option of the fbsplash applet.
I have also added an option (-m) to pass the map of characters from an 
external file. For the moment the font map file that I have added to the 
project (fbsplash_fontmap) contains the same fonts hard coded.

For the three options, the size output is:

size miscutils/fbsplash.o
    text    data     bss     dec     hex filename
    1773       0       0    1773     6ed miscutils/fbsplash.o
size miscutils/fbsplash_hardcoded.o
    text    data     bss     dec     hex filename
    3447       8       0    3455     d7f miscutils/fbsplash.o
size miscutils/fbsplash_extfile.o
    text    data     bss     dec     hex filename
    2375       8       4    2387     953 miscutils/fbsplash.o


> And a further improvement would be to support multibyte-strings for
> localisation.
> 
> I would recommend having a simple font file like:
>   # Lines starting with # are ignored
>   # So are empty line
>   0x12345678 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C
> 
> where the first hexa number is the UTF-8 sequence to be recognised, and the
> folowing single bytes are the patern to draw.
> 
> Of course, the font table will be sparse, and finding the character to
> draw will need (smart) iteration throught the table. And because the table
> might miss entries for some characters, have a default character be drawn
> (eg 0x00000000).
> 
> Then, in the build procedure, have a litle script that parses that file format
> and outputs either a .h file if the font is hardcoded, or a binary blob if the
> font is dynamicaly loaded at run time.
> 
> So to sum up:
>  - text rendering should be configurable
>  - the font map can be either hard-coded to use the default font map,
>    or it can be dynamically loaded at runtime, so the user can create
>    their own font maps
>  - font map should be UTF-8 compliant, to allow localisation.
>  - the source font map format should be documented (at least in the
>    default font map).
> 
> Of course, this is but my opinion. :-)

Very interesting design Yann!!
But since I have not yet had other answer, I propose to postpone this 
improvement.

Please, someone can test the new functionality?

Thanks a lot.

-- 
Michele Sanges

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fbsplash_patch21_09_08.diff
Url: http://lists.busybox.net/pipermail/busybox/attachments/20080922/62970e6a/attachment.diff 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fbsplash_fontmap
Type: application/octet-stream
Size: 1140 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20080922/62970e6a/attachment-0002.obj