November 18th, 2010 byIn contrast to a proportionally spaced font a the characters in a monospace occupy all exactly the same width. In the past monospace type was used on typewriters, and more recently in some specialised printing environments such as Credit Card embossing, or ticketing. Today, monospace fonts are primarily used within a programming environment working on terminal windows. The monospace font answers the need for clear code structuring and predictable line lengths. Using monospace fonts allows the programmer to immediately spot a mis-typed character or double space, any of which would prevent the code from compiling as expected.
The new Ubuntu Mono in a code enironment.
Courier is probably one of the most widely recognised monospace fonts, available on many computers. Its pitch sits at 12 glyphs per inch, set at 12 point. Based on an em-square of 1,000 units this is equal to 600 font units. As Courier is widely used it must be considered as a baseline for new monospace designs.
When starting the work on Ubuntu Mono we soon felt that we could narrow the pitch and thus increase the character count per line without compromising legibility. Only a few other monospace fonts have departed from the Courier pitch, amongst them Consolas available in the latest Clear Type collection from Microsoft. We carried out numerous trials to establish the right pitch width for Ubuntu Mono and arrived at 560 unit width. The narrower pitch also helped with spacing of the font as many characters tend to have too much space on the left and right, locking the lowercases together for enhanced legibility. Naturally, the narrower width does create a conundrum on some wide characters such as ‘m’ and ‘w’ but we are confident to have found an acceptable compromise.
Comparing Ubuntu Mono Regular with Courier
Of course, as the font weight gets bolder the narrower width does create a number of design challanges, even more so with the critical characters mentioned above. But the tighter density of the type allows the type designer to compensate by reducing the stroke width of the characters compared to the proportionally spaced font, without deacreasing colour texture, or contrast against the Regular. The biggest difference between creating a proportional font and a monospace is that a proportional design allows the designer to draw the glyph in harmony within itself and agains the other glyphs. A monospace design is dictated by the width and side-bearings (space to left and right of glyph) leaving the designer challanged to find creative solutions to maintain harmony.
A number of alternative designs to solve the problem of the ‘m’-density. Sometimes we just have to live with a compromise.
The monospaced fonts are planned to be part of the next Ubuntu release in Spring 2011 after being exposed to extensive testing. This is to ensure that they meet as many needs as possible, and being aware that it will be used primarily within a coding environment our emphasis will be to create it with this user group in mind.
The challanges of placing the bold style onto the fixed narrow pitch
The dot within the zero helps to distinguish this glyph agains both the O and Danish Oslash.
The toolkit
85 Responseshide comments
Great work!!
PPA please
+1
Luís: You’re welcome to join the ubuntu-typeface-interest team. You’ll then receive instructions for activating a personalised PPA with access to the UbuntuBeta Mono fonts.
Excellent work and fantastically informative post as always.
The monospace is looking divine.
Thanks for the informative update. The font looks terrific. I am looking forward to testing it with my terminal and editor to see how it works.
Hi Bruno, the font looks great!
I wonder if it would be worthy to compare it with Inconsolata (http://www.levien.com/type/myfonts/inconsolata.html), which is for many the best font for coding. From what I have seen, the weight looks slightly different.
Well done, chr
Christian: In the end the choice was made to use the same 500×1000 design and 2:1 ratio that Inconsolata uses. The weight of the UbuntuBeta Mono is very slightly heavier than Inconsolata—hopefully balanced by reduced or absent serifs and stem extensions on the letters
"bdgilmpru".Well done. This monospace looks very nice, readable and usable!
Still, I do have a quibble: the lowercase “r” looks a little less readable than the other letters: I have the feeling that the stem is too much in the middle, which makes the curve too undersized compared to the leftwards serifs (or the serifs too important compared to the curve).
Adhemar: Good feedback, thank you. The lowercase ‘
r‘ has been re-designed, removing and the serif shown in the examples above and just using an extended simple, open curve much closer to the proportional Ubuntu Font Family members.Looks good…
My personal favorite is the one called “Monospaced” on my Ubuntu machine (not sure that is the real name though…).
The main reason for using that font, is that it is fully Unicode and supports all the alphabets I’ve had to work with so far…(Arabic, Hebrew, Chinese, Hindi, Japanese etc.)
Thus the question is… Will this new font support all these as well ?
The “Monospace” alias is currently provided by Bitstream Vera Sans Mono, progressively falling back to DejaVu Sans Mono, Liberation Mono, Inconsolata, Free Mono and others to get the maximum coverage possible. You can investigate how this mapping is done (it varies for different Unicode ranges) by looking in the files matched by:
grep 'monospace' /etc/fonts/conf.d/*The same substitution mechanism should occur when the Ubuntu(Beta) Mono is selected, meaning that any missing glyphs (ones that are not yet included) will fallback and be rendered by other fonts, continuing to work just as they are at the moment.
I just noticed that the official ttf-ubuntu-font-family package has replaced ubuntu-private-fonts. Will ubuntu-private-fonts still be used for testing? Right now, which package has the most recent version of the font? It tells me that if I install it, it will remove ttf-ubuntu-font-family (which is recommended by ubuntu-desktop).
Yann,
ttf-ubuntu-font-familyis the current version, and the only version that you should have installed (it replaces the temporary-privateversions. The fonts in this package (there is no monospace included yet) are considered part of Ubuntu (the operating system desktop) and without the font is incomplete which is why the message appears.Yes I understand that `ttf-ubuntu-font-family` is the current (stable) version, but when there will be beta testing of the mono font, will it be in the `ubuntu-private-fonts` package?
It hasn’t yet been decided, but I don’t think that “private” will be after of the name. A lot of the issue depends on whether people will need to install both the latest stable and latest beta versions at the same time, and if this is the case the packages will have to have different names. The
.ttffile themselves will probably have their internal names set to “UbuntuBeta” so nobody selects them by accident. Your input and ideas for how to handle this is welcomed.Yann: The beta team are currently testing UbuntuBeta Mono 0.3. This provides a slightly newer version of
ttf-ubuntu-font-familywith the extra test fonts in. It’s available now to those that have signed up to the beta.Thanks for your replies. I’m using it now by default, and it’s nice. But I find the “i” and “m” much better on the first screenshot than on this first beta.
How will beta testing be done? Will it be Ubuntu members only, like for the other beta test?
Dieki: the phased beta test is open to anyone with an interest and who takes the time to join the phased beta group and add the special personalised PPA (not just Ubuntu Members!): the instructions are at wiki.ubuntu.com/Ubuntu Font Family#Howto. Note that there is currently (2010-11-18) nothing to beta test, as the latest released version is already in Ubuntu 10.10 by default!). The screenshot shown above is still in-progress.
The lowercase ‘m’ looks kinda crowded, but it looks good otherwise.
Colin: Which m looks crowded? (There are eight (8) variations shown, because of the difficulty with this character in particular). Of those eight, which do you think look best, or better, or worse?
The top of the ‘m’ certainly needs to be different from the ‘n’. So I prefer the one used now, or the last ‘m’ from the list, with the shorter leg. The last one might help against overcrowding.
sanderd17: Thank you for the feedback about the ‘m‘. Indeed, the ‘m‘ with the shorter middle stem seems to help with opening the letter up and making it appear less solid. The UbuntuBeta Mono 0.3 presently under test now has that version as the default.
I’ve been developing software exclusively in a Ubuntu environment for several years, and look forward to a solid monospace font.
(BTW, consider posting your sample images as PNG, since JPEG leaves compression artifacts, which are distracting when trying to see the minutia of font details.)
Thanks for the png tip. I freely admit that to me one format is like the other and that I don’t know much about the technical stuff in image files.
JPEG is good for pictures and uses lossy compression (creates artifacts).
PNG is good for graphics like those above and uses losless compression (creates no artifacts.)
The basic rule is:
For pictures taken from the “real world” => JPEG.
For everything else => PNG.
Personally, I find the second-to-last ‘m’ glyph (the one with the shortened middle leg) to be the best.
I agree.
Zarggg and Austin: could you each just clarify, do you mean the ‘m’ with the thin centre stem (second-to-last), or the ‘m’ with the short centre stem (last).
Personally, I find the one with the short middle stem (second from the right) to be the least crowded looking.
Of all of the m characters, I find the short middle stem ones to look the least tall, thin, and crowded.
Mind you, I’d have to see these during testing at a couple of point sizes. Most programmers I know use between 8 and 10 points for coding.
Personally, I use 8 point fonts for coding.
The ‘m’ with the thin centre stem (second-to-last) looks best. The ones with a short centre stem look odd, I’ve never seen a short centre stem for an ‘m’ not capitalized.
Yes, I agree on that. If anything, the stem should be thinner, not shorter. I think that the shorter ones make it look like McDonalds font.
Yann: yes, the thin middle stem approach at small on-screen sizes gives a very good result in my eyes, I think because it manages to give an equal rhythm to the whitespace.
However, scaled up to large sizes the thin stem starts to look quite weird. If the opimisation still works at (just) the small sizes, perhaps the hinting could be left to narrow the middle stem at small sizes, rather than doing it in the glyph outline itself.
I agree, too. But I think that most of the crowded effect in the first pic (the code example) is due to the blurriness of the JPG. I think it’s not that bad, even at that size, look at the “(min + max)” line, for some reason those “m” do look good while the other ones are blurry.
yaaaaay!
Realy Great Work
I’ve always loved the ubuntu font, and was looking forward to using it for my programming purposes. Hope we get it for testing soon.
Awesome font! Just like the normal Ubuntu font really rocks. And you seem to have done the bold “m” done right, which so many monospace fonts don’t. Although i haven’t seen it in small font sizes, that’s probably the hardest to get right.
Personally, I find all the Ms to be crowded, but the last M in the line of 8 Ms looks best. However, I don’t think it looks as good as Courier New Monospace.
NoSheds, Courier New monospace was my first source of research in the development of the Ubuntu monospace. Building up the design I have greatly moved away from this reference. I am intrigued now by your statement… Would you mind to give further details why you prefer Courier Sans monospace?
Hmm, looks quite similar to M+ 1mn
http://en.wikipedia.org/wiki/M%2B_Fonts
Will this include Hebrew? If so, are there plans for when? Currently, the only general-purpose monospaced fonts I’ve found that actually include Hebrew are Courier New and FreeMono, neither of which is as appealing as what you’ve produced (and many other monospaced fonts).
David:
yes, all of the glyphs and scripts in the typeface will be present across all thirteen fonts(four of these are the Ubuntu Mono variants). Designing a typeface as big as the Ubuntu Font Family takes a long time: the variable-width Hebrew and Arabic forms are still in the design phase and need to be mostly completed first, as they are then used as the starting point for everything else (condensed, light, medium, bold and monospace).update (2011-06-06): Currently the Hebrew expansion for Ubuntu Mono would be for community expansion after the initial Dalton Maag boot-strapping is done. By that time the Hebrew for the proportional fonts should have been completed, which should provide a starting point for doing a monospace version. Would you like to try and help lead this afterwards? It’ll require finding a type-designer to work with Dalton Maag on the expansion of Ubuntu Mono to Hebrew?
David, Paul: I need to clarify this. All fonts we’re currently developing are Lat A+B Ext, Greek Poly, Cyrillic Ext. Arabic and Hebrew will for now only be in the core four fonts that were released with 10.10. This is our contractual mandate. However, we will be here to assist the community in extending these fonts in the future into all sorts of scripts.
Personally, I find the one with the short middle stem (second from the right) to be the least crowded looking.
Of all of the m characters, I find the short middle stem ones to look the least tall, thin, and crowded.
Mind you, I’d have to see these during testing at a couple of point sizes. Most programmers I know use between 8 and 10 points for coding.
Personally, I use 8 point fonts for coding so it would be nice to see a good hinting at that size.
So, when you say 8pt, can you give me an idea of the rasteriser resolution? If it’s 8ppm we can probably still do it but there will be some compromises regarding distinction of cap against x-height proportions due to the simple fact that we haven’t got enough pixels available.
I am sure, though, that Vincent will do his best to get this done.
Around our office, all of the coders are working on monitors that display 1920×1200 resolution. Right now my laptop has a 1920×1200 resolution In general, the idea is to be able to see as much source code as possible without having to scroll around.
I could live with 9 pt font, but many monospace fonts look squished at that size on my displays. Anything bigger than that defeats the purpose of having the larger resolution.
I’d be happy to supply a screen shot of what code looks like on my current setup using the default Ubuntu monospace font at a few point sizes.
The font hinting is performed based on pixels-per-em (PPEM), the relationship between PPEM and point size depends on the dots-per-inch (DPI) on the device. “Resolution” here is the density of your display, not the physical size of it.
PPEM = Point size × DPI / 72So at 72 DPI they are the same, but if the computer is configured with your monitor resolution is 96 DPI, or 120 DPI (modern smartphones have 250–300 DPI) then there are more pixels to play with and it is easier to get a better rendered form. In this case, the “resolution” that Bruno needs to know is the DPI setting selected.
Sorry for my misunderstanding. The DPI setting on my laptop and the machines around the office is 96 DPI. The DPI is not anything I have ever experimented with, so I’m assuming that is the default?
Awesome… Waiting for it to come !! Gr8 work
and as usual very informative !!
Font looks great. What is the vertical height like? For me number of lines on the screen is one of the most important factors in choosing a monospace font.
Matthew: The number of lines of the screen was hard to answer until bug #727733 (“Technical: Mono: discern level of scaling to fit in terminal cell”) had been resolved. The easiest way is to either join the beta team and find out, or get an idea by installing the
ttf-inconsolatapackage, which has the same 500×1000 final metrics.The M looks too small in comparison to other letters such I, A, and B. The middle line in it looks like it’s too much to the left, and takes too much space from the inside of the M. This isn’t all that noticeable in small type, but when I looked at the large versions of the images here it bugged me. I don’t know if it’s even possible to do a better job, but I think you should try.
yman: could you clarify, is the description of the issue about the ‘M’ (uppercase) or the ‘m’ (lowercase—and ig so, which one of the eight?).
I’ll ignore the “n” characters:
The one I dislike the most is the first from the right. The middle stem is too thick and looks like it is too far to the right, because the place where it connect to the top arc looks somehow warped. Having a higher density of black makes it look small in comparison to more spread out characters, especially those that have big ellipses.
The last ‘m’ (of the eight) tries to use the same apparent bridge shape to form both of the arches. The middle stem is actually currently off-centre (you are correct about this). If the middle (short) stem was adjusted to be truely centred, would it look better?
At the moment the lowercase ‘m’ is proving to be the hardest character so far, and any suggestions, or ideas (or even designs!) on how to improve it would be greatfully accepted.
This version of the m is actually my favourite. I like the short middle stem and I like the fact that it is off-centre a bit, so I think some of this is taste.
In the comparison picture of the monospace’s bold and regular styles, I find the m with the long stem looks crowded compared to all of the other letters. It sticks out conspicuously. It would be interesting to see the same example using an m with a short middle stem.
I think the placement of the middle stem is good. My problem with it is that it looks warped at the place where it connects to the upper arc.
I forgot to say that Ubuntu Monospace Bold looks perfectly fine to me.
Compressing the font relative to Courier is very important, but for printed/PDF books, this compression may not be enough. Ideally, one wants to be able to fit 80 characters in a code display that spans maybe 5 inches. Compressing DejaVu Sans Mono to 75% horizontally works pretty well–see http://weblogs.java.net/blog/cayhorstmann/archive/2010/11/21/condensed-monospaced-font. A Ubuntu Mono Condensed for print use would be awesome.
Cay, we’re working on a Condensed Regular as we speak. This will be proportionally spaced, though.
Cay Horstmann: The UbuntuBeta Mono 0.3 currently has 12 CPI (characters per inch), compared to 10 CPI for Courier and DejaVu Sans Mono at 12 point. Five inches should give 60 characters at 12 point, or 72 characters at 10 point so you may need to provide an additional 33% or 10% scaling on top of this to get a full 80 characters.
Would you be able to test these levels of scaling and give some further feedback about how such scaling works in a print environment?
I have really been missing a monospaced version of the ubuntu font ever since it was introduced with the 10.10 version of ubuntu.
I really like the design of most letters – as far as I can tell for now.
Some letters do however not really look very ubuntu-ish, because they have to many serifs and thus don’t look very light anymore. Especially the “l”, the “r” and the “f” look way simpler and lighter in DejaVu Sans Mono … the way the “r” looks right now it is even a little hard to read I think, because the littlebow in the upper right doesn’t look very different from the serifs in the other corners.
But other than that – great work! I’m looking forward to using the monospaced ubuntu font on a daily basis myself.
Fritz: Have you had a chance to beta-test the monospace now? In the version of UbuntuBeta Mono 0.3 now testing, the ‘r‘ has lost its serif once more and the ‘f‘ also at the bottom slab serif removed too. Both of these hopefully make the end result lighter and more open.
Is there any idea of when the monospace font will be available for testing?
George: The UbuntuBeta Mono is currently (May/June 2011) available to those who’ve joined the
ubuntu-typeface-interestteam and installed the relevant personalised PPA.I personally prefer the fourth m (the one without the little dip), but still looking great
The fourth m from the left? I like that one, but its style doesn’t match the rest of the letters in the Ubuntu font, like the n and the r.
True, it doesn’t match up as well, but all the others (besides that and the sixth from left) look to cramped in my opinion
The sixth one from the left (the one with the space in between the middle vertical bar and the main body) may lead to confusion though
The Ubuntu Hebrew font, last I’ve seen, looks like Hebrew script that is only pretending to be Hebrew print. Hebrew script is for handwriting only while Hebrew print is for almost everything else, including computer interfaces. Instead of taking the Ubuntu Latin font and modifying it to resemble Hebrew print, Hebrew print should be used as the base and then modified to resemble Ubuntu Latin.
yman: You may be interested to read the article highlighting some of the (again, very early) Intial Hebrew trials. Must understanding is that some quite major changes have now been made based on the feedback received. Perhaps it would be useful if you could add Hebrew-specific feedback to that article, or by filing a new bug report on Launchpad so that your useful suggestions don’t get accidentally lost by the wayside.
I’m surprised you’re not keeping with the design of the lowercase t and f in the proportional font, where the little crossy part (in typography newb speak) only sticks out to the right, not the left. I always liked that about the new font — why leave it out of the monospace version? Too hard to tell t from C that way, or something?
Good catch. Now I am wondering about that, too.
Luke and George: the serifs have been added to some of the thinner characters in order to help “fill out” the full width of the bounding box. Perhaps you could follow-up on bug #677134 which is specifically for recording thoughts about the style and design of the serifs on the narrow characters.
Thanks for the bug link. The “filling out” is actually a good explanation for the look of the font – the DIN monospace reference shows the problem nicely.
The reason having it in the ‘f’ is that it contains a serif along the baseline. Not crossing the ‘f’ fully would make it look rather awkward. The reason for the serif is to give the character more width, make it fill out more space. And since the ‘f’ is fully crossed it stands to reason that the ‘t’ should also. In addition, the ‘t’ needs the full crossing, again to make it occupy more of the space.
I literally can’t wait to try the mono version out!
I like the fifth M the best. If I’m not mistaken it’s very similar to the one in the proportional Ubuntu font.
That m might get confusing when mixing uppercase and lowercase letters, perhaps?
I don’t know how much our opinions matter. I have a feeling that Shuttleworth already knows what he wants.
George: Mostly the experts agree between themselves and find a solution that most people are happy with (it’s not possible to please everyone at once!). The process of alpha- and beta-testing then find out if the decision works in practice or not. When the obvious answer isn’t clear, that’s Mark involvement really comes into its own, listening to all of the input and finding a solution from it.
The more input you can bring to the table, the easier it is to have a fruitful discussion—it’s very difficult to fix or to take account of aspects or issues that have not been reported via the bug tracker or documented anywhere!
How is the mono font coming along?
For those curious, Paul Sladen gave a very helpful update on the mono font’s status in the comments for another post:
http://design.canonical.com/2011/03/quit/#comment-14207
Can’t wait for this one. One thing i don’t like is the dot in the zero. Would look better with a slash (maybe forward slash).
Vishal: I would encourage you to file it as a bug requestion. There seem to be as many people asking for a slashed-zero, as for a dotted zero. In-lieu of any other reasoning for-or-against either, a slashed-zero has the potential for confusion in Scandinavian with ‘Ø‘:
I liked the last “m” in the alternative designs. Oh, and I’d advice you to get an english spell checker in your web browser, you made a few typos there.