Please include the flowing when reporting a bug:
- windows 10 home 64 bit (10.0, build 18363)
- FontBase 2.16.6
- when I activate a google font (ex: cairo) it say could not activate 2 fonts (regular and semibold).
Please include the flowing when reporting a bug:
Is this happening to every Google font or only these specific fonts?
@dominik I’m getting similar behavior on Ubuntu 20.04.2. My scenario is a little bit different though. I have a collection of fonts that are stored in Dropbox and synced across multiple devices (macOS Big Sur and Windows 10 machines).
When I initially installed FontBase on Ubuntu, I was able to activate my fonts with no problem. However, as soon as I shut down the box and restarted it, the fonts became deactivated. Ever since when I try to activate any of my personal fonts, I get the
Could not activate font notification.
For reference, Mac and Windows are still operating normally. I’m still new to the Linux world, so if there’s a way to be able to provide some logs, I’d be happy to do so. I would just need a little guidance.
Please let me know, thanks!
Do you have all the necessary rights to write into system directories on Linux? The folder ~/.fonts/FontBase should be existing and writable.
@dominik after looking at my rights, for the
~/.fonts/FontBase folder, they weren’t set to being writable. so I changed the permissions, deleted the link files for the fonts that were underneath it, and I was finally able to activate my fonts. however, after I reactivated the fonts, I noticed that permissions for
~/.fonts/FontBase went back to a non-writable state. it seems that FontBase changed it on its own? I haven’t restarted my machine so I’ll see if the activations hold after that. I’ll update you with a status once I know.
@dominik welp, unfortunately, I bring some bad news. I just restarted my machine and as soon as Fontbase started up (it’s set to launch on startup), I immediately got a notification that all of my previously active fonts were deactivated. maybe this has something to do with the fact that I’m syncing and activating the fonts from my Dropbox folder, but everything works fine on my Mac and Windows machines. I’ll play around with it some more.
Hello @metal-gabe, thank you for bringing this up.
My first guess would be that the system is starting up the apps in such a sequence that FontBase is ready before Dropbox is (possible downside of being way too fast ), so the font files in Dropbox are not yet ready at that time and FontBase deactivates them because it looks to it like files are gone from the system.
If this is indeed the case, not sure if there is any way FontBase can tell the system to launch it after Dropbox is completely ready.
We’ll have to investigate this in more detail to see how and if this is fixable.
Hope this helps.
Hi, @yuriy thanks for responding, I kind of see what you’re saying, but my Dropbox files are synced locally to my machine. They should be available as normally stored files on the HDD as soon as the system boots up. Why would FontBase boot up faster on Linux than it would on Mac or Windows if the boot order were the case?
Thanks for such a quick followup @metal-gabe.
I was just able to test this on a Windows 10 setup. FontBase launches well before Dropbox and everything still works well, just as you said. Unfortunately I don’t have an access to a Linux machine at the moment.
The sequence might depend on many factors (number of applications installed, hardware, internal OS design), but it seems it shouldn’t be an issue if files are 100% local and not online-only (premium Dropbox feature).
For some reason FontBase’s check on whether the files exist fails on your Linux machine on startup.
In your scenario with both Dropbox and FontBase running on startup (on Linux), does font activation/deactivation work if you try to use FontBase normally after the initial deactivation message and without restarting it?
@yuriy I think I may have found something. I was looking at the locations where FontBase stores its files on Mac and Linux/Ubuntu and noticed a difference.
On Mac, it appears that FontBase is making actual copies of the font files from my Dropbox for the ones I’ve activated.
However, on Linux, it seems that FontBase is creating symlinks/aliases inside of the
~/.fonts/FontBase directory for the ones I’ve activated.
If I delete these files in Linux, I am able to reactivate my fonts, and they work until I restart my computer. To your point about FontBase possibly being too fast and booting up before Dropbox, the situation of symlinks might break because the files aren’t “ready” in this scenario.
I haven’t yet checked my Windows machine to see if FontBase is using aliases there or not.
If it’s true that Mac is using actual copies and Linux is just using symlinks, is it possible to update the Linux version to create hard copies as well?
Hopefully, this is the cause of the issue and it can be resolved within the app. It wouldn’t be fun to have to constantly delete/reactivate fonts or to just leave my computer on forever.
Thanks for your quick responses and help on this!
@metal-gabe thank you so much for your investigation.
This does make a lot of sense and the initial guess doesn’t look that ridiculous now
I was just able to confirm that we will be implementing this change in the upcoming release, please bear with us until it rolls out.
Thank you again for taking the time to get to the bottom of this
awesome, that’s good to hear! thanks @yuriy, I was happy to help.