I have been testing UbuntuBeta Mono as a coding font in Konsole with vim. I've been very impressed and very much like the way this font is progressing. I usually use a font size of ~10 and my previous favourite fonts before Ubuntu Mono were Consolas and Liberation Mono.
At font size 10.1, the glyphs are approximately the same size in Ubuntu Mono and Consolas. However, in Ubuntu Mono there is an extra pixel between the lines. This means that less lines of code can be displayed on the screen at one time. (see screenshot 1, Consolas on left and Ubuntu Mono on right)
Reducing the Ubuntu Mono font size to 9.9 sets the same line height as Consolas, but the glyphs have been shrunk rather than the line spacing, making them much more difficult to read (see screenshot 2, Consolas on left and Ubuntu Mono on right).
I would like to see the option of retaining the glyph size of 10.1 at the line height of 9.9 in Ubuntu Mono (perhaps at size 10?). I think this is an important issue, because when coding (presumably the activity this font is aimed at) I want to see as much code as possible on the screen to make best use of screen real estate. For what it's worth, Liberation Mono behaves the same way as Consolas (larger glyphs, less line spacing).
Would it be possible to get Ubuntu Mono to behave like Consolas and Liberation Mono with regard to line spacing?
Hello Scott! It's good to find that you've found a workaround by toggling the nominal point size up and down in fractions of a whole point to get roughly the effect that you're after. It should also be possible adjust the line-spacing using FontConfig, but because Monospace have a cell-structure they're really designed to be drawn touching (not overlapping) so that the box-/line-drawing characters touch (indeed this is how we've been testing that the rendering is correct under various terminals).
When it comes to rendering fonts, what actually matters is the pixels-per-em (PPEM, how many *pixels* are available to draw the outline into). The relationship between the PPEM and point size depends on the DPI (resolution) of the screen:
PPEM = Point Size * 96 DPI / 72 point
frequently the default "DPI" of 96 is left configured because changing it breaks so many current applications. In this case, it is a simple 3:4 ratio; 9 point == 12 ppem; 6 point == 8 ppem. What's probably happening the scale of 10 point (13.33 ppem) is that the spacing is either getting rounded up, or down as your change the fractional part and then likely the vertical-only autohinter ("slight hinting") is taking over and also rounding up and down.
The main final question was during the early alpha process was bug #727733 ("Technical: Mono: discern level of scaling to fit in terminal cell"), was the one that has taken longest to try and find an answer to and I think covers many of the topics that you've raised above. The current solution being tested in the beta is 500×1000, with the x-height being about half of that. This gives:
1. a slight differentiation in x-height with the proportional Ubuntu
2. all vertical accents and descenders/
3. sufficient vertical separation between '[]' on consecutive lines
4. no overall between accents and descenders (eg. '
5. 2:1 ratio (same as Inconsolata) allowing bitmap 8×16 use on the VGA terminal/consoles.
One of the attachments on the existing bug report also shows the various impacts on line-spacing that the scalings produced:
https:/
On the left-hand side of this PDF as line-counts which also show how 'gjĂ' overlap, and also behaving of touching non-touching pairs of '[]'. The one currently tried is in the middle. Less ambiguity at only a very slightly line-count cost compared to the much denser version. Would you I mind if I make this as a duplicate of bug #727733 above, and we continue the discussion there? (I think it would be useful to keep discussion mainly in the one place).