[nc] Wasteful line spacing in Ubuntu(Beta) Mono

Bug #800055 reported by smlx on 2011-06-21
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu Font Family

Bug Description

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?

smlx (sml) wrote :
Paul Sladen (sladen) wrote :

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/ascenders within the design square
  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:


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

smlx (sml) wrote :

Hi Paul,

Thanks for the detailed reply and explanation - I have to admit that I'm not familiar with the details of font design. That PDF is very interesting. Of course, I hadn't considered accented letters being a coder and native english speaker.

I note that bug #72773 has been marked as 'Fix Released'. Does that mean that the decision on glyph scaling and line spacing has already been taken? It looks like others in that bug discussion, including Mark S, prefer the larger line spacing at the expense of smaller glyph sizes as it better matches the proportional font, and looks better for the web.

If there is some way to incorporate the denser line spacing I think it would be great for us hackers with lower resolutions. Perhaps by tweaking the way the font scales at fractions of a whole point? I saw the suggestion that an additional "programming" variant of Ubuntu Mono with a denser line spacing is a possibility.. something like that would be very welcome. I think it's possible without losing readability - Consolas and Liberation Mono both manage it.

Anyway, feel free to make this a duplicate of the other bug. And I hope the final decision on scaling is still open to debate. :-)

I totally understand @sml. Ubuntu mono indeed wastes the vertical space. Luckily there is linespace option in gvim but it's only gvim. You cannot affect line spacing in any other text editor so I would like to see the font version with less vertical spacing.

P.S. @sml, see my attachment

summary: - Wasteful line spacing in Ubuntu(Beta) Mono
+ [nc] Wasteful line spacing in Ubuntu(Beta) Mono
Changed in ubuntu-font-family:
importance: Undecided → Medium

The over-line-spacing is also a problem with vertical line-drawing characters as it prevents boxes appearing correctly, which is a shame. (Ubuntu Mono is otherwise IMO much the best font for console applications.)

Paul Sladen (sladen) wrote :

Hello Dominic. How did you generate this screenshot? What OS, what console, what font version?

Ubuntu Mono should not have any extraneous spacing between lines, and should be an exact 1:2 ratio (width:height).

Hi Paul, thanks for your swift reply.

I am using Putty 0.67 and specifying Ubuntu Mono 12-point (under Window/Appearance) as the font. Putty is running in Windows 10 and the remote machine which it is accessing via ssh is running Ubuntu 16.04. The program that produced the screenshot is called 'dialog' - it is a way of using text windows in a linux console:

$ echo "50" | dialog --gauge "Please wait\nand some more" 7 70 0

A similar screen shot using Deja Vu Sans Mono looks like the attachment hereto - the box is perfect but I have to say the font isn't a patch on Ubuntu Mono ;-)

If you want to reproduce this, you may also need to change the Putty setting at Window/Colours to 'Indicate bolded text by changing: The colour'. I also have Windows/Translation Remote Character Set at UTF-8 and 'Handing of line drawing points' as 'Use Unicode line drawing code points', these may or may not make a difference.

I suspect the problem is connected with the fact that I have to use 12-point Ubuntu Mono to get approximately the same size onscreen as 10-point for other fixed fonts. In any case 12-point Ubuntu Mono looks vastly better than smaller point sizes of the same font, for some reason.

Really all we need is a slightly taller vertical line in Ubuntu Mono font, but I realise this may not be possible.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers