font changes after configfile command

[GoogleCodeExporter]

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?

Original issue reported on code.google.com by Steve6375 on 17 Nov 2013 at 11:44

[GoogleCodeExporter]

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

Original comment by tinyb...@gmail.com on 18 Nov 2013 at 7:03

[GoogleCodeExporter]

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?

Original comment by Steve6375 on 18 Nov 2013 at 9:45

[GoogleCodeExporter]

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?

Original comment by tinyb...@gmail.com on 19 Nov 2013 at 4:00

• Changed state: Started

[GoogleCodeExporter]

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.

Original comment by Steve6375 on 19 Nov 2013 at 12:02

[GoogleCodeExporter]

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

Original comment by Steve6375 on 19 Nov 2013 at 1:03

[GoogleCodeExporter]

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

Original comment by tinyb...@gmail.com on 20 Nov 2013 at 5:14

[GoogleCodeExporter]

> 0067:0000000000023A44444438203C42423C

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

Original comment by tinyb...@gmail.com on 20 Nov 2013 at 5:21

[GoogleCodeExporter]

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

Original comment by Steve6375 on 21 Nov 2013 at 12:40

[GoogleCodeExporter]

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?

Original comment by Steve6375 on 25 Nov 2013 at 9:52

[GoogleCodeExporter]

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

Original comment by tinyb...@gmail.com on 26 Nov 2013 at 8:36

[GoogleCodeExporter]

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

Original comment by Steve6375 on 26 Nov 2013 at 9:32

[GoogleCodeExporter]

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.

Original comment by tinyb...@gmail.com on 27 Nov 2013 at 2:36

[GoogleCodeExporter]

seems OK to me :-)
Thanks.

Original comment by Steve6375 on 27 Nov 2013 at 11:20

[GoogleCodeExporter]

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

Original comment by Steve6375 on 28 Nov 2013 at 1:00

[GoogleCodeExporter]

This issue was closed by revision r367.

Original comment by chenall.cn on 30 Nov 2013 at 1:55

• Changed state: Fixed

[GoogleCodeExporter]

This issue was updated by revision r367.

Original comment by chenall.cn on 30 Nov 2013 at 1:55