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.)
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.
It was designed to be a comprehensive monocode typeface to support Julia's full Unicode support.
Most programming languages evolved from the limited selection of ASCII printable characters from the keys of early ASCII keyboards (which evolved from earlier typewriters and teletype machines)...
But these days we have Unicode -- a huge amount of potential symbols (and combinations of symbols!) that could be used in new programming languages (i.e., asterisk: '*', long used for multiplication could (finally!) be replaced with a true multiplication symbol: 'x' -- if an extended symbol space were used by the language...
Symbols could visually represent such things as loops, conditionals, variable declarations, etc., etc.
Pointers and pointer dereferencing (if the language supported it) -- could have their own symbols...
Would that be a good idea?
Well, if backwards ASCII compatibility is desired to run on old computers for whatever reason (in a future time when we need to revert back to older/simpler/more predictable systems because the AI's are out of control?) then maybe not...
But if we wanted graphical or quasi-graphical symbols to represent programming constructs more visually -- then maybe the idea has some merit...
Maybe a conversion program could be written that would convert between the new symbol set and ASCII, and maybe the programming language would be created to recognize both constructs...
And yes, I know that there is the Scratch programming language -- but I'm not talking about quite that visual! :-) The language I envision would still be physically typed on a keyboard, as most are today...
Anyway, great looking typeface!
Just a heads-up.
| ^
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.
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
Some people believe that ligatures make source code more readable. Even, perhaps, beautiful or "comfy."
Others feel that past a certain point, programming font choice doesn't really matter much and that too much time spent sharpening the saw means you never get around to cutting the wood. Or that hiding two physical symbols behind a single logical one for the sake of aesthetics is somewhere between pointless and dishonest.
Still others are of the opinion that we wouldn't need ligatures at all if programming languages understood Unicode. The other problem of course being that most of us don't have Unicode keyboards.
Your project seems to have somehow managed to upset all three camps and for that, I salute you and have starred your project on GitHub.
I like that it's relatively compact horizontally. If I had to nitpick, the curly braces look a bit too "wavy" for my taste, which doesn't quite match the hard angles on some other glyphs.
My favorite monospace font for the past 10+ years has been Iosevka Term ss08. I've tried many others over the years, and Iosevka is just perfect IMO.
Out of curiosity: what are the tools and the process to create a font today? It would be interesting to read a bit about that.
Switched from Iosevka to this, feels a little more readable.
It's about halfway between standard Iosevka and a typical monospace font in terms of narrowness. I find it ideal.
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
Do you ever feel like your font treats symbols as second-class glyphs? Are you frustrated that -> looks nothing like an arrow, and $, @, % seem ever mismatched?
Want to experience the beauty of ligatures without losing the simplicity of ASCII?
Myna (Gracula religiosa 🐦⬛) is a monospace font which aims to bring harmony to your editor by treating symbols as first-class glyphs alongside alphanumeric characters.
Myna was born of a need to scratch a persistent typographical itch. While I've tried many otherwise well-crafted monospace fonts, I always found myself wanting to tweak a glyph here or adjust a shape there. After developing Myna and using it almost exclusively in my professional and personal work, I'm sharing it as a small contribution to the wonderful community of monospace typography enthusiasts.
Here are a few of its attractive features that might make it your next favourite monospace font:
->, >>=, =~, :: align seamlessly1 l I | or 0 O oNB: Myna is designed to be a simple font. The current release is a single weight without ligatures, though future updates may expand its features if demand arises. It does work out nicely with synthesised bold generated by fontconfig and pango on Linux.
Here is a comparison between some popular monospace fonts with Myna (at the bottom in different color). The list of the fonts used could be found in the script mkcomp. Myna tries to emulate the smooth look of ligatures but also retains the simplicity of ASCII.
Please click on the images below to view it in full in a new tab.
| Language | Light | Dark |
|---|---|---|
| Perl | ![]() |
![]() |
| Haskell | ![]() |
![]() |
| C | ![]() |
![]() |
| Bash | ![]() |
![]() |
| Clojure | ![]() |
![]() |
| Erlang | ![]() |
![]() |
| OCaml | ![]() |
![]() |
| Rust | ![]() |
![]() |
| LaTeX | ![]() |
![]() |
| HTML | ![]() |
![]() |
| SQL | ![]() |
![]() |
git clone https://github.com/sayyadirfanali/Myna.git
cd Myna
cp Myna.otf ~/.local/share/fonts/
fc-cache -v
git clone https://github.com/sayyadirfanali/Myna.git
cd Myna
cp Myna.otf ~/Library/Fonts/
Myna.otf and select "Install for all users"SIL Open Font License, Version 1.1
Myna started out as Hera which was a customised version of Source Code Pro but now has come a long way after stealing many beautiful designs from Fira Mono, Inconsolata, Plex Mono, Office Code Pro, Anonymous Pro. Detailed credits could be found in the Hera repository.
Code banner and illustrations were produced using ImageMagick and Ray.so.
Myna is designed to be used universally in every kind of terminal and editor. I've tried to include a reasonable subset of non-ASCII glyphs (mostly geometrical and mathematical characters). However, I'm considering expanding it based on community interest and would welcome contributions in these areas:
Please feel free to open issues and also contact me at irfan@irfanali.org.
- https://www.intel.com/content/www/us/en/company-overview/one...
the problem there isn't only in making characters distinct - but it's about not confusing one for another "in a vacuum", by itself
this font succeeded in making `I` unique - but `l` still looks like "one"
I wish people copied discord's font in this instance - remove bottom serifs altogether and replace with a slanted end
this sentence makes no sense, ASCII is something like a code page and ligatures are something like glyphs
Looks like I’ll have to install this to see if it’s the case here.
BTW, I find the screenshots for this font quite a bit more useful in evaluating it than any of the other fonts referenced in the HN comments here. These help you decide at a glance.
Input Sans is great:
No because this problem has been solved by other font designers working with pretty much exactly the same requirements.
As an engineer, I like to see -- for the lack of better word -- some taste instead of characters being too formal and too symmetric. Ubuntu and Ubuntu-Mono satisfy this to a good extent without being too much, like in comic sans.
The closest font with similar taste, which I found recently is Mononoki
The site should be more explicit about which characters are covered. I understand it's only ASCII, right? Although the example shows some currency signs that are definitely out of the 0-127 plane.
It would also be appreciated if you could suggest a fallback font for those glyphs not present in Myna, so that if I ever need to include the word "naïve" in a string, for example, the "ï" won't look as an alien character.
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.
this particular font is quite simple and doesn't contain any ligatures, etc. so most of the design is in Fontforge. i didn't start from scratch. it started out as a customised version of Source Code Pro (released as Hera and currently archived in my profile) but i borrowed many glyphs from other fonts and modified many others to the point it became a different font. you can open the .sfd file directly in Fontforge to edit and modify it yourself.
It allows comments to indicate the thing they're talking about ↑
Or logical → implications
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.
It’s easy to toggle ligatures on or off in the common editors. A lot of fonts have them, but they’re opt-in. Nobody gets alienated.
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
but more than preference there is matter of availability and consistency. Unicode is not available for all possible glyph combinations and many times what we see in Unicode looks quite ugly in monospace because of the width constraint.
ligatures are also not supported everywhere. that is one of the reason i designed this.
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.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).
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.
Are there any programming languages that use vertical arrows? Do they appear on one line or two?
Unicode is not there for you to necessarily use the whole thing. It's there so that everyone in the world can encode their text the same way, despite having a completely different set of characters on their keyboards.
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...
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.
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).
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.
Or, as suggested here, use language macros:
#define → ->
https://lists.isocpp.org/std-proposals/2023/01/5485.phpif you want to use it but em-dash is the only deal-breaker, please try it once and raise a feature request. i'd see what we can change to make it work.
(Sorry.)
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.
I found what while it's not the best for me - it is suprisingly good for a PowerPoint-like presentations, #specially the condensced vars.
about the alignment, i think the README might give an impression that it's solely about vertical alignment, but it's more about uniform flow of characters along with some resemblance with an actual symbol (which we can not have in ASCII).
for example, take the `<-` combination. i think you're correctly pointing out that in most fonts they are indeed vertical-aligned properly. but there are other details (horizontal alignment, angle between strokes, weights, etc) which i found missing. in most monospace fonts, these less-than and more-than signs are not designed with the view that their most common usage is indeed not checking for inequality but for bitwise operators and struct pointer dereferencing (C), function declaration and monadic/applicative/functorial programming (Haskell), shell redirection (bash), function composition (OCaml, Elixir), tags (HTML), and countless others. if you think about it that way, it makes sense to not make the angle between strokes too small. many monospace fonts do it because they respect classical typographic conventions regarding space and design. the same goes for the designs for backquote, tilde, comma, colon. in most monospace fonts, backquote is so small it's barely visible and tilde looks too much like the hyphen, etc.
Myna is my attempt to break some of these conventions to make things look a little bit even for programmers.
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
i didn't know about Go Mono. it looks alright but monospace serifs are probably not for me.
the symbols are all pure ASCII and are supposed to look normal. it is not a ligature font and neither focusses on Unicode symbols. the symbols are just more evenly adjusted with the letters and with each other.
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.
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).
Peers of my age also can't stand looking at my screen contents, so maybe it's also because I have bad eye-sight and am used to infer letters from general shapes and context.
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.
Same way you type everything else - by pressing a button combination that corresponds to the symbol in your layout. Or by using an app that does it without changing the layout. Like your editor could insert → when you type fn () -> {} Or you'd simply not type it and continue to use ->
> Or I need to get out a special keyboard per language?
No, your regular keyboard will work fine for any language.
> Unicode is not there for you to necessarily use the whole thing
The suggestion was about literally 1 char (maybe implicitly about a dozen more), why did you jump to the millions from "the whole thing"???
I will test it out and report any abnormalities I see!
languages which insist on using full Unicode like APL and Agda have bigger problems (availability of uniform glyphs and inconsistency with monospace design) on their plates. which imo is one reason why full Unicode editing hasn't really caught up.
Myna doesn't use any ligatures though. it would run on almost all terminals and editors.
A search on Google Fonts shows most monospaced fonts keep them vertically aligned, but there definitely are exceptions:
https://fonts.google.com/?preview.text=%3C-%3E%3D%2B-~&categ...
I'd be very, very surprised if inequalities was used less often.
Don't get me wrong. I appreciate the work you put into the font and it looks very nice but that part of your post struck me
0 and O are not actually confusing in any of the fonts I use. As I’m typing this comment without any custom font changes, the 0 has a slash through it. In other fonts I use there’s an option to add a dot. These are all normal and common.
Redrawing the ^ character to not be elevated would be unexpected.
> This is not (such) a (n absolute) thing, there are different contradictory norms that persist for decades,
Fonts are expected to show common characters as those character, not something different to satisfy a singular edge case at the expense of every common use case.
If someone wants vertical arrows they should use Unicode vertical arrows, not try to force everyone looking for a ^ character to see something unusual.
But I've sacrificed vertical alignment for a more human-friendly code appearance :)
It definitely helps differentiate similar-looking glyphs!
Being distinct from parens and brackets is obviously still desired and sorry I'm not a designer myself enough to give more specific feedback on how it could be improved.
Otherwise very attractive font.
what would be ideal is a variable-width font which covers most Unicode characters consistently. some Unicode characters (eg, arrow) would need space of 2 characters and so on. making it elegant would require quite a lot of work to ensure Unicode does't look out of place (eg, arrow in your comment).
these are the problems which make me feel full Unicode editing is difficult to achieve in the short run. not to mention the obvious issue of typing Unicode characters from the ASCII keyboard.
i've included a reasonable subset of Unicode in Myna but it may not look very good. don't get me wrong, i appreciate the Unicode advocacy. but until we've something good-looking and well-behaving tooling on that side, using it would be quite frustrating.
The comment above requesting that ^ be turned into something unexpected would have been a negative, but thankfully it’s not a feature of the font.
Rather, you don't provide reasons to motivate people to switch to your font and stick with it.
You have mainly two kinds of users:
- those who have always stuck with whatever font came up by default in their text editor or terminal emulator.
- those who have gone through a phase of experimenting and tried a good bunch of fonts, then settled.
When you motivate the former group to experiment, they will tend to go into the second group: once they get into the workflow of installing fonts, they won't just stop at the one that was suggested to them first.
The second group is harder to motivate to try new fonts; they will do it if there is some compelling reason they can understand /before/ installing.
You don't explain how your font stands out above the competition. Or, maybe the personal angle: I tried these fifteen different fonts and still had to make one because X, Y, Z, so here it is.
Not everyone likes it, but I do.
Having to use some app that converts two characters inserted in sequence into the correct character is a terrible idea. It makes me think of the Dvorak trend among geeks. I very nearly learnt Dvorak myself, but then a wise elder dissuaded me, reminding me how amazing it is to be able to type fast on any keyboard you come across, even if it might only be 90% of your theoretical maximum on the perfect keyboard. Sometimes local optima are good enough.
> The suggestion was about literally 1 char
It's never "just one more".
the inequalities would probably be more common than bitwise/pointer usage in C, most because of for loops, i guess.
but if you consider all the other languages i listed, it is obviously not the case, especially in Haskell and even HTML.
But we're not talking about you, are we? You made a very general point, so look around... generally
> These are all normal and common.
Again, look around at most popular fonts in this wor(l)d, see how few of them have it. It's only "normal and common" in a small niche of code fonts. At most popular fonts would differentiate width, but that is a far legibility cry from the "exicting" innovation of using a dot. But that would be a surprising experience to most of the users because it's a rare occurence, so breaks your "be boring" maxim.
> Fonts are expected to show common characters as those character
In the case of 0 "as those characters" means an empty oval, so adding a dot/cross is "something differnt to satisfy a singular edge case" of basic legibility at the expense of "every common use case" of confused ovals between 0oO
Also, I finally looked into more details of the ^ and even more confused by your comments: one of the most popular fonts - Verdana - has ^ exactly like described by the OP - top reaching the top of U and bottom reaching the horizontal line in e. Similar with Arial, ony it raises higher than U Same in a popular code font Source Code Pro
So all your "don't mess with expectactions" is made up, they do not exist because that symbol is already popularly different, so there is no expectation that it's a tiny hat!!!
i've not been faithful to the original design of Source Code Pro or even Fira Mono or Ubuntu Mono (from which i also derived a lot) but do try to stick to a simple geometrical ideal with only a few exceptions.
now i have also added a comparison table of Myna with many popular monospace fonts (if that could help gauge the utility).
i understand that there would be many many folks who would find this font ugly and unusable. it is largely a matter of personal preference.
You mean the label: well, take out your favorite marker and draw one on the side! But also, you don't have labels that correspond to these standard Mac layout symbols https://i.sstatic.net/ht0Tg.png So? Should it be removed?
> ubiquitous, regular keyboards that have been around for decades.
All poorly designed, most even acknowledge that by adding an extra set of numbers at the side because the default numeric (and symbolic) row is so bad. Why is the 'why bother improve the awfulness' a great attitude?
> but then a wise elder dissuaded me, reminding me how amazing it is to be able to type fast on any keyboard you come across
There is nothing wise here, it's a bog standard rejection of any improvement. First of, you could still train yourself to use both. Second, if you're only using your own keyboards 99.9% of the time, there is nothing amazing about not being slowed down in those tiny percent of typing cases. Also, it's of course not literally `any` keyboard you come, that's such a myopic view - plenty of countries have different non-qwerty default layouts, so you wouldn't be able to enjoy your qwerty speed there
> only be 90% of your theoretical maximum on the perfect keyboard
What if it's 10% that will make you disabled in 20 years? After all, "speed" isn't the only factor here. Any "wise" man could appreciate the broader ergonomic implications...
> It's never "just one more".
If only you didn't cut off the quote you could've read "implicitly about a dozen more", but the most important part is the last that you failed to address about the millions
The big problem that I am having with this font is that its narrowness makes it difficult to find a fallback font for APL/BQN that plays well.
> find this font ugly and unusable
Not even remotely the case; they would have to get their heads examined.
So why would one change the keyboard layouts just because somebody needs an arrow for programming? This is such a niche use case that it will never happen.
Also many programmers will not want to use the unicode arrow instead of ->, thats a personal choice and nothing else.
It would also be fatal to retrofit old languages like this since it would just create confusion for little benefit.
How do you square this with the simple fact that it has already happened? And just as simple of a forecast: it will continue to happen.
> Also many programmers will not want to use the unicode arrow instead of ->, thats a personal choice and nothing else.
So what? Other programmers will.
But I don't get your general point - are you saying that the only change worth doing is the one that has happened globally in the past? Like, currently some popular languages support "unicode letter" for identifiers, which means it includes various nonsense like dead languages from thousands of years ago (but doesn't include much more used stuff just because the designers outsourced all their thinking to some Unicode Annex). Do you want to remove all that for consistenty with the fact that no one will ever use those symbols in function names?
> It would also be fatal to retrofit old languages like this since it would just create confusion for little benefit.
Could you link to the death certificate of the old language called C since this compiles despite no one having 𓀄𓀂 in their keyboard layout
#include <stdio.h>
int main() {
int var𓀄𓀂 = 2;
printf("%d\n", var𓀄𓀂 );
return 0;
}
Are you confused to death?These arrow symbols are NOT identifiers but a specific syntax used in these C type languages, and then you give examples of identifiers being able to be specified in unicode.
This is not the same thing, so i have to assume that you are confused here.
Also, my point is that keyboard layouts are so ingrained that they will never change, and even if they change, it wouldnt be for some niche use like using unicode arrows.
So what? How is that relevant to your argument about fatal confusion? Why is confusion in supporting var𓀄 ok, but confusion supporting → in addition to -> suddenly fatal???
> they will never change
What's the point of this point, what does it address in this conversation? Who is talking about mandatory or even necessary global layout changes? Did you miss one of the alternatives I mentioned that allows changing nothing on your input side by letting your editor auto-substitute?