"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.
I help maintain/develop an app that allows users to draw and simulate logic circuits on a canvas. Text plays a minor but important role for labeling various components, showing bit and hex values, etc. The app uses system fonts, and it's a huge mistake. The sizes and exact layout and connectivity of various logic blocks depends on text size, and when that changes (and it does from platform to platform), it leads to lots of subtle and hard to notice errors. I've spent a lot of time tracking down every logic dependence on character width and making those all platform-independent heuristics instead of using the actual font metrics. Which makes the UI often look terrible (but at least it is a consistent and functionally correct terrible). I would much rather the app bundle a freely redistributable font and be done with it.
I don't know what toolkit you are using, but when I want to place text with e.g. SDL_ttf, I can compute the width and height of a string knowing its font. IMO relying on a specific font is exactly like throwing magic numbers in a codebase. I can understand that it simplifies things, but it doesn't feel right.
The sizes and exact layout and connectivity of various logic blocks depends on text size
I have used many schematic editors and they all handle different font sizes correctly, even letting you choose different fonts and styles within the same document. It is not difficult to figure out how much space a piece of text takes up, and scale the other elements to fit.
If the actual connectivity of the parts in your schematic changes with font size, then I will quite frankly say "you're doing it wrong".
It seems to me that having a specific UI toolkit font would not help you in your case.
If Go maintainers decide to change the font metrics you will have the same problem. Distributing your own font (as you have mentioned) is the right way to go.
If the Go maintainers change metrics, you can still distribute the old version, or even modify the new version back to the metrics you want and distribute the result. That's the advantage to friendly licensing.
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.
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 ;)
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.
System native doesn't neccesaraly mean high quality or standards compliment. Take windows control panel as an app which still has zero effort put into standardisation, I get that it's pretty much a dead man walking but they could at least try polish it up.
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?
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.