Iosevka is a beautiful font indeed. the condensed look of Myna was inspired by Iosevka. i saw it once in a coding demo and decided to make it condensed. the predecessor of Myna (called Hera, available on my profile) was just a customised version of Source Code Pro (and is non-condensed, just like Source Code Pro).
Beside being a neat font in its own right, Iosevka allows for custom builds with different settings, selection from a bunch glyph variants, and custom ligature choices. It's pretty incredible.
Thank you for the detail that Iosevka is a form of the name "Joseph." I've used this font for years and it never clicked for me--nor did the correct pronunciation, which it turns out was always listed on the readme.
Not trying to be negative, just confused: I don't really see how this font is "designed for symbol-heavy languages". The symbols look normal to me. Maybe the letters are a little more spaced? I'd love to be enlightened.
designer here. by symbol-heavy languages i mean languages like Perl and Haskell which make heavy use of symbols (sigils in Perl and operators in Haskell). Myna was designed after my frustration with other monospace fonts combined with my (self-imposed) inability to use ligatures.
I think it might be useful to put some screenshots of other fonts on your page, to show what symbol or alignment problems yours corrects. Because I've studied a lot of typeface design, and I can't really figure out what you're doing, what pain points you're trying to address.
Because when you say "and $, @, % seem ever mismatched?", I don't have the slightest idea what you're talking about. I certainly am curious though, since you went to all the work of building a new typeface!
And when you talk about fixing alignment, like all of these seem correctly vertically aligned with each other here on HN at least in monospace mode:
<->=+-~
So if you could demonstrate what it is fixing with reference to the most common monospace system/coding fonts, I think that would help a ton.
Thanks for the link, at first glance seems like a fascinatingly rich font
(by the way, to overcome the char/font limit they can publish JuliaMono2 and 3 and 4 and then set those as fallback fonts to reach the full coverage...)
thanks for pointing it out. i mostly program in ASCII range. Myna covers a reasonable subset of Unicode but one can indeed use Julia as a fallback for Myna to cover Unicode if one wishes.
The kerning in the "Lorem" at the top drives me batty. It nearly looks like 2 words to my eye. I know that's super subjective and it probably doesn't bother anyone else at all. It's kind of a deal breaker for me, though.
i use this font basically everywhere and have become kinda blind to the defects. for me it looked best when glyphs are mostly centered (which makes them "genuinely monospace" if you catch my drift).
but you raise a valid point. it is not entirely subjective. some obviously grotesque (no pun) kerning would need to be changed in the next version. if you can point out some obvious ones i would urge you to create an issue.
This, like many fonts, fails to handle vertical arrows:
| ^
v |
Note that the raised appearance of `^` exists for compatibility with typewriters that use the backspace key to use it as a circumflex accent over lowercase letters. This is doubly obsolete today (we have real combined characters and can use them on uppercase). This is one of those cases where the name originally used for the character in various standards is in conflict with the way people actually have come to use it.
The bottom of the independent caret should be lower, roughly symmetrical to the letter `v` (this is not traditionally a goal). The top should still reach the height of a capital letter, but the bottom should descend into the lowercase letter area - for many fonts, perhaps to the level of the horizontal part of a lowercase `e` (is there a typographical term for this?)? For fonts where the x-height is half of the cap-height, there might be no overlap with the lowercase letter, though it still doesn't need to worry about leaving space.
The bottom of the caret is, however, higher than the mathematical "and" sign ∧, which rests on the baseline (and usually does not reach full height) or the Greek capital lambda `Λ` which is full height.
I have never seen anyone use it as part of an up arrow spread across two lines in the way that you’re suggesting. So I don’t really understand your point.
Ok it’s not symmetrical, but I don’t buy your argument that it _should_ be (or that it’s a reasonable complaint to make about a font).
Rust compiler error output certainly uses a lot of vertical arrows. But it also highlights the fact that the caret is often used to highlight characters on the line above, and if it were lower it would be worse at doing that.
I do hate this asymmetry when I'm trying to do an ASCII flowchart of some sort.
But I'd also like to add that calling it an unreasonable complaint sounds a little hysterical. It's just a complaint. It's also a clear one, and of obvious use.
Your point about the caret is interesting, but I'm a bit dubious about using them for vertical arrows. I don't think it would be practical to type this combination in one go, since the two symbols would be on two separate lines. For the upward arrow, are you suggesting caret-return-space-space-space-...-vertical bar?
Are there any programming languages that use vertical arrows? Do they appear on one line or two?
I don't see such a niche use case as a design failure.
By your logic, the lowercase "v" should extend even higher to meet the pipe. The caret has conventionally been higher for a long time, and IMO would look out of place making it the inverse "v".
thanks for pointing it out. as i mention below in a comment, there are bound to be many combinations which don't align (especially vertical ones). i would ideally tell you to invoke a feature request but i am not sure this esoteric combination could even be detected in a contextual alternate rule (which Myna doesn't support anyways for now).
beside if i may say so in my defense, the comparison is a bit unfair as a V (a full letter) is being compared to a caret (almost a superscript symbol). i have broken many typographical conventions but it won't make sense to break programmatic convention of the caret operator just for the alignment of the vertical arrows.
> Note that the raised appearance of `^` exists for compatibility with typewriters that use the backspace key to use it as a circumflex accent over lowercase letters. This is doubly obsolete today
The origins don’t really matter at this point. That’s what the character looks like and it’s what everyone expects.
Your use case is extremely niche. Making a font choice for that specific double-line situation would alienate everyone else who just wants the ^ to look like a ^.
Like others suggested, just use the Unicode arrows if you want arrows. Let the ^ be a classic ^.
It’s really disappointing when I find a new font that seems interesting until I encounter one weird design choice that makes it surprising to read. Fonts should be boring, typical, and follow what your brain expects to see, not trying to erase decades of typography norms and start something new for one common character.
> Fonts should be boring, typical, and follow what your brain expects to see
So you're ok with permanent confusion of 0 vs O because "boring/expected" doesn't add a dot for zero?
> erase decades of typography norms and
This is not (such) a (n absolute) thing, there are different contradictory norms that persist for decades, just like in and artistic (though not only) field, so at a practical level this offers no guidance for any specific decision, you'd have to actually consider it in that specific case to see whether it makes sense
Not a solution to your issue but as my main use of arrows is in documentation I've just mapped ↓ ↑ → ← to a covenient place on my keyboard. It's pretty at least
It allows comments to indicate the thing they're talking about ↑
Those symbols were never intended to be used as arrows. Every modern programming language today can use Unicode at least in comments, and there are extensive groups of characters for box and arrow drawings.
> Are you frustrated that -> looks nothing like an arrow
The proper solution is, of course, to allow ←arrows→ (and, naturally, not trying to fit a variable peg into a monowidth whole)... maybe in the next generation of languages when the bottom level of typesetting quality is raised a bit
i have addressed this in one of the other comments. it is impossible to achieve both elegance (good look) and consistency (monospace width) in these cases. many folks, like yourself, are pioneering full Unicode editing. we, on the other end, are just trying to make editing without ligatures elegant because ASCII, i believe, would remain predominant for a long time to come.
I kind of think monospacing is overrated in programming. Sroustrup typeset the entire of The C++ Programming Language in variable width font and it looks totally fine. I've used variable width fonts in my editor a fair bit too.
I think the main problem with it is you need to use tabs for indentation and unfortunately spaces comprehensively won that battle. IMO that's because although tabs are clearly better, spaces are definitely more idiot-friendly and there are a lot of idiots in the world - or at least people who don't give a shit about nice formatting. So large tab based codebases tended to end up with a horrible mix of tabs and spaces.
well, my "pioneering efforts" :) are killed by language designers, as you note "it is impossible", so we can only waste time looking for various workarounds like using fonts designed around those limits...
Typesetting doesn’t really get better until you use proportional fonts for programming. At least in my experience, I know this is controversial since proportional fonts don’t allow for ascii art.
and don't solve the spacing issue, also: I see an →, so I type one in my search box, but can't find anything since it's not an arrow, but a fake replacement of ->
Or I press Shift+Right to select it, but can't, need to repeat it 3 times because again, it was a long arrow, not a single symbol. Then, of course, they could do a replacement in y our comments where you meant literal symbols, not an arrow...
I appreciate the effort, but the result kind of shows why usually symbols are aligned as they are. Dashes, colons, angle brackets — all look way too high next to lowercase letter. I assume this stems from trying to align everything with brackets, and those are aligned with uppercase letters kind of naturally. But I don't think the tradeoff is worth it.
i understand the point you raise. but i believe symbols are generally aligned as they are because most fonts are designed for text and many monospace fonts respect those typographic traditions.
but i think code is not text and breaking some tradition improves readability.
the dash (hyphen) is actually supposed to align with the greater than symbol to resemble the arrow (extremely common symbol in C and many functional languages).
Genuine question: is everyone coding on such high resolution displays and/or with font sizes so big nowadays? For me, the example screenshots are useless to see how the font would actually look like in my editor.
Hard to talk about "everyone" since I'm not aware of any large polls around this point. On a personal note, yes, considering that I'm 44, I tend to always increase font size everywhere: the code editor, the terminal, the browser, the OS itself and mobile phone.
It's unavoidable for me. I was making fun of those people with huge font sizes on phones 10 years ago. I'm almost one of them now.
As a counter example, I always decrease the font-size everywhere. The annoying trend of bloating everything with whitespace, means that less and less stuff fits on the screen. But even HN is on 80% right now.
Not me. Ubuntu Mono is the only font I'm able to use because all others I've tried just take up so much space. I'm literally losing lines of text with other fonts. I need that density. I haven't tried this one yet, though.
I definitely increase my font size, so I'm not straining my eyes. Any monitor with a lower than about 120 PPI causes me strain, unless I really boost the size. For example I read HN at anywhere from 150-200%.
Readit News
https://github.com/be5invis/Iosevka
The fun thing with Iosevka is that one stands a reasonable chance of reading the source code (as opposed to just random numbers in SplineSets etc.)
It's about halfway between standard Iosevka and a typical monospace font in terms of narrowness. I find it ideal.
Switched from Iosevka to this, feels a little more readable.
Makes my terminal look amazing as well.
Especially since I've been working on a color scripts compilation that relies heavily on font being accurate
The GitHub page has a list with 5 items of what was the focus, this is the first (and I think the most easily noticeable) area
Because when you say "and $, @, % seem ever mismatched?", I don't have the slightest idea what you're talking about. I certainly am curious though, since you went to all the work of building a new typeface!
And when you talk about fixing alignment, like all of these seem correctly vertically aligned with each other here on HN at least in monospace mode:
So if you could demonstrate what it is fixing with reference to the most common monospace system/coding fonts, I think that would help a ton.It was designed to be a comprehensive monocode typeface to support Julia's full Unicode support.
The kerning in the "Lorem" at the top drives me batty. It nearly looks like 2 words to my eye. I know that's super subjective and it probably doesn't bother anyone else at all. It's kind of a deal breaker for me, though.
but you raise a valid point. it is not entirely subjective. some obviously grotesque (no pun) kerning would need to be changed in the next version. if you can point out some obvious ones i would urge you to create an issue.
I will test it out and report any abnormalities I see!
The bottom of the independent caret should be lower, roughly symmetrical to the letter `v` (this is not traditionally a goal). The top should still reach the height of a capital letter, but the bottom should descend into the lowercase letter area - for many fonts, perhaps to the level of the horizontal part of a lowercase `e` (is there a typographical term for this?)? For fonts where the x-height is half of the cap-height, there might be no overlap with the lowercase letter, though it still doesn't need to worry about leaving space.
The bottom of the caret is, however, higher than the mathematical "and" sign ∧, which rests on the baseline (and usually does not reach full height) or the Greek capital lambda `Λ` which is full height.
I have never seen anyone use it as part of an up arrow spread across two lines in the way that you’re suggesting. So I don’t really understand your point.
Ok it’s not symmetrical, but I don’t buy your argument that it _should_ be (or that it’s a reasonable complaint to make about a font).
You've never heard of "caret and stick"?
I do hate this asymmetry when I'm trying to do an ASCII flowchart of some sort.
But I'd also like to add that calling it an unreasonable complaint sounds a little hysterical. It's just a complaint. It's also a clear one, and of obvious use.
Are there any programming languages that use vertical arrows? Do they appear on one line or two?
Befunge (1993; many later languages were inspired by it) uses just the ASCII arrowheads. The arrow tail is more likely to exist in doc comments.
By your logic, the lowercase "v" should extend even higher to meet the pipe. The caret has conventionally been higher for a long time, and IMO would look out of place making it the inverse "v".
If you want arrows, just use U+2191 and U+2193.
You could maybe try U+2303 (⌃) for the up arrowhead, but why not just use U+2191 (↑) for the standard arrow?
The crossbar height of lowercase letters is not a common typographical reference point...
beside if i may say so in my defense, the comparison is a bit unfair as a V (a full letter) is being compared to a caret (almost a superscript symbol). i have broken many typographical conventions but it won't make sense to break programmatic convention of the caret operator just for the alignment of the vertical arrows.
I don't know why the elevated position of the caret is sacred, other than to use as an accent mark. It could cause confusion with the ∧ (AND).
The origins don’t really matter at this point. That’s what the character looks like and it’s what everyone expects.
Your use case is extremely niche. Making a font choice for that specific double-line situation would alienate everyone else who just wants the ^ to look like a ^.
Like others suggested, just use the Unicode arrows if you want arrows. Let the ^ be a classic ^.
It’s really disappointing when I find a new font that seems interesting until I encounter one weird design choice that makes it surprising to read. Fonts should be boring, typical, and follow what your brain expects to see, not trying to erase decades of typography norms and start something new for one common character.
So you're ok with permanent confusion of 0 vs O because "boring/expected" doesn't add a dot for zero?
> erase decades of typography norms and
This is not (such) a (n absolute) thing, there are different contradictory norms that persist for decades, just like in and artistic (though not only) field, so at a practical level this offers no guidance for any specific decision, you'd have to actually consider it in that specific case to see whether it makes sense
It allows comments to indicate the thing they're talking about ↑
Or logical → implications
The proper solution is, of course, to allow ←arrows→ (and, naturally, not trying to fit a variable peg into a monowidth whole)... maybe in the next generation of languages when the bottom level of typesetting quality is raised a bit
I think the main problem with it is you need to use tabs for indentation and unfortunately spaces comprehensively won that battle. IMO that's because although tabs are clearly better, spaces are definitely more idiot-friendly and there are a lot of idiots in the world - or at least people who don't give a shit about nice formatting. So large tab based codebases tended to end up with a horrible mix of tabs and spaces.
but i think code is not text and breaking some tradition improves readability.
the dash (hyphen) is actually supposed to align with the greater than symbol to resemble the arrow (extremely common symbol in C and many functional languages).
It's unavoidable for me. I was making fun of those people with huge font sizes on phones 10 years ago. I'm almost one of them now.