so, for a first attempt, I'd tell linux users only to "hey, install this yourselves", they'll even be happy :)
Yes. This is simpler by far.
Note: it was suggested in another mail to use the PdFontLoader which is a workaround for loading local fonts on Windows. This would work for within a GUI plugin, no external required, but I would not assume the font loader and it's calling style will stay consistent as it's not really a "public API" part of there GUI. I would personally try a GUI plugin first which just runs the TK calls to load whatever font you want, then it could be used either by retrieving the font instance or via the font-family name. After that, however, you don't really have a way too *use* it directly unless you are sending actual Tcl strings around...
windows is pretty covered and we can see if we can adapt mac to load an external that can read a key inside a given Info.plist
Nope. This will not work. It's only a convenience when the app bundle is started and not a dynamic option which can be changed or invoked after the app is running.
The main patch canvas uses the single font specified by -font-face when rendering. The IEM GUI object labels have 3 font options, but none are settable, ie. replace or add a new option. It would probably be difficult to modify the canvas to work with "rich text" where fonts and styles could be mixed and matched. Maybe I'm wrong on this, but I'm not sure if anyone has tried with the Tk GUI itself, more probably with one of the forks.
yeah, rich text and multiple fonts would be nice to design documentation, but something related to this is happening, where if you have unicode glyphs installed in your system, Pd seems to find them even though they're not in DJVSM
In the end, you still have the same problem: providing *local* fonts, not installed on the system, to Pd and "rich text" which is harder as I don't believe Tk has this as a built in option, unique southing like macOS's Cocoa API NSTextView which supports attributed strings.
Honestly, this is a bunch of extra work to provide a small set of symbols whereas there are quire a number of other issues which, I feel, take higher priority of messaging/.development bandwidth.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/