1556 / New font installation?

[SlySven]

Putting new fonts in a Mudlet specific (shared between profiles) /fonts/ directory alongside the /profiles/ one is too hacky? Not sure if I really want to get into the intricacies of adding and removing fonts on a per profile basis. This topic only came about because I needed to fix something so that the Mudlet versions without the bundled fonts still load any present font from that place but if Nyyrazzilyss wants to experiment they might want to remember that the font loading only occurs on start up so if they script something to run on package/module installation they may want to check for the presence of the font in that place, and only copy it from their profile/package specific place if it is not present and then advise anyone using their package to restart Mudlet to use that font...

N.B. I still have to finish the package/module overhaul to get sub-directories included in the archive file {I'm stalling on that with handling all the places error messages can be created and making sure they end up in the correct place, I turned over a stone and a whole new set came to like when modules are reloaded - and some other issues are currently in my sights/are at the top of my task stack}... so in the mean time any font files (and any others) will need to be kept in the "staging" area and not placed in a sub-directory to get the current package (module) exporter to work.

[Vadi]

I haven't suggested per profile at all! My take on it is that a package should be able to include a font and it should "just work" - the script should not need to worry about copying fonts to certain locations and ensuring that they're always there.

[SlySven]

Ah, something for future consideration.

[Nyyrazzilyss]

Just played a bit more with this doing it from script - The main problem now with this would probably be while having the script copy the file into the fonts directory does work, the font itself isn't usable until next mudlet restart. (Windows)

[SlySven]

That makes sense, the directory scanning and registering of fonts is one of the steps that is reported on the splash screen and happens really early on (it has to - to make the fonts available before they are potentially used) - this is the case for all OSs, not just Windoze... I suppose we could look to adding registerFont(<pathname relative to Mudlet's fonts base directory or absolute>) to allow a font to be added in after installation, on FIRST usage only {wouldn't be needed afterwards if it is placed "in the right place, so it gets loaded automagically on subsequent runs"}...

[Nyyrazzilyss]

That would probably work perfect: registerFont(path) with path being an offset from the current profile location.

That could allow me to load (and immediately use) a new font file included with the package, without having to copy the file to a new location. If the registerFont command itself were to copy the font into the fonts folder, that should probably be transparent userside - The script would likely still be trying to register the font on startup since that's a whole lot easier then figuring out whether it's been previously installed or not.

Thanks!

[Vadi]

I don't think people should have to mess with the API either. Sure, a function for the edge cases would be useful, but in general you should be able to include a font in a package and it'll "just work", no API calls needed.

[SlySven]

Well, fonts are either system ones or additional ones that the application registers for it's own use. Once a font gets put into the Mudlet font directory (or a single sub-directory below it) then it will be available to ALL profiles from the start of the next run at present. I was suggesting an additional command that only has to be used after a new module that contains it had dropped it in to make it available straight away without a restart.

We could remember the ids returned by int QFontDatabase::addApplicationFont(const QString &fileName) as the fonts are loaded up on startup (or afterwards) and also provide a lua interface to QStringList QFontDatabase::applicationFontFamilies(int id) to give that information back to the scripter so they can check to see which fonts have been loaded (and thus whether the font in a module has already been loaded by a different profile). However that only covers those fonts and not the ones generally provided by the system. Should a scripter/module creator want to use/provide additional font resources I think they are going to have to code cautiously because fonts are such a fundamental part of a GUI and removing them from a running application can mess things up if:

• some other part is still using them;
• the application tries to replace one copy of a font loaded by one profile from a shared module when another profile loads using the same module

tl;dr; I do not think a "just work" approach will "just work" without some API enhancements...

[Nyyrazzilyss]

I haven't look at the Qt structure for loading fonts, but that sounds kind of complex.

Wouldn't it be possible to just have a lua call loadFont(fontname) that

- If font is already loaded, does nothing
- If font is not loaded, copies the provided font file to the fonts directory, then registers it to be available

On subsequent runs, the font would already be in the fonts directory = already have been loaded, so the call to loadFont wouldn't do anything/just return

[SlySven]

Yes, that is the sort of thing I anticipate - however this will only work for the fonts that either Mudlet or modules loaded by profiles would provide - if the font is already provided by the system it is not obvious that we could detect that. However should multiple profiles use the same module which provides it (or multiple modules provide a font with the same {for some not entire clear value of sameness}) then I think we might be able to do something like that. The person who builds a module would have to script something to run on-module installation to indicate where in the module's file structure the font file(s) are to that putative loadFont(fontFileName) function but note that the name the font has is not necessarily going to be what the base of the font file name is...