[PD] Pd-list Digest, Vol 191, Issue 33
danomatika at gmail.com
Mon Feb 15 10:18:09 CET 2021
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list