Short answer: IOhannes is right. If you want to use a special font, ask the users to install it on their system, then (re)start Pd with -font-face FONTNAME. You could include a ttf file with your project's download and some instructions on how to set things up but you can't pass in a .ttf and have Pd load & use it.
Long answer:
To summarize IOhannes: the fonts available to Pd are those installed on your system and found by the OS. Then you choose the font by the name the system uses to find it which is usually defined in the font file then the system loads it. If there is confusing, it may be coming from the fact that we do include the .ttf files for Windows and macOS, but this is misleading as they are still handled by the system (see below).
The Pd GUI does not load a font file directly (from ttf, otf, etc), and this is good, as things like font caching are good to have, especially when it's handled by the system for you.
As mentioned in the fonts/README.txt in the Pd sources, DejaVu Sans Mono is now standard on most platforms (Menlo is a very close replacement on macOS for now) because:
* Linux: the font is a dependency, ie. installing pd via apt-get also installs DVSM
* Windows: the font file itself is shipped with Pd and loaded into Tk using a custom Tcl extension written in C which calls the Windows API to have the system load the font file and make it available, this way people don't have to manually install DVSM to their system when using Pd
* macOS: the font file itself is shipped within the Pd .app bundle and the system reads a key inside the Info.plist which tells it to find and load that file when the Pd .app is opened.
The "safe fonts" like Courier, Times, etc are only so in that there is a pretty good change they will be installed on most systems by default.
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.
Message: 2Date: Mon, 18 Jan 2021 21:43:57 +0100From: IOhannes m zmölnig <zmoelnig@iem.at>To: pd-list@lists.iem.atSubject: Re: [PD] unicode symbols and PdMessage-ID: <F9AA55FF-E583-4EE6-80F2-846270B2B1EC@iem.at>Content-Type: text/plain; charset=utf-8Am 18. Jänner 2021 20:24:27 MEZ schrieb Alexandre Torres Porres <porres@gmail.com>:Em dom., 17 de jan. de 2021 às 23:12, Alexandre Torres Porres <
porres@gmail.com> escreveu:
Ok, I know it's coming from somewhere else, and that's not the point.
Maybe a better question is to just make sure that this indeed happens
(that
the Pd will look elsewhere in your fonts to see if you have a bass
clef or
whatever else is missing in DejaVu). I
Pd doesn't do anything like that.in fact, most applications don't do anything like that.fonts are a *hard* problem, that's why these problems are typically solved centrally (on the toolkit level (eg Tcl/Tk) or even lower).there are of course exceptions to this: eg Gem handles the fonts on its own (using a library; I'm not crazy enough attempting to handle fonts myself).as a rule of thumb: if you don't specify the font-file directly (eg `/path/to/DejaVuSans-Mono.ttl`) but rather the font name (eg "DejaVu Sans Mono"), then you are working with a high level interface that will use multiple fonts to render a glyph.
Well, this
price question: when selecting a font for Pd (using the `-font-face` cmdline option), do you specify the font by filename, or by the font-name?
mfg.hft.fsl
IOhannes