From the perspective of GlkOte and RemGlk, actually testing if a character was supported would need to take place over the JSON protocol. That would then mean that glk_gestalt would need to be changed to be async, turning what had been a very quick function (that Zarf once told me wasn’t worth caching the results of ) into one that could affect the performance of everything that calls it.
There’s also the complication that the proportional and mono fonts will support different glyphs.
I just don’t see a good way of handling it in GlkOte.
In the code you just pushed to github, you use unichar uniglyph[1] in handleCanPrintGlyph which seems to be just a 16 bit type, so only works for characters in the BMP.
you use unichar uniglyph[1] in handleCanPrintGlyph which seems to be just a 16 bit type, so only works for characters in the BMP
Thanks! unichar is used for all text output in Spatterlight, so that is obviously the problem. I’ll need to take a look at the Zoom code to see how it is done there.
On the plus side, web browsers are generally pretty good about having fallback fonts, so there’s more likely to be something instead of just a question mark or an empty space.
That would then mean that glk_gestalt would need to be changed to be async
You could always special-case gestalt_CharOutput, so that only that check needs to be async and the rest of glk_gestalt stays as it is.
There’s also the complication that the proportional and mono fonts will support different glyphs.
Most browsers running GlkOte will probably implement some kind of glyph substitution, so the answer will likely be the same for every font. As long as one of the installed fonts supports a glyph, it will be printed.
I was going to say that wouldn’t be possible, but I guess it could if glk_gestalt was changed to a macro. But that’s only for C. I don’t think we could do anything for JS.
I would love to be able to use smallcaps font variant instead of bold, so I am excited about this font path lookup thing.
But I would like to suggest a change to the propz font descriptor. I want to use smallcaps for headers and subheaders, but keep bold for user input. The way I can do this is to repurpose propz like this:
Gargoyle uses the correct font but unfortunately propz machine-slants the smallcaps fonts in this case. Maybe I can convince you to change this propz behaviour or provide a neutral user defined propx descriptor that uses the font file as it finds it and not try to slant or bolden it.
Anyway, it would be nice to be able to use the custom fonts like that system wide(not game specific) but not requiring to copy the font files to the root directory (that is the working directory in Mojave for programs run from the launcher), but I realize that requires a substantial overhaul of the font management system for a cross-platform application for just one person, so I am not asking for it .
The way propz works can’t be changed, as there are a lot of config files out there relying on it (implicitly or otherwise). “z” here is just a single-character identifier that means “bold italic”, and if the selected font doesn’t support bold or italic, Gargoyle fakes it, as you’ve noticed.
Your use case is valid, though. You can create a feature request issue at Issues · garglk/garglk · GitHub, and I can look into a way to provide more control over fonts without breaking existing configurations.
I have slept on the problem and found that I have overlooked an obvious fix: opened Fontin-SmallCaps.otf in FontForge, changed OS/2 style map to Bold Italic, regenerated the font, copied the new Fontin-SmallCaps.otf into to root directory. Now Gargoyle thinks it is already bold and slanted and displays it as it is when I use it with propz. No need to waste your time for my specific pet peeve.
Also thank you for showing me that those custom font ini-file entries are possible. I didn’t know that until I saw it here.
) into one that could affect the performance of everything that calls it.
.