Ubuntu Mono is too small

[Carlos Pita]

EDIT: I don't believe this is as strongly related to px sizes or hidpi as I first suggested, but a more general issue.

Many applications expect the user to configure font sizes in px units. For example, PyCharm, VSCode. In a hidpi screen (3000x2000) using 2x scaling factor, Ubuntu Mono looks considerably smaller than other popular monospaced fonts at the same px size. This is not only a problem of setting a different pixel size when one wants to use Ubuntu Mono but a much worse issue: complex applications often use heuristics to set font sizes of different elements of the GUI according to the base size set for the main font and having to scale Ubuntu Mono to px sizes larger than the usual ones distorts the size of other GUI elements to the point of ugliness or even unusability.

For example: https://github.com/microsoft/vscode/issues/88916, but I have many similar problems with PyCharm also.

[Carlos Pita (carlosjosepita)]

Here is a similar report:

https://askubuntu.com/questions/800424/why-are-ubuntu-mono-letters-so-small

I would like to understand why Ubuntu Mono behaves differently than other fonts in this regard.

[Carlos Pita (carlosjosepita)]

Another example: dbeaver. If one sets the base monospaced font to Ubuntu Mono 13 and then a non-monospaced font for the grid results (as it's the default) with an equivalent size of 11 (say DejaVu Sans 11), then the text-only version of the grid results is rendered with Ubuntu Mono 11 (the 11 being taken from the grid font size).

Anyway, this is the general pattern: apps tend to infer font sizes from other font sizes and Ubuntu Mono is wreaking havoc with their assumptions in many, many places, because its actual size is very different from other fonts at the same nominal size. Something has to be done upstream.

[Matthew Paul Thomas (mpt)]

I made the attached comparison when I first noticed this issue in November 2011. Unfortunately, I don’t think it can be fixed without redesigning the font. There are two factors involved.

First, the “x-height” — that is, the height of an “x” and most lower-case letters — in Ubuntu Mono is about 47% of the total height. That is about the same as Courier, for example, but it’s less than most other monospace fonts, especially those used for coding. (It’s also less than the x-height of the proportional Ubuntu font.)

Second, the width of Ubuntu Mono characters is substantially less than most other monospace fonts.

Those two factors combine to make the font look much smaller than most other monospace fonts at the same pixel height. Which, in turn, means that you need to use a larger size to achieve the same level of legibility.

(The attached comparison shows fonts with hinting turned on. With hinting turned off, fonts may look slightly larger or smaller at particular sizes than they do here, since their x-heights and widths aren’t being rounded up or down to the nearest pixel. But overall the issues are the same.)

[Carlos Pita (carlosjosepita)]

Thank you for the detailed explanation, Matthew.

Isn't it possible to produce a new font with a modified descriptor so that it's seen from outside as having a size that better matches other fonts (and expectations)? Sorry if the question doesn't even makse sense but I'm far from being an expert in the area. It's only that it seems to me like a nominal issue and, moreover, it's relatively clear what size to map the font in order to make it better interoperate with other families. I even tried to transform the size using a fontconfig rule, but the apps I'm trying to get working with Ubuntu Mono are not using fontconfig :(

[Paul Sladen (sladen)]

It's an imperfect solution, but likely no *perfect* solution is possible;

* Historically typewriters/lineprinters/paperfoms were 10 CPI or 12 CPI (characters per inch); pick one—neither is "wrong";
* Cell-ratio of 1:2 ratio (eg. 8x16 pixels) so text-mode box-drawing
* Cell-ratio of 1:2 ratio so double-width CJK character cells are square
* default sizing such that Ubuntu Mono and Ubuntu Regular have roughly the same overall advance
* default sizing such that Ubuntu Mono baseline is slightly below Ubuntu Regular at the same nominal font-size, so that documentation works better.
* default sizing such that Ubuntu Mono does not increase base-line spacing (but is still 2:1 and, and, and, …)

As originally designed, there was a 1:1 relationship between many of the characters; such that the lower-case Latin characters "abcdeghk23456789nopquvxyz" were practically identical:

* https://www.youtube.com/watch?v=DdfLtTIpFWo&t=6m (see, slide... blast from the past)

and the shrinkage was applied later to try and make some of the other constraints work.

[Matthew Paul Thomas (mpt)]

Interesting. So if I understand that correctly, the design of Ubuntu Mono was aimed more at similarity with the equivalent proportional font — and, therefore, aimed less at legibility at small sizes — than, say, the design of Fira Mono or DejaVu Sans Mono. Which is quite a reasonable choice in isolation. But now IDE UIs are being laid out based on monospace fonts that look larger, and Ubuntu Mono is too different from those to work well at the same size.

“Isn't it possible to produce a new font with a modified descriptor so that it's seen from outside as having a size that better matches other fonts (and expectations)?”

Font coordinates are all relative, so a font can’t claim to be a different size than it really is; it gets scaled to whatever size the app wants. What *could* be possible (and Paul, not to mention Dalton Maag, would probably shudder at the suggestion!) is to scale up each glyph inside the font, simply by multiplying all the point coordinates by, say, 1.2. But that would have two drawbacks:

* Some of the glyphs would end up overflowing the top/bottom of the space available — for example, accents for capital letters ÀÁÂÃÄÅ, or descenders gjpqy, or both. Accents are stored as separate glyphs, so those could be special-cased to avoid overflow by multiplying their height less than their width (or not at all) — but then the bottom of the accents would start scraping the top of the taller capitals underneath.

* The whole font would end up looking a bit bolder than it does now. That might not matter at small sizes in a code editor. But it would mean that Ubuntu Mono was bolder than Ubuntu Regular at the same size. It might also introduce problems with hinting.

A much simpler solution is just to use a different font. If most apps using the OS’s default monospace font expect it to look larger than Ubuntu Mono does, perhaps we should (gasp) change Ubuntu’s default monospace font.

[Carlos Pita (carlosjosepita)]

> perhaps we should (gasp) change Ubuntu’s default monospace font.

Please no, I love Ubuntu Mono. Except that you mean to provide a
different versión of Ubuntu Mono, with "fixed" size, under a different
variation of the family.

Moreover, I don't think that changing the default to a different font
will be a solution because the problem is not that these tools are
ill-configured out of the box because they adopt the platform default
monospace font by default, which they don't, but that if you like
Ubuntu Mono the most, then you are out of luck.

[Matthew Paul Thomas (mpt)]

Carlos, did you start experiencing this problem in PyCharm before or after v2019.3? That’s when they adopted the JetBrains Mono font, which has an x-height of 55%.

Meanwhile it turns out that the x-height for Ubuntu Mono is 46.5%. <https://www.brunildo.org/test/xheight.pl?family=Ubuntu+Mono>

Since (as that site demonstrates) a font’s x-height can be determined in code, and that’s the primary factor in how big the font looks, you might suggest to the PyCharm and VS Code developers that they scale their UI by the font’s x-height rather than by its total height.

[Carlos Pita (carlosjosepita)]

Before v2019.3.

I filed issues at DBeaver, VSCode and PyCharm trackers. VSCode promptly closed it, as I expected they to do. I suspect the other two issues will simply rotten at their respective trackers. I did my work even if I don't believe that a case-by-case solution will do it here.

[Paul Sladen (sladen)]

Carlos: please could you share the links the bugs; these will help other people join everything together and/or follow up.

[Péter Prőhle (prohlep)]

A related annoying feature, that say Ubuntu Mono Regular 24 has only a very loose connection to the actual height of the font and to the distance of baselines of adjacent lines in a terminal, ... these are in this special case 27 and 33 respectively, 9/8 and 11/8 times the nominal 24. --- while usually the most important question is how many lines fit into a given height of the area we have for displaying lines of letters. I.e.: 24 has nothing to do with this fundamental question, while either 27 or 33 has much more relation to this fundamental question.

Is it guaranteed that given a font of any kind of nominal size X, the actual height will be X*9/8 ? Obviusely not, and this is annoying.

More precisely, making the question independent of the output device: is it guaranteed, that any two given fonts of the same nominal size have the same height?

Even a weaker request what seems to be not satisfied by the typographers: is there ANY property of the fonts, for what it is guaranteed, that any two given fonts of the same nominal size they share exactly the same value of the property in question?

Obviusely not.

Hence I suggest to cancel this bug report, since the typography itself is not a mathematically precise topic, and hence the original question is not a bug, only a human complain concerning the nature of typography.

[Matthew Paul Thomas (mpt)]

The answer to the last question is “Yes, that’s the reason Arial exists”. However, nobody here is advocating “exactly the same value” for anything. Just that it be big *enough* for expected use cases.

[Domizio Demichelis (domizio)]

It's not a problem of being smaller than other fonts of its same size... it's a problem of being smaller than its own non-mono variants of the same size!

For example, try to use Ubuntu in a an app that can only set one general font size. You will get either huge text size with normal code size or normal text size with unreadable small code size on the same page! That is annoying at best!

It's terribly inconsistent with itself!

[Adolfo Jayme Barrientos (fitojb)]

See also: https://github.com/daltonmaag/ubuntu/issues/73

[Adolfo Jayme Barrientos (fitojb)]

Fixed last year