Earlier 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?
Go fonts
41–50 of 182 posts
Re: Go fonts
#42The serifs are short enough that I couldn't see them all on my regular screen (particularly the right-hand serif on the lowercase 'w'). But on my phone I would be able to see it perfectly well. On a high-DPI screen, the text isn't blurry or anything. They didn't focus on the rendering at all it seems, but made their screenshots in high resolution.
Re: Go fonts
#43Earlier 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?
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?
Re: Go fonts
#44Earlier 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.
Re: Go fonts
#45Re: Go fonts
#46The page itself is set in the proportional version of Go. I found it distracting to read because of the uneven character widths. The majority of the characters (like 'b', 'd', 'f', 'k', 'l', 'o', and 't') are narrow, but some common letters (mainly the 'e' and 'c') are round and wide, with generous space around them. I can't get past the impression that I'm reading paper that wrinkled when it went through the printer…
Re: Go fonts
#47It's pretty hideous. The alphanumerics feel rather slapdash, like this whole thing was put together by the foundary on a Friday afternoon and made to meet the minimum requirements but without much love.
Re: Go fonts
#48This 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.
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 being used for the majority of applications, GTK and Qt. It's already difficult enough getting a consistent UI for applications that use both.
Re: Go fonts
#49"The experimental user interface toolkit being built at golang.org/x/exp/shiny includes several text elements, but there is a problem with testing them: What font should be used?" I am really amused by this opening. I guess it is part of the culture to "recreate" something unnecessary and perhaps better when there is resource to spare.
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.
Re: Go fonts
#50Earlier 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.