Ubuntu Font Family

Bug #800055
Comment #2

Comment 2 for bug 800055

Revision history for this message

Paul Sladen (sladen) wrote on 2011-06-21: Re: Wasteful line spacing in Ubuntu(Beta) Mono

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:

https://bugs.launchpad.net/ubuntu-font-family/+bug/727733/+attachment/1893352/+files/ubuntu-mono-nominal-size-r17-r21.pdf

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

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:

One of the attachments on the existing bug report also shows the various impacts on line-spacing that the scalings produced:

https://bugs.launchpad.net/ubuntu-font-family/+bug/727733/+attachment/1893352/+files/ubuntu-mono-nominal-size-r17-r21.pdf

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