Created attachment 606233 [details]
grub edit mode
Description of problem:
Installed F18 Alpha TC3 into KVM. If you go to grub edit mode, the text font is barely readable. It is extremely largely spaced. It is very hard to edit boot options, because it's almost impossible to read.
Version-Release number of selected component (if applicable):
F18 Alpha TC3
KVM with vga driver
Seems to be essentially a duplicate of Bug 848884; a side-effect of Bug 840179 is that all graphics is seriously messed up.
Let's use this bug for the problem of the big font, considering it a separate problem to 848884, which was _really_ about the lack of a theme.
So it's fairly well established by now that the font we're using for grub2 in F18 doesn't work well in low resolutions...and all VMs seem to be considered by grub2 to have low resolution displays. Basically, you can't practically edit the menu entries within grub2 in a VM. vicodan reports that this also affects VirtualBox, just the same as KVM - see http://i.imgur.com/An2jF.png .
Nominating as Alpha NTH, it's often useful for troubleshooting purposes to be able to access this function.
So our /boot/grub2/themes/system/theme.txt has:
message-font: "DejaVu Sans Regular 12"
terminal-font: "DejaVu Sans Regular 12"
I suspect we want to use a monospace font at a much smaller point size. We could probably play with editing that file in a KVM and observing the results.
OK, so progress:
the font in question is terminal-font. Setting it down to size 10 makes things better, though still not really usable.
The fonts themselves are in “PFF2 font format”, in the /boot/grub2/themes/system directory - DejaVuSans-10.pf2 , DejaVuSans-12.pf2 , DejaVuSans-Bold-14.pf2 are the fonts. So we only have those three to pick from unless we add more.
I'll figure out how to make a PFF2 font file and then see if I can come up with one that's vaguely workable.
For fixed width font we should use 'unifont' in unicode.pf2. It seems like it doesn't have a real name, but it seems like 'Fixed' can be used as well. But that really doesn't matter:
The unicode font is always loaded ... but it seems like loading a theme resets the available fonts. (mkconfig will create instructions for loading all fonts found in the theme directory.)
An enabler for a solution/workaround is to place unicode.pf2 in the theme directories. I guess /boot always will be on a capable file system, so a symlink will do. (unicode.pf2 is insanely big.)
The default for 'terminal-font' is 'Fixed 10' which works fine, so I would recommend just leaving out that line. These two steps and running mkconfig works for me.
Discussed at 2012-09-12 NTH review meeting. Accepted as NTH as it can have a significant impact on testing and debugging on VMs (and probably low-res metal).
OK, I tested Mads' suggestion and it's definitely better. The lines still wrap a lot, but you can see what you're doing, and the fact that it's monospace I think fixes that bug where the character you're editing isn't the character it *looks* like you're editing. My name is Adam, and I approve this plan!
So the fix for this is entirely within theme.tar.bz2, one of the package SOURCEs. I have uploaded a new theme.tar.bz2 that incorporates the fix for this. The next time a grub2 build is done, this fix should be included automatically. Therefore, setting MODIFIED. Peter, Mads, throw this in the changelog next time you do a build...
*** Bug 858582 has been marked as a duplicate of this bug. ***
grub2-2.00-9.fc18 has been submitted as an update for Fedora 18.
Created attachment 621465 [details]
Screenshot showing working "edit box" but with LARGE font
I installed using Fedora-18-Beta-TC1-x86_64-DVD.iso using grub2-2.00-9.fc18-x86_64
After installation, pressing "e" in GRUB showed a working edit view. However, the font is still huge (see attachment), but it is an improvement compared to the previous version showing lots of spaces between the characters. It is at least usable....
(In reply to comment #11)
> Created attachment 621465 [details]
> Screenshot showing working "edit box" but with LARGE font
That font is not "LARGE" - only "large" ;-)
It uses the font size that it is intended to use and it is not the bug reported/fixed here. I don't consider the current font size a bug.
But it is a strange upstream decision that it doesn't use the full screen when using themes and editing or in command line mode. If you prefer to use the full screen then don't use a theme.
It is however a bug that the (german) help text is so long and not wrapped correctly. It seems like wrapping it correctly would give at least one extra line. Feel free to file it ... but I doubt anything else than waiting for an upstream fix will happen.
You are right, the font is not large. Instead the window is really small! I searched through the sources of GRUB and found out:
Under VirtualBox it uses the VBE (Vesa Bios Extension) driver. It asks the driver for its prefered size which it does not answer (This makes sense, because VirtualBox does not know, which size the window should be). GRUB defaults to 640x480 which is not much, but the comments state, that this is the biggest size, which is supported by all adapters. So I think, this is safe, too. We end up with 640x480 which is small, but safe.
The problem is, that our theme uses 56% width for the text box. Under 640x480 this is a width of only 358 px. As GRUB uses unifont (8x16 px) inside the text box, we end up with only 44 characters. When using 1024x768 we get 71 characters.
I would suggest:
1. Increase width of text box from 56% to 66% or even more. For 1024x768 this would give 84 characters width (and would help a little bit for smaller resolutions, too).
2. I will contact GRUB upstreams, if there are plans for "conditional" themes. This would mean, that there is a way to check for the resolution and depending on that info, decide which theme to use, or how to change the theme. For 640 width we could e.g. use a width of 99%.
it'd be best to continue the discussion in another bug report for clarity. i'm aware of everything in comment #13 already, but it's not part of this bug and addressing it is rather more complex than just fixing up the font choice. the current situation is a bit cramped but usable.
-9 went stable and it definitely fixes this, so closing.
-12 in F18 public Beta does not fix this.
I have reproduced this on QEMU/OVMF instances and a IBM x3550 M3 box (all UEFI systems). Bug 859632 will affect reproduction of this bug (I'm to post detail there).
In /boot/efi/EFI/fedora/grub.cfg, the last "loadfont" will be the font used by gfxterm terminal.
The default grub.cfg is like
I swapped the order of these, and gfxterm terminal did change font size, like in the attached image.
In grub-core/gfxmenu/view.c, init_terminal():
/* Note: currently there is no API for changing the gfxterm font
on the fly, so whatever font the initially loaded theme specifies
will be permanent. */
Btw, the terminal sizes are hardcoded to be 7/10 of the screen:
init_terminal (grub_gfxmenu_view_t view)
term_rect.width = view->screen.width * 7 / 10;
term_rect.height = view->screen.height * 7 / 10;
So theme.txt makes no different for sizes and font here.
But, really, we should be using monospace fonts.
Created attachment 659249 [details]
gfxterm loadfont DejavuSans-Bold-14,12,10.png
(In reply to comment #16)
> -12 in F18 public Beta does not fix this.
It does - please try on a BIOS system for reference. What you see is another problem with similar symptom but a different solution. Please create another bug report.
I guess the problem is that the hardcoded grubx64.efi looks for unifont in the wrong place ... or that the extra unifont is placed in the wrong place.
I was wrong. Sorry for confusion. The "loadfont" part is irrelevant.
terminal-font: is missing in my /boot/grub2/themes/system/theme.txt. It is present in grub2-tools. I will check if anaconda missed something.
There is a definite problem with the font in grub2 in F18.
I don't like the fact the Font size/style changes when you arrow over each option. I don't think its the size per say, as it is, the spacing between letters is too big.
being a visually impaired user of Fedora, I like the bigger size of letters, but I agree with the rest of the comments except to say, its not the size of the print so much as the spacing between characters, and that, the font spacing definitely changes when you arrow thru each menuentry. I agree that has to be smaller, but at same time, large enough to be readable. I'm sure I'm not the only one saying its annoying the font spacing changes when arrowing thru each menuentry, even for someone like me who is extremely sight impaired its annoying.