Triplicate has a nice look, but l (lowercase L) and 1 (one) are indistinguishable, which is an immediate non-starter for me in a programming font. (CORRECTION: there is apparently a code version that disambiguates these and others. See comments. That means this probably would be a candidate font for me, except:)

I finally just paid for Pragmata Pro, and haven't regretted it. The unicode support is incomparable, and for someone who lives in emacs and console, support for things like the Powerline glyphs and the option to use Emacs' prettify-symbols mode means an awesome user experience.

I actually like ligatures when reading code, less so when writing. The thing I like about prettify-symbols and a font like pragmata pro is that I can toggle between strict representation and a cleaned up version with things like the below replacements:

  (defun aja/pretty-symbol-push-default ()
    (push '("!="      . ?≠) prettify-symbols-alist)
    (push '("<="      . ?≤) prettify-symbols-alist)
    (push '(">="      . ?≥) prettify-symbols-alist)
    (push '("=>"      . ?⇒) prettify-symbols-alist)
    (push '("->"      . ?→) prettify-symbols-alist)
    (push '("lambda"  . ?λ)prettify-symbols-alist))

There's a code variant that disambiguates 1 and l (and others).

But it makes the code Small Caps, which I find unusable in code.

I think you’re confusing Triplicate C4 (C for Caps) with Triplicate T4’s Code variant (T for Text).

Didn't notice that. Thanks for the correction.

PragmataPro compromises readability across the board - here is why: It is compressed/condensed to allow for shorter line widths but legibility suffers.

Put up 2 exactly same code snippets side by side. One in PragmataPro and one with SF Mono (or Consolas, etc.).

I purchased PragmataPro but regret it. Now I use it on Mechanical Drawing dimensions :) It is fantastic in CAD.

I actually like the reduced width because of the way I arrange edit panes, and after a brief adjustment period, have no readability issues at the font sizes I typically use. That's a personal taste thing, though, so I can see that others wouldn't like it. The 'm' glyph is a useful bellwether/canary in that it becomes difficult to distinguish the legs before most other glyphs become problematic. I tend to adjust the font size to one level above where the m's start turning into bricks, and have no readability issues, and still ample horizontal space. I don't generally use the font for publication to others (although I'm experimenting with its use in code blocks). I do often use it in projecting demonstrations to students, although that's typically at a large font size, when the legibility isn't much of an issue, but the narrowness is an asset.

The homepage includes snippets of both the regular and code variants, and they do look pretty distinctive in the code variant.

Which weight of Pragmata Pro did you purchase and use for emacs? Just wondering if I should get all of the weights which is super pricey or I only need Essential PragmataPro Regular/Bold.

I got the full version, but the nature of my job means I can claim a significant part of the cost against my PD funds (It's mostly for books, but I already own more unread technical books than I can complete within my expected lifespan. Thankfully they opened it up to allow software.) I think just the essential would be plenty for the majority of users.

Thank you.

Personally, my eyes and brain just can't scan ligatures in code efficiently, I have to double read the code, especially "is that =, ==, or ===? Oh, and that's !=="

(edit) I'll additionally qualify my comment, from a mathematics background I can casually scan a handwritten "!=" which is the same as the ligature, but I just cannot retrain my adult brain to accept the ligature version which is the same as the handwritten one. Brain plasticity I suppose.

Seconded. I get it for math but, it's just super confusing in code. Like, most of us agree "there should be one obvious way to do it" in code. Why don't we think the same about what code looks like? That feels much more fundamental.

Obligatory digraphs/trigraphs reference: https://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C

I find some ligatures help a lot. I can often miss != but won't miss ≠ or ≢

I think the whole idea of pre-pending ! to negate is a poor idea in general, it's too hard to spot especially in long convoluted lines where it's just thrown in before a complex bracketed expression.

Even looking at what you've typed was hard for my old (!!) brain to read, especially != and !==.

It's brain training - you find "!" hard to spot, and I don't. And vice versa for ligatures. Thank goodness we both have choices!

I sometimes use a triple negation !!! for that reason. I don‘t know if there are any drawbacks, especially if there are other people working on the code, but it worked pretty well for me so far.

That might work until there's somebody who uses double negation !! for some reason. But this might only be common in JavaScript, so YMMV.

I had to google this to see why on earth you would use double negation.

Apparently it's a way to negate and convert to boolean.

Yes, it's one of those dirty JavaScript tricks that abuse type conversion. Negation converts anything into a boolean, so if you negate that again, you get the equivalent of converting the into a bool. In standard (old) JS fashion, it's both slower and less readable, but people still (used to?) do it. Similar hacks include 1* for num->string and +"" for the opposite, along with several others that I have luckily managed to forget.

I've never had to use JavaScript, but I've done the *1 or &"" in Excel to force conversion to the desired type... yes, let's mercifully lay the veil of forgetting over this.

Considering Excel's offical way of writing a != b is a<>b, I think these kinds of hacks there can be excused :)

a<>b is the preferred syntax in SQL. I'm pretty sure a!=b works everywhere these days, but that hasn't always been the case.

(eta: didn't finish the thought - I'd assume SQL influenced Excel, since it's older.)

As I'm not keeping up with recent progress of the language, how would you do that today?

If x is your variable, you can just do Boolean(x) rather than !! to make it boolean. E.g. it will convert undefined, null, 0, "", and NaN to false.

This is a much more readable cast.

Personally I think it is a good rule to never use Boolean(x), String(x), etc.

The problem is that many developers are unaware that `const s = new String(x);` creates a string Object. It looks like a string, and acts like a string, except that in some places it is not a string: for example `typeof s` returns “object”! Same problem for Boolean, Number, etcetera. Yes casts are ok, but it is easier to just say never use the value object keywords because you can end up with very wierd bugs a long way from where the value object was created.

Another example:

    let x = new Boolean(true);
    console.log(x === true);

Gives false.

Okay, thanks. And why would it be faster? Optimizing !! in the JS engine seems trivial to me.

I suppose it would be easy and might already be in some engines, but it's still discouraged because you can't rely on that optimisation (there are many engines), it's semantically incorrect, and most importantly much less readable - especially for someone not tok familiar with the JS type system.

Not for comparison, but for boolean checks I prefer to use `foo == false` instead of `!foo`, the latter is easy to overlook.

I've recently started using a kind of middle ground by putting spaces around the !. Makes it harder to miss without losing the "reads like text" property that's lost when using == false.

if ( ! isLast(e) ) reads perfectly, especially since my native language doesn't insert the "not" im the middle like english does and my brain is used to that. if (isLast(e) == false) just jolts me out of that state where code reads as fluently as text. YMMV, of course, and I have a suspicion that your native language might play a role in that...

Do all languages have `foo === false`? When testing booleans, I always do the type specific test to avoid `foo = 0 !== false` stuff

> Do all languages have ...

Of course not

This looks really nice, too bad it doesn't (and never will) support ligatures. I understand the point the author is trying to make about ligatures in the separate blog post, but boy do I love my ligatures when programming.

The blogpost makes some good points, but it's extremely selective in choosing examples to support the author's thesis.

Mainly in that it ignores many examples of orthographic ligatures that don't fit the author's narrative. A (further deep-)linked blogpost on ligatures in general states:

> Ligatures were invented to solve a practical typesetting problem. In the days of metal fonts, certain characters had features that physically collided with other characters. To fix this, font foundries cast ligatures fonts [0]

But that's not true. That is why ligatures are used by many foundries more recently, but it's not why they were invented, and it doesn't cover all traditional uses of ligatures. German and French orthography in particular contain a lot of examples that are closer to programming operators in use than the author's "fi" example.

[0] https://practicaltypography.com/ligatures.html

To me, ligatures in programming always file like a kind of syntax highlighting if that worked on the character level rather than the token level. Suppose given `difficulty = 3` your editor would highlight the `if`. That's how these ligatures feel to me.

That doesn't usually happen, though.

For example, if you type three '=' symbols in Firas Code or JetBrains Mono, you get ≡, but if you type a fourth '=' it snaps back to '===='.

I can invent some odd situations where I get a ligature in the middle of a string, but in actual coding (for me 80% JS, 10% HTML/CSS and 10% Ruby) I simply don't see any incorrect ligatures.

But most text editors don't render ligatures if the characters span token boundaries. Sublime Text at least doesn't.

How do you plan to reverse engineer the underlying keystrokes if you look at some ligature ridden code on a tutorial website?

It is nice to read. That's not the only thing we do with code. Ligatures are fine for yourself in a private setting.

It's popularity is alarming.

> How do you plan to reverse engineer the underlying keystrokes if you look at some ligature ridden code on a tutorial website?

Copy and paste it in a different font.

Well, you just have to learn all the popular ligature forms, just like you have to learn all the popular variations of letter forms (e.g. "a" and "g" both have very different variations that are popular in different typefaces).

I am not fan of ligatures because of the (although small) mental gymnastics that have to happen when reading code. It's unnecessary.

I got used to them really quickly to the point that I prefer them over regular characters. No mental gymnastics required.

Can you easily differenciate between == and === with ligatures ? That's one thing that holds me back to trying ligatures.

Yes, it’s fairly obvious. It depends on the font, but my triple comparisons actually have three bars (you can see it in the examples I think)

Of course. A `==` is two characters long, while `===` is three characters long. Also, with the font I use (Fire Code) the `===` ligature has three lines, making it even easier to distinguish.

I just had a look at Fire Code. How do you distinguish -> with ligatures from → (an Unicode arrow)?

Personally, it’s never really come up. I have no Unicode arrows in my actual source code.

On the occasion it’s in a string literal or whatever the it’s pretty obviously different, because it’s a single-width character as opposed to the double-width ligature.

The ligaturized -> is two characters wide and is pretty easy to tell apart.

So it looks like U+27F6 ⟶ rather than U+2192 →?

Sure, but in a monospaced font both of those arrows would have to fit into the same small box, so 27F6 might be the full width while 2192 would be some partial width, while a -> ligature would be two widths.

The Unicode arrow looks smaller and is positioned lower, while the ligature has the same size as -> with the dash extended into the 'arrow'. Not that I use this frequently.

The Unicode arrow is most likely throwing an error in the linter or compiler and is underlined with a red line.

For me, I just selectively use _some_ ligatures. There are a few I like (like a lambda symbol instead of `fn` in Clojure), and the rest I just don't use.

yes because === is presented as a three long parallel lines (at least in the font I use, which is JetBrains Mono)

“ligatures in programming fonts are a terrible idea”

I agree as well with the point about ligatures, but I find funny that the advice comes from a site that thinks straight up normal text with no hover, no distinct color, no distinct font and no underline is a good way to signal linked pages https://i.imgur.com/9iVMfgD.png (who would have guessed Racket was a link?)

"Ligatures in programming fonts—a misguided trend I was hoping would collapse under its own illogic."

The same could be said about so many programming conventions most people take for granted. Sometimes programmers are their own worst enemies. "just because you can doesn't mean you should" is probably the #1 rule of programming, at least for me, and ligatures definitely fit into that category.

I certainly don't blame you for not noticing the `#fbf3f3` background color on hover. However, it seems that every link is either small caps or has that trailing ° character. It looks like the former is used for internal links, and the latter for external. I agree that they're certainly not screaming, but considering that the author considers this a book, that is probably by design.

then again, the signature is indistinguishable from small cap and isn't a link

In short it’s a design choice paying homage to some other books, as well as to make the reading experience less distracting. He has a whole page explaining here, https://practicaltypography.com/how-to-use.html

It's a pretty interesting approach to the website and there's some features I never would have discovered on my own, but the author's reasoning seems pretty poor. The premise being that multi-line stretches of underlined text are difficult to read, therefore link-text (typically 1-3 words) should not be underlined.

It's also quite ironic that the author's argument against ligatures in programming fonts is that the simple substitution doesn't respect semantic difference, whilst using emphasis to signify that there is a link present

...and then he decided to put his name in small caps under the ligature article, and that one isn't a link.

I'm not a fan of symbol ligatures but what I really loathe are monospaced fonts with a single character width fi ligature so the f and the i are both half width. I've seen several websites recently using fonts that do this. It is very visually distracting, especially in code samples.

Really? So it's not monospaced? I'm having trouble imagining any monospaced font doing this.

(The ligatures in fonts such as Fira Code take up the same amount of space as the non-ligatured versions.)

On Macs, Courier (but not Courier New) can do it, though not by default.

(Open up TextEdit, enable Rich Text, select Courier, type "ff", highlight it, go to Font > Ligatures > Use All. The "ff" will now take up the width of a single character.)

I've run into a bug where certain styles of Courier Prime turns into ligatures in Google Docs. (Long story short, whether or not ligatures get enabled is a complex interplay between the OS, font, browser, and application, and not every layer always does it right.)

I'm not really sure why font designers even bother creating them in monospace in the first place though, I can't imagine any valid use for them. The only thing I can imagine is if a badly written application forces a ligature character, at least the end result will be readable rather than an empty box or something.

I can't imagine why anyone would do this either. I suppose one possibility is that some software in their web stack is converting fi to an explicit fi ligature and the monospaced font chosen by the web page doesn't support it so the browser does a substitution. When I spot another one I'll have to dig more deeply.

There's a free monospace serif-looking font called Go (made for Go, the programming language), designed by Bigelow & Holmes: https://blog.golang.org/go-fonts

I've been using Go/Go Mono as system fonts for a while, and they're one of my favorite typefaces. Their spiritual predecessors, Luxi Sans/Serif/Mono, are also worth checking out.

Go Mono is my favorite console font, alternating with Plex Mono...

I have been using that font as my main development font since it was released. Great looking font. Although I have to give an accolade to Iosevka which is easily my favourite "narrow" font.

I switched to this right after it came out - it's amazing.

Unfortunately it isn't using a usual font license. It's not really clear under what conditions you can use/redistribute it.

According to the GP's site:

> They are licensed under the same open source license as the rest of the Go project's software

Which I assume is this one: https://golang.org/LICENSE

It may not be usual, but what about the licensing terms is unclear?

It’s unclear whether I need to include a copyright for this font in every PDF I create that uses this font. SIL Open Font License explicitly doesn’t apply to documents using this font.

I'm not clear on the outcry against ligatures. This is a client-side setting and not committed to code, is that right? If so, this is like prescribing that we should use dark-mode over light-mode because I like it.

Now during the pandemic we might screenshare more often so I can disable it for that, but for development on my own time on my own screen it's nonyabizness.

People like Having Opinions About Things In Public.

For ligatures it's bikeshedding taken to absolutely ridiculous extremes. It's past prescribing night/dark mode, it's at the level of pre/proscribing colour themes in a text editor.

It is a personal choice and it doesn't affect anyone else bar me. If you don't like ligatures, I don't care, it has no bearing on whether I like ligatures (and it is a personal choice, what fonts are easier to read is always based on what I'm used to reading text in)

/rant

I disagree that it doesn’t affect anyone else. The only way it can truly not affect anyone else is if no one else knows that you use ligatures.

And dark/light is fundamentally different: it doesn’t actually change the content, just the colours. Similarly most font choices are purely presentational in effect, with the variation easily within what a normal viewer can be expected to read. (There are exceptions; for example, I’ve seen a couple of fonts go for a very old style of r in their fancy joined-writing style italics which Indians will have no trouble reading, but which has completely fallen out of use in most of the English-speaking world, certainly in Australia, and so may be difficult to read.)

But ligatures change the actual glyphs, so that your fingers must type something other than what your eyes see, and any viewer must decode the ligature’s meaning. And this is the key reason why the proliferation of ligatures in coding fonts becomes a problem for everyone.

If anyone else ever sees your screen (in person, in a screencast, or in teleconferencing with screen sharing), it has affected someone else.

At an objective level, I think it’s fairly clear that for most people in most circumstances, a light background is superior to dark, and ligatures are a bad idea. However, at a personal level, the subjective factors routinely outweigh the fairly slight objective factors.

Popularity breeds popularity. I have been exposed to ligatures in coding fonts on websites and other people’s screens. I never chose to use ligatures.

There’s an ancient philosophical question about personal freedoms in all this.

> The only way it can truly not affect anyone else is if no one else knows that you use ligatures

That covers 99.999999999% of the times ligatures are used then, that's my point.

Sure, in a situation like screensharing, using ligatures "affects someone else". A font also "affects someone else". A theme also "affects someone else". Night/dark mode also "affects someone else". That's a given. It's also something that is normally trivial to turn on or off.

And sure, very, very occasionally people use custom fonts with ligatures turned on in the CSS on websites.

> I think it’s fairly clear that for most people in most circumstances, a light background is superior to dark, and ligatures are a bad idea.

It's not clear at all. Regarding typefaces and character sets and reading comprehension, what a person is used to reading turns out to be the easiest thing for them to read (why do you use a monospaced font in your text editor?). I get that it's a fun thing to argue about because it is completely stylistic, context-sensitive and personal and has near-zero real world effects (I'm doing it now!)

> But ligatures change the actual glyphs, so that your fingers must type something other than what your eyes see, and any viewer must decode the ligature’s meaning.

As opposed to typing a collection of "actual glyphs" which the viewer must then decode back to their actual meaning via the conventions of the language? The characters available a given programming language are determined by [sensible] technical limitations, so creative use needs to be made of those to represent concepts that are already represented by single, well known characters that are not available in the PLs character set.

My beef is that talking about which fonts you like/dislike: that's a productive discussion as they're a personal thing, very often an aesthetic choice.

But banket saying "usage of this _type_ of font is bad": that's not productive in any way, it's pointless, as it ignores the huge % of people who clearly don't share this view. Saying "it's fairly clear ligatures are a bad idea": no, it's display preference, and if is forced on you, you will generally have agency to request it be changed back to something you are used to.

And this is every time coding fonts appear in HN: comment after comment stating the latter as if it's some empirical truth when it most definitely is not (and yes, similar thing for tabs Vs spaces etc, so obviously everyone paints the bikeshed, but this time it's completely tied to one person's personal computer display)

I was going to complain about them because there are a few fonts there I like a lot, but not the ligatures. Wasn't sure if it was = or == or === in the samples.

You can disable the ligatures for all those fonts and only see =, ==, === explicitly.

I agree with the author on adding ligatures where they are not needed, but one of the comments used in their justification is not quite right:

> Unicode [...] identifies each character uniquely. This way, software programs don’t have to worry that things like the fi ligature might be stashed in some special place in the font. Instead, Unicode designates a unique name and number for each character, known as a code point. If you have an fi ligature in your font, you identify it with its designated Unicode code point, which is 0xFB01.

This is true for the Roman script, but for many other scripts, Unicode does not provide dedicated code points for common ligatures. They would instead have to be denoted by two characters with a zero-width joiner in the middle (much like emojis).

Also, most Unicode experts would tell you not to use 0xFB01 in new stuff today and instead should rely on font ligatures for it. 0xFB01 was included in Unicode for cross-compatibility with older encoding schemes for systems that didn't support fonts with ligatures. Today we have support for fonts with ligatures.

This looks very nice, but I can't pay that much for a coding font like this simply because until you load it into the various pieces of software you use it is impossible to know how it will render. Especially on a non-hidpi screen.

Chances are it will look significantly different than the PDF once you load it into your terminal. Each of the three terminal emulators I have installed already render fonts very differently from each other.

The author offers a pretty good 30 day refund policy if the font doesn't work in your use case: "Triplicate has no demo version, but I do offer a 30-day return option: if the fonts aren’t your style, you can cancel your license for a refund."

As for the customer service experience, the author himself has responded (within the day even) to a couple of emails when I had questions about licensing.

They give a 30-day free trial, it seems (last item in the 5-reasons list):

"Triplicate has no demo version, but I do offer a 30-day return option: if the fonts aren’t your style, you can cancel your license for a refund."

Ah thanks, I didn't spot that. That's good enough!

> the only true serif monospace that I know of

Sun Gallant Demi is another one. Libertine/Libertinus Mono as well.

Oh cool! Thanks for broadening my horizons.

> My favourite monospaced font is Triplicate: the only true serif monospace that I know of

Also: https://github.com/yellow-type-foundry/xanhmono / https://fonts.google.com/specimen/Xanh+Mono

Cool! I hoped that line would get people to show me a few more, and it has.

The "l" looks like a big "1" in Triplicate. There is no way I will use a font like that for programming.

I agree with you and do consider the default l glyph to be a poor choice, insufficiently distinct from 1. Fortunately, the Code variant of the font goes for a curved tail on l, so that it’s sufficiently distinct.

(However, if you try to enable both the Code and Poly features—Poly meaning “don’t be a true monospace, make characters like l and i a little narrower and characters like m a little wider”—you end up with a slightly narrower flat-bottomed l glyph, rather than a curved tail. See this, for example, in https://chrismorgan.info/blog/make-and-git-diff-test-harness..., which is set in Code + Poly. Disable the `code { font-feature-settings: "ss01" 1, "ss02" }` CSS rule to see the effect of removing Poly—you get the curved tail l glyph back again. I’ve been meaning to sort out a better glyph for the combination, but I haven’t gotten round to it yet, because it’s annoyingly difficult to actually do that sort of thing.)

As mentioned in [1], Triplicate includes a Code variant which disambiguates l and 1, and O and 0, and makes other tweaks for better legibility.

[1] https://practicaltypography.com/triplicate.html

Triplicate has code-specific variants, including a curved lowercase L.

What's the decision process behind _choosing_ a font? I've always gone by look and feel but I've never felt fully satisfied with any of the (code) fonts I've chosen. I used Incosolata for a long time and in the last year I've moved to Hack. I really like Hack a lot but I am also trying harder to make more conscious decisions with my physical programming environment as I age (beyond aesthetics, caring about ergonomics, etc...).

I'm dyslexic. Because of that, I've spent a bit of time thinking about this for practical reasons. I prefer heavier sans-serif fonts with no character ligatures, but I like symbol ligatures and glyphs; they're not deal breakers. I've been using Cascadia Code, and find it usable, don't like the dotted 0 (the fact that the top and bottom of the 8 round in sharply helps offset this) or the few serifs it has. I've used Ubuntu Mono (spacing is too tight) and Source Code Pro (lines are too light) in the past.

What I look for is legibility between things like ({}), l1!|I, Oo08, mwnu, tl bpdq, ecoa, and being able to distinguish repetitio and symbols like --, ==, !!, "'`, :;, _-, and even ,.. (Something's going to try to parse that and absolutely shit itself)

I just grabbed B612 Mono.

n.b. I hadn't actually assembled those thoughts into one place before now. I apparently have Opinions about this!

Triplicate looks like Gallant, the font used by old Sun workstations. Looking like Gallant is a point in its favor (but ouch! That license fee is to its detriment.)

As far as serif monospace, NSimSun is still my favorite. It's in Windows. I love Triplicate but can't bring myself to purchase yet. I like Equity, too.

I think Triplicate is the closest to the old Selectric Prestige font, which I loved. But if anyone has NSimSun replacements (paid or free), please let me know.

A sibling post [1] mentioned Xanh Mono, which looks similar to NSimSun IMO. They both have that distinctive "Latin script alongside eastern script" serif look.

[1] https://news.ycombinator.com/item?id=25161756

Equity, a mono serif? Where do you find that one?

Equity is being mentioned as another of Matthetw Butterick’s fonts—a serif, not a monospaced font.

I like the true italics - they remind me a bit of the Light Italic typeface on the IBM Selectric (which has been discussed recently on HN I think.) IBM developed a number of beautiful and legible typefaces for its typewriters and I'd love to have them all as screen fonts.

> those characters aren't typable and will only ever be used in strings

Raku wants to have a word with you. https://docs.raku.org/language/unicode_ascii https://docs.raku.org/language/unicode_entry

Yep, Triplicate and is far and away my favorite programming font as well, closely followed by Operator Mono. You need to pay for both, but it was easily worth it for me.

There's also CMU Typewriter text if you want another serif monospaced font. Looks wonderful in high dpi I believe. I've hacked mine to put slashed zero.

That’s a slab serif.

What about GNU Free Mono? I use it for APL development because it has nice APL symbols. The font itself uses serifs.

That’s a slab serif.

i can't find any pictures of triplicate with a dark background. could you share any? some hefty fonts (ie, go mono, courier) look so different when you change backgrounds that i am hesitant to buy without looking at a sample.

TIA

My own website has a dark theme if you have @media (prefers-color-scheme: dark), or if JavaScript is enabled, there’s a switcher in the top right hand corner. Note however that I use Triplicate T3 in the dark theme (300/700 for regular/bold), compared with Triplicate T4 in the light theme (400/700). You can fiddle with the @font-face declarations in dev tools (the font change happens in 2019b-dark.css) if you want to try swapping it out. https://chrismorgan.info/blog/rust-fizzbuzz/ has a bit of code, some other articles do as well.

thank you! this helps. as i suspected it is the best font i've seen for programming with a light background, and just meh with a dark background. i prefer a dark background though, and the only font that i can tolerate with dark is pragmata pro. sigh being so aware of fonts is a curse.

thanks again.

ok; so i bought the font. it's beautiful! wow. thanks.

Go Mono is another nice looking serif monospaced typeface I use.