------------------------------------------------------------------------------- Finding a Fixed Width Unicode Font for Terminals The follow are my own personal notes on finding a good fixed width font for use in Terminal Windows, such as Linux XTerms, or in Putty on Windows 10. This is not easy, especially for fonts that use a lot of double-wide characters with few terminal programs handle well. ------------------------------------------------------------------------------- Standard X Window 'Misc' or 'Fixed' Unicode Font... A good range of unicode blocks encoded is, the Unicode "Misc Fixed" Fonts. However these bitmap fonts were designed with older lower resolution displays where individual pixels were more pronounced. As you get a whole slew of size in the 6 to 8 pixel widths, but very few at larger pixel sizes, basically you are stuck with 9x15 (reasonable), or 10x20 (very high an aspect ratio). Big thanks to Markus Kuhn, who pioneered and did most of the early work to achieve such a great effort! 9x15 font is probably the most complete fixed width Unicode font, sized for a modern display... FONT="-misc-fixed-medium-r-*-*-15-*-75-75-c-90-iso10646-1" BFONT="-misc-fixed-bold-r-*-*-15-*-75-75-c-90-iso10646-1" I set Xresources to... XtDefaultFont: -misc-fixed-bold-r-*-*-15-*-75-75-c-90-iso10646-1 XTerm*font: -misc-fixed-medium-r-*-*-15-*-75-75-c-90-iso10646-1 XTerm*boldFont: -misc-fixed-bold-r-*-*-15-*-75-75-c-90-iso10646-1 This Font includes Glyphs for... Arrows U+2190 Mathematical U+2200 Technical U+2300 Miscellaneous U+2400 Graphics U+2500 Miscellaneous Symbols U+2600 Dingbats U+2700 Braille U+2800 There are some minor mistakes... * The most glaring is "Dentistry Symbol Light Vertical and Bottom Left" Which should show a bottom left corner '⏌' but instead is a copy of the top right corner '⎾' This character is correct in the Misc "8x13" and "10x20" Unicode fonts. * Another is "Box Drawings Up Light and Left Down Heavy" '┪' and "Box Drawings Down Light and Left Up Heavy" '┩' which do not quite match up with other similar 'mixed heavy & light' box drawing characters. The 'light' lines of the character should join with "Box Drawings Light Vertical" '│' but is of by one pixel to the right. It is correct in "8x13" and "10x20" Unicode fonts. * "Vertical Line Extension" \u23d0 '⏐' is simply not defined! A glaring omission. * The font could also use other glyphs additions. Such as those found in the Arrows Supplement-B block (\u2900 to \u297f) and in other areas. * Bold "9x15" is missing many symbol glyphs, and because of this you should not display unicode in bold mode. Other than these mistakes, the "9x15 Unicode" font it is one of the BEST Unicode glyph renderings, I have seen. (Including most GTK fonts I looked at!) It is especially great with the vertical alignment between box and other characters, like arrows. Almost every other font rendering fails badly here. Some symbols are quite small relative to the character bounds. Morphological circle symbols for example are almost impossible to distinguish between each other on the modern displays because they render so small. But compared to most fonts this are extremely minor faults. I have found it the best font for use in XTerms, and yet to find a replacement (at perhaps a slightly larger size for the newer HDMI displays. --- While the 9x15 implements practically a complete Unicode glyph set, others do not. Almost every other X-Window font is generally incomplete with regards to Unicode symbols such as: Graphic, Dingbat, and Mathematical Unicode Glyphs. Even the simplest and most basic "Bullet" '•' glyph is often missing. Many of the other fonts don't even provide a visible 'undefined' glyph, leaving the character 'blank', so you can not see that it is a missing glyph rather than a space. That includes the "9x15bold", "10x20", and "8x13" Unicode fonts. --- Misc 10x20 font... XTerm*font: -misc-fixed-medium-r-*-*-20-*-75-75-c-100-iso10646-1 XTerm*boldFont: -misc-fixed-bold-r-*-*-20-*-75-75-c-100-iso10646-1 The 10x20 does implement some non-alphabet Unicode glyphs (even in its bold variant). Box characters are completely correct, and even has braille, but it is not quite as complete a set of gylphs compared to the "misc 9x15" font (above). The aspect ratio I also find disturbing. Its symbols (like morphology symbols) while clearer are still smaller that they should be. You may be better going to "DejaVu Sans Mono-12" (see below). ------------------------------------------------------------------------------- True type fonts (or Outline Scalable fonts) While they implement a larger range of glyphs, including he latest emoji. But they mostly suffer when you simply want a fixed-width font that really is FIXED-WIDTH! That is a font for use as a terminal. The Graphics and Mathematical Blocks for example often do not work with character extensions across multiple lines. You often only have to look at Extended Braces, to see the font and application using it, failing badly, with symbol characters not lining up properly. What is worse, just about every true type font implements Braille Space as a set of 8 open circles (except Terminus), and the other with filled in circles. All these circles means make reading or even using braille much harder, and basically impossible. Regular Braille only consists of 6 dots, not 8, so being presented with 8 open circles also makes it more confusing. The other bug is every single true type font miss implements "Extended Square Root Base" ('⎷'). They implement it more like a normal square root ('√'), so it does not join up with it counterpart "Square Root Extension". They also do not ensure double height summation (like '∑') joins up vertically. Actually almost all of them fail in some way for any of the Extended Bracket Characters in U+2300 code block. In summery.. • Braille space ('⠀') is not blank but 8 open circles. • Extended Square Root Base ('⎷') does not join vertical line • Double height summation ('⎲' and '⎳') do not connect to make a '∑' Add to that many applications often leave gaps between characters or between lines, making characters 'fuzzy' from over use of scaling and anti-aliasing in the rendering, or not implementing the combining proprieties for the Unicode block "Combining Diacritical Marks for Symbols U+20D0 - U+20FF" correctly. One thing that really annoys me is how many terminal programs using true type fonts replace specific characters with large color 'emoji' variants, even when it is not warranted. For example Example... "double headed arrow" '↔' is a math symbol. But some terminal programs and web browsers will prefer to use the emoji variant! That means some mathematical formulas simply do not render as it was originally intended. (See U+FE0E to indicate/force text rendering, if this is understood!) --- Noto Sans Mono (large number of styles) A complete font that at first glance seems to work correctly, with the exception of extra intra-line spacing (seen in gedit). This implements practically all standard Unicode. Problems seen... • Extra intra-line gaps between lines • In GEdit, braile and ideographic dot '。' at the start of a line causes the leading spaces to 'disappear'! • Box Graphic horizontal mismatch between thin-thick lines '╃╀╄ ┟┲┱┧ It is like they could not decide where the 'center' is but only in even point sizes, like 12, 14, and 16, but connects up fine in 11 point • The "combining enclosing circle" diacritical '•⃝' fails • Part circle symbles are still very small '●◐◑◒◓◔◕◖◗' I have not seen the font work in XTerms as yet... xterm -u8 -fa "Noto Sans Mono Medium-9" xterm -xrm 'XTerm*faceName: Noto Sans Mono Medium-9' --- DejaVu Sans Mono On my Fedora Linux machine this is also known as the GTK "Monospace" Font! This was also the ONLY font that I found in the default font list for "Putty" under Windows 10, that has even a semblance of a good set of glyphs, and its practically complete. This implements practically all standard Unicode (not emoji), and Box Graphics actually WORK! Even many of the symbols I have found larger and clearer than those in the "Misc Fixed" font. Using in Xterms... xterm -u8 -fa "DejaVu Sans Mono Book-12" xterm -xrm 'XTerm*faceName: DejaVu Sans Mono Book-12' This implements 10x19 font, (almost the same size as Misc 10x20) The only problems I have see (in xterms) is... • ASCII "hypen-minus" '-' is very very small, more like a centered dot! • The "horizontal line extension" '⎯' is more like a underline! • The "combining enclosing square" diacritical '•⃞' only shows the right half • The "combining enclosing circle" diacritical '•⃝' is too small. • The right side of '〿' gets truncated • Morphology circle symbols (and faces) are again on small side • In XTerms braille space is '8 open circles' This is on top of the problems seen in almost true type fonts... It also has sizes that fit well on today's higher resolution displays, where most "Misc Fixed" fonts are designed for lower resolution. Morphological symbols for example render very well and clear. --- FreeMono Looks to be just about the perfect fixed width unicode font. Its Box Drawing glyphs, and extended brackets are all perfectly aligned. And it gets the diacriticals (combined characters) right (but not in xterms). Double height summation, and even the Square Root Extension actually work! However it only seems to work properly with black-on-white text. With white-on-black, the text seems very dim and grey. And the brightness of joining box characters varies greatly, especially vertically with a bright line connecting to a dimmer line. It's grey 'hash' patterns are again correct for black-on-white, though the pattern could be better. Central greys become swapped on white-on-black displays. ON a GTK application, or Web Browser, characters usually join together perfectly, Especially at an 11 point size. But in a XTerm a single pixel gap is present between almost all joining characters, in both columns and rows, making it far from ideal for normal use. I recommend it for Web browsers (Chrome, Brave, Firefox, etc) and GTK editors like gedit, but not for XTerms, and only for black-on-white. --- Terminus Works well, though I find it hard on the eyes. Especially its lowercase-'g'. Some of the sizes also result in gaps between lines. What it does has going for it is that "Terminus-12" is exactly 10x16 pixels! A good size to scale up to if you need something bigger than misc 9x15. The most annoying aspect is that in the right most edge of many glyphs are missing. The 'right 1/8 block' ('▕') for example is blank. NOTE: The font of this same name in Windows (Putty) is NOT a good Unicode font at all. ------------------------------------------------------------------------------- GNU UniFont Project One other font I'd like to mention is the GNU Project "unifont". http://unifoundry.com/unifont/index.html This implements a 8x16 bitmap font with the aim to be the most complete unicode font implementation out there, and in this it succeeds. It is a practically perfect unicode font, with definitions for ALL symbols. Though its current rendering of braille has single pixels for 'no dot'. However using the X windows BDF and PCF version of the font with "xterm" is having some rendering problems with its Box Drawing Glyphs, (U+2500). All the single line box chars are being rendered as double width, but with single width spacing, meaning they do not work properly, especially with the 'heavy' or 'double' box chars, which do render correctly as a single-width character. I have a Bug Report about this as it is still in active development. But they don't know why those gyphs are thought to be double-wide, nor can I find any reason in the font source BDF file. The truetype font (ttf) works perfectly with a complete (non-emoji) unicode. Except for Except for '⟙' and '⟘' whcih may be rendering as emoji equivelents, However when I used "UniFont-12" with "xterm" the xterm sets all the characters to be double-width. -------------------------------------------------------------------------------