Nice. it looks interesting.
Do i need it? don't know. Will it be useful? might be.
I don't see any reason to complain. It's a completely free font people.
I see no downsides to this.
Go fonts
61–70 of 182 posts
Re: Go fonts
#62Why wouldn't they just use Google Droid? Strange.
From the comments here so far, it seems really important that they could be under the same permissive license as the rest of the project.
Another reason to not just use Google fonts is to make sure they do not - even if unwittingly - give an impression that the Go language is controlled by Google. This is an open source initiative (at least in spirit) and needs to make choices akin to its roots.
Re: Go fonts
#63Earlier quoted context omitted.
Why is it not possible to just use the system font for these UI elements?
> there is a problem with testing them Maybe they're comparing the rendering of the UI toolkit against reference bitmaps, so always need to use the same font, so want to distribute the font in the repository?
That's what Ahem is for: https://www.w3.org/Style/CSS/Test/Fonts/Ahem/
Re: Go fonts
#64Love that screenshot. Reminds me of rebuilding Emacs, opening it up, and immediately remembering that I forgot to enable Xft or something.
Re: Go fonts
#65Earlier quoted context omitted.
Font licensing is complicated and Chuck is a friend. It was very important to us that Go programmers be unencumbered when distributing programs that use this font.
Why is it not possible to just use the system font for these UI elements?
The blog post explicitly stated testing as the reason why Go needed a font that could be freely redistributable.
Re: Go fonts
#66Earlier quoted context omitted.
Why is it not possible to just use the system font for these UI elements?
While possibility is another question entirely, from a design standpoint I can definitely see why an app might want to bundle the font together with the rest of the package. It guarantees a homogeneous user experience.
homogenous for who?
for the end-user? nope, because this application doesn't look like the rest of their applications, and ignores their preferences.
for the developer? yes, because their application will look the same regardless of platform it's deployed on.
But as we've learned with Responsive Design, having a single "my way" of presenting an interface regardless of end-user preferences and device capabilities is a Bad Thing. Interfaces need to be configurable by the user not fixed by the designer.
I like the font, though. Makes my code look sexy, and that's hard to do ;)
Re: Go fonts
#67Earlier quoted context omitted.
While possibility is another question entirely, from a design standpoint I can definitely see why an app might want to bundle the font together with the rest of the package. It guarantees a homogeneous user experience.
Being self consistent is not important, being constant with the environment is important.
That ship sailed long ago. I fired up the mail client in windows 10 for the first time in a while yesterday and it had this weird galaxy background. It looked like an access app an amateur would throw together.
Re: Go fonts
#68This reminds me of Java applications that you can immediately tell are Java because of the weird font. I don't see an advantage over using native system fonts. As far as I know you don't need a license to use fonts installed on the system running the application. Why does the font need to be bundled? The wide spread adoption of this is going to make go programs stick out like a sore thumb.
Jetbrains are the only example I've come across that provide an option for native UI elements in Java apps. To expand on your point. What about the combination of fonts and UI elements I've chosen for my desktop environment. Will this new UI toolkit ignore those choices I've made and stick to using their own font? It's bad enough already, for example on linux, where there are already two incompatible UI toolkits bein…
What options for native UI does IDEA provide? It's mostly a Swing app.
Re: Go fonts
#69I see there's a black-on-white Gopher hiding at U+F800 in the middle of the BMP Private Use area (U+E000..U+F8FF). Besides that, only Latin, Greek, Cyrillic, and a few box drawing glyphs are provides. Are there any plans from the Go Fonts team to provide glyphs for all characters in the BMP, and beyond?
Re: Go fonts
#70I love that they actually included Bigelow's explanation of each decision made. So often (especially in the realm of programming fonts, it seems) decisions on letter forms in new fonts seem to be made "because it looks nice", but there is, in fact, a science behind it all. Indeed, Go Mono ticks every item I look for in a programming font (one of only 2 or 3 programming fonts that does):
- slashed 0
- easy differentiation of 1, i, l, and |
- open lower-case g
- proper kerning and adequate width of r, n, and m
Unfortunately, I don't see myself switching away from Menlo to Go Mono for a silly and purely aesthetic reason: 5 point raised baseline * . Yes, yes...I know that's how pretty much every font has done * since forever, but after working with the vertically centered, six-pointed * in Menlo (and SF Mono), it's hard to go back.