What steps will reproduce the problem? 1. Make a menu.lst with graphicsmode -1 800 font /unifont.hex.gz

text is thin

2. Now load new menu using

title menu1 configfile /menu1.lst

>> text is now bold (thick)

What is the expected output? What do you see instead? configfile seems to change the font?

What version of the product are you using? On what operating system? 0.4.5c latest

Please provide any additional information below.

Also, if load a font using font /unifont.hex.gz then UTF-8 characters (e.g. chinese) is displayed OK as expected

then if run font to clear the font, chinese characters are still displayed in the menu correctly even though font should be cleared?

P.S. Where can we find different font files?

"font"(without argument) does not actually clear the current non-ASCII character patterns. It clears the "font loaded" indicator and enables the next "font ..." command to load additional character patterns. It also loads the ROM ASCII font, which usually looks like bold(or thick).

"font"(without argument) might run automatically with "configfile ...". If you need the thin ASCII font, you may load a small thin ASCII font once again in your new menu.lst.

The unifont.hex is in plain text format. You may manually edit the unifont.hex and create your own small font file, or change the pattern data in the font file.

Why does configfile 'automatically run "font" and set it back to ROM characters' ?? Loading unifont.hex.gz produces a thin font, but then loading a new menu.lst using configfile loads the thicker ROM ASCII font again. Why is this - surely it is a bug. If we have 20 menus, why do we have to load the 1MB unifont.hex.gz file in each menu when we have already loaded it once in the first menu?

Do you know of any ready-made alternative font hex files or a way of converting existing fonts to the correct grub4dos format for the font command?

Please check if the attched source code could solve the problem. And sorry I cannot compile it for you now.

Do you know of any ready-made alternative font hex files or a way of converting existing fonts to the correct grub4dos format for the font command?

Sorry I don't at this moment. I just Googled for "unifont.hex", and I got these pages: http://en.wikipedia.org/wiki/GNU_Unifont http://unifoundry.com/unifont.html Does that help you?

The new Stage2.c still does not work, but if I comment out the line font_func (config_file, 0); then it does work and the new font is displayed in all menus.

If I have a menu.lst title gggg root ()

0067:0000000000023A44444438203C42423C

Then the gggg in the title appears as thick text (the new character is not displayed).

If I have a menu:

title halt (关机) halt

5173:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFFFFFFFFFFFFFFFFFFFFFFFFF

Then the first character in halt is displayed correctly as new character.

So it appears that the font_func(config_file,0); line is resetting roman ascii characters to the ROM font even if they are defined in the same menu.lst file

In builtins.c, please change this

if (! valid_lines) goto build_default_VGA_font;

to this

if (! valid_lines) return valid_lines;

together with the previously modified stage2.c.

Could that work fine?

0067:0000000000023A44444438203C42423C

The line should end in a CR or LF(or both). It should not end in a NULL or even "End of File".

0067:0000000000023A44444438203C42423C

You should not append any other chars to the end of the line. The only char allowed is CR or LF.

yes - using if (! valid_lines) return valid_lines; fixes the problem for me :-)

Can you check that font command returns result correctly, e.g.

font /unifont.hex.gz && echo OK

does not print OK even if correctly loaded?

before you use "font ..." command to load a new font, you should use a font command (without argument) to enable the next "font ..." command.

You cannot use a "font ..." command after another "font ..." command.

Each time the "font ..." command runs, it will automatically disable the next "font ..." command, so as to avoid possibly loading a large font twice.

"font" (without argument) also restore the ROM VGA font(for all ASCII chars 0x20 - 0x7F).

If a fresh boot (no menu.lst) I run the batch file (modified grldr for fix in #3 and #8...

!BAT font /terminus.uni && echo 1 font /terminus.uni && echo 2 font /sansf1.uni && echo 3 font && echo 4 font /terminus.uni && echo 5 font /terminus.uni && echo 6 font /sansf1.uni && echo 7

Output is 1 4 5 6 7

So after a 'font' command, loading a unifont file always returns 'True'. If the same batch file is run again after running once on same boot, I get 1 2 3 4 5 6 7

Thank you very much.

Well, in builtins.c, please change this:

if (i == old_narrow_char_indicator)
return valid_lines; /* nothing need to change, success */

to this:

if (i == old_narrow_char_indicator)
{
*(unsigned long *)UNIFONT_START = i;    // disable next font command.
return valid_lines; /* nothing need to change, success */
}

That would fix the issue.

Now I also upload the whole source file of builtins.c for you (and chenall) to check.

seems OK to me :-) Thanks.

@chenall: Is this change OK to include in a new version now? Can you make a new release please? Thanks!

This issue was closed by revision r367.

This issue was updated by revision r367.