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

[Colin D Bennett]

On Tue, 23 Dec 2008 20:39:15 +0200
Vesa Jääskeläinen <address@hidden> wrote:

> 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.

Great.

> >> 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.

Also, I'd like to add LZMA compression as previously discussed, which I
think would give a huge improvement.

> 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.

It certainly could be rewritten in C, but it would take some time.

> >> 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?

Perhaps.

> > 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.

Well, I don't have time right now to rewrite the converter; not for a
couple of weeks, at least.  I'm certainly willing to do it, so I'll get
to it when I can, and then we can replace the Java converter.

Regards,
Colin

signature.asc
Description: PGP signature