Live data from Hacker News

Myna: Monospace typeface designed for symbol-heavy programming languages

github.com

151–160 of 185 posts

Re: Myna: Monospace typeface designed for symbol-heavy programming languages

#151

I love when people make their own fonts (I make one myself), but I wish they had more unique personalities. These days it’s hard to tell one programming font from another.

i'd like one with more extreme braces. a lot of the time, my old eyes find it hard to tell them apart from parentheses. i like OP's font but braces are looking like brackets now.

My eyes miss the 14” 80x25 green phosphor of the IBM 3278.

Re: Myna: Monospace typeface designed for symbol-heavy programming languages

#152

Earlier quoted context omitted.

Where does the design for the text characters come from? Is it based on a mono font you find readable?

Myna's predecessor was a customised version of Source Code Pro. but i've changed a lot of glyphs by borrowing designs and modifying glyphs. so, it may not look like it at all now.

My own font took on the blockyness of the IBM 3270 terminals. Now it has a ton of glyphs those terminals never had, but I tried to remain faithful to its original design principles.

Not everyone likes it, but I do.

Re: Myna: Monospace typeface designed for symbol-heavy programming languages

#153

Earlier quoted context omitted.

Myna's predecessor was a customised version of Source Code Pro. but i've changed a lot of glyphs by borrowing designs and modifying glyphs. so, it may not look like it at all now.

My own font took on the blockyness of the IBM 3270 terminals. Now it has a ton of glyphs those terminals never had, but I tried to remain faithful to its original design principles. Not everyone likes it, but I do.

i totally get what you mean.

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.

Re: Myna: Monospace typeface designed for symbol-heavy programming languages

#154

I think one thing you are running into here in the HN comments is that ligatures as they relate to source code editing can be somewhat controversial among developers who are especially vocal about their preferences. 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 t…

> I think one thing you are running into here in the HN comments is that ligatures as they relate to source code editing can be somewhat controversial among developers who are especially vocal about their preferences

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.

Re: Myna: Monospace typeface designed for symbol-heavy programming languages

#155

Earlier quoted context omitted.

> 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 aliena…

any particular glyph you find surprising in Myna? feel free to open a feature request.

None, and that’s the great feature about it.

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.

Re: Myna: Monospace typeface designed for symbol-heavy programming languages

#156
post #108

Earlier quoted context omitted.

> 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 aliena…

> 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 guid…

> So you're ok with permanent confusion of 0 vs O because "boring/expected" doesn't add a dot for zero?

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.

Re: Myna: Monospace typeface designed for symbol-heavy programming languages

#157
post #69

Earlier quoted context omitted.

And the Haskell example doesn't even include common operators like or or . I would've also expected some fancier arrows like = >>.

if you're looking for those Haskell operators, you'd find them in the huge banner at the start. maybe i should also add them in the illustrations too.

That unfortunately doesn't show them in context.

Re: Myna: Monospace typeface designed for symbol-heavy programming languages

#158
post #108

Earlier quoted context omitted.

> 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 guid…

> So you're ok with permanent confusion of 0 vs O because "boring/expected" doesn't add a dot for zero? 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 no…

> in any of the fonts I use

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!!!

Re: Myna: Monospace typeface designed for symbol-heavy programming languages

#159
Looks pretty nice. I could download and try it but one character I find missing, from the sample, is emdash. I wrote a lot of markdown and many programming typefaces get emdash wrong (it’s hard to tell from a regular dash).

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.

Re: Myna: Monospace typeface designed for symbol-heavy programming languages

#160

Looks pretty nice. I could download and try it but one character I find missing, from the sample, is emdash. I wrote a lot of markdown and many programming typefaces get emdash wrong (it’s hard to tell from a regular dash). 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…

thanks for the feedback. i think the em-dash is not very different in case of this font too. i made the (en-)dash so wide that there was no way to disambiguate within fixed-width constraints. i don't use em-dash at all, so there was no need to disambiguate too.

if 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.

Post reply on HN