On Tue, 23 Dec 2008 20:39:15 +0200 Vesa Jääskeläinen wrote: > Colin D Bennett wrote: > > On Sat, 06 Dec 2008 22:18:14 +0200 > > Vesa Jääskeläinen 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