Re: [PATCH] GSoC #10 new font engine (UTF-8 support+bugfix)

[Vesa Jääskeläinen]

Colin D Bennett wrote:
> On Sat, 06 Dec 2008 22:18:14 +0200
> Vesa Jääskeläinen <address@hidden> wrote:
> 
>> Colin D Bennett wrote:
>>> Update: 
>>>
>>> I fixed an error pointed out to me by Y.Volta: 
>>> In grub_font_get(), if no fonts are loaded, a null pointer is
>>> dereferenced.  This is fixed in the attached patch.
>>>
>>> The grub_font_get() function now returns a dummy font object (a
>>> statically allocated font object with no characters) so that
>>> callers of grub_font_get() can be assured that the return value
>>> will never be NULL.  If no fonts are loaded, then the "unknown
>>> glyph" will be used for all characters, but it will be safe.
>> Hi Colin,
>>
>> I applied this patch against SVN today and tried it out. And noticed
>> that gfxterm gets a bit "broken" after this. Was this the thing that I
>> promised to look at :) ? Or was my merge just incomplete?
> 
> There are two problems with gfxterm now:
> 
> 1.  unifont has problems rendering glyphs: they seem to be rendered
>     too wide (maybe), and the cursor ends up being drawn after each
>     character resulting in t_e_x_t_ _t_h_a_t_ _l_o_o_k_s like this.
> 
> 2.  With fonts that otherwise work (i.e. "Fixed 10" for me), sometimes
>     a few random junk characters with weird background/foreground
>     colors show up in gfxterm -- mainly when it is first set as the
>     terminal, leading me to think that there is some uninitialized
>     memory.

I think I have workable solution for these now in my local copy.

>> Videotest was fine however. (or how fine it can be with just
>> unifont.bdf)
> 
> I should look closely at unifont.bdf and the .pf2 conversion and see
> why GRUB is rendering it weirdly in gfxterm.

Actually what we want is to have improved conversion tool.

If I make full conversion it generates ~1.7 MiB font file which does not
fit to floppy. Now if we could specify unicode ranges what to put there
it would make them smaller.

This would be similar to how you specify ranges to old pff converter. I
was planning to make such modification to handle near term goal.

Actually it would be nice if converter tool would be in C. Then it could
be compiled and executed easily during normal compilation process.
Viewer application is not so important and it can be external to project
. Same time with C implementation it would be easy to add compression
there too.

>> After:
>> loadfont /boot/grub/unifont.pf2
>>
>> lsfonts gives:
>> Loaded fonts:
>> Unknown -1
>>
>> Is this expected?
> 
> Yes, since there is no 'POINT_SIZE' or 'FAMILY_NAME' attribute in the
> unifont.bdf file.  I added these manually, and it then showed up
> properly in the lsfonts listing (and can then be specified using the
> name/size in GRUB).

Perhaps this addition should be moved to GNU Unifont's upstream?

> --- gnu-unifont-2008-04-06.bdf        2008-12-22 08:48:00.000000000
> -0800 +++ gnu-unifont-2008-04-06_tagged.bdf   2008-12-22
> 09:10:22.000000000 -0800 @@ -1,5 +1,8 @@
>  STARTFONT 2.1
>  FONT -gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1
> +FAMILY_NAME "unifont"
> +WEIGHT_NAME "medium"
> +POINT_SIZE 100
>  SIZE 16 75 75
>  FONTBOUNDINGBOX 16 16 0 -2
>  STARTPROPERTIES 3
> 
> The font converter should probably fall back on the file's name and the
> font's pixel size if such specifications are missing in the BDF file.
> 
> 
> Sorry for the delay getting back to you; now that the font patches are
> going in, I will be ready to continue work on submitting the graphical
> menu system patches.  I've received e-mails from a number of people who
> have found my project web site and want to try out the graphical menu,
> and are asking when it will be merged into GRUB.

I'll try to get them in. But I have to make it in way to normal grub
operation do not break at same time. Temporary this means probably that
toolchain is there in Java form unless you can make quickly the new
converter. It can start without compression. What we want is to match
functionality of old font converter. Eg. specify ranges and then
generate file based on that one.

Thanks,
Vesa Jääskeläinen