Although Simutrans has had TrueType font suport for some time, it was apparently unable to find the fonts installed in my linux system. Looking at the code everything seemed fine, it was looking for fonts in /usr/share/fonts/ (among others). However, all my fonts are installed in subfolders (like /usr/share/fonts/TTF), and Simutrans didn't look at subfolders! This patch fix this, among other things:
- Change the predefined list of font folders. Some are not used nowadays or just deprecated (like ~/.fonts/ which is replaced by ~/.local/share/fonts/) (
- Look for subfolders (only one level deep) at runtime making use of dirent.h (should be present in all unix-like systems)
- Avoid the use of ~ to specify the path of the folder. This was not working, so getenv("HOME") is used instead. I've applied the same logic to Apple and BeOS systems (is anyone still using BeOS?)
My goal with this patch was only to fix the search of fonts without dealing with the implementation of the font system - just by fixing the list of folders it needs. And so it does. However, the implementation of the function which receives the list of folders is... suboptimal. I haven't looked at it in detail, but it seems that the function iterates from the first folder visited to the first not visited folder
everytime it request another folder to search for fonts. For example, if we have:
/usr/share/fonts/
/usr/share/fonts/noto/
/usr/share/fonts/TTF/
1) The first iteration:
Visit /usr/share/fonts/ and end (not visited before).
2) The second iteration:
Visit /usr/share/fonts/ and continue (second time - already visited).
Visit /usr/share/fonts/noto/ and end (not visited before).
3) The third iteration:
Visit /usr/share/fonts/ and continue (third time - already visited).
Visit /usr/share/fonts/noto/ and continue (second time - already visited).
Visit /usr/share/fonts/TTF/ and end (not visited before).
And so on! Which each additional folder loading times get exponentially worse (it just wasn't noticeable before because it didn't have to iterate much), so the next big thing would be to solve this. But that's work for another patch.
Please use tabs for indentation, not spaces.
There is also a bug: result is a stack variable; after the function returns, the returned pointer references invalid memory.
Quote from: ceeac on April 17, 2020, 06:07:45 AM
Please use tabs for indentation, not spaces.
There is also a bug: result is a stack variable; after the function returns, the returned pointer references invalid memory.
Weird, I've always used tabs for indentation. Something went wrong with my editor, I guess. This time it is all tabs.
You are right, I've also changed it so it reserves the memory it needs.
On rasberrian, the ~/.font/ folder seems still be in use according to google. Some for other distros with the other paths. With Linux, there are really often no bets and the LSD never ever took off. Simply remove the path will break it on some of those distros.
I added a slightly different code without memory leak that will also iterate one level down through al;l folders, and each folder exactly once in r9041. Please try it out.
Quote from: prissi on April 23, 2020, 02:43:19 PMPlease try it out.
It is working perfectly! I can finally play with Comic Sans :D
(https://i.imgur.com/IUsiNUb.png)
One thing to note is that the path displayed in the GUI is not correct at all. It is appending the simutrans font folder (I guess) before the actual path (in the above image, /usr/share/fonts/TTF ). But that bug corresponds to another code not related to this patch, I guess.
EDIT: Wait. Since your patch doesn't include the ~ path fix (using
getenv("HOME") instead of ~ to specify the home folder), Simutrans is not looking for fonts in ~/.local/share/fonts/ (nor in ~/.fonts/). Please review this (>人<；)
I have an /etc/fonts/fonts.conf that lists where fonts are, among other things. It is apparently part of something called fontconfig. I don't know how widely available that is.
Not too widely, it seems, and it depends strongly on the release.
I do not understand why ～ is not working. Anyway, test r9053
Quote from: prissi on April 26, 2020, 01:13:39 PMI do not understand why ～ is not working. Anyway, test r9053
It is still not working :/
Sorry, there was a typo. So the string was composed correctly, but then the original wrong one was fed to opendir. r9065 should fix this. Please try again.
Quote from: prissi on May 05, 2020, 12:25:07 PM
Sorry, there was a typo. So the string was composed correctly, but then the original wrong one was fed to opendir. r9065 should fix this. Please try again.
It is still not finding my fonts located at ~/.local/share/fonts
But the path is definitvely passed to the search.I will try it in a virtualo amchine to see what happens. Maybe opendir does not like to closing slash?
Quote from: prissi on May 08, 2020, 02:07:09 AM
But the path is definitvely passed to the search.I will try it in a virtualo amchine to see what happens. Maybe opendir does not like to closing slash?
I've added some printf to debug and I have found this:
Quotetrying the path: /home/rober/simutrans/.fonts/
trying the path: /home/rober/simutrans/.local/share/fonts/
The function you used, *dr_query_homedir(),
does not return the home user directory, but the simutrans "home" directory.
Ups, ok try r9075. I added a "../" after the homedir. I hope this is enough.
Quote from: prissi on May 08, 2020, 01:32:40 PM
Ups, ok try r9075. I added a "../" after the homedir. I hope this is enough.
Not a valid solution it seems xD
Quotetrying path: /home/rober/simutrans/../.fonts/
trying path: /home/rober/simutrans/../.local/share/fonts/
I think you will need to implement a function that actually returns the home user directory.
why not make this configurable by user? i.e. let them specify the path to their fonts in simuconf.tab or another text file.
In principle, all fonts can be compied into the simutrans directory anyway ... This seems rather the system directory for fonts (which I find stange, since a multi user system storing its fonts locally seems counterintuitive ... Anyway, now using getenv, sinc the ~ problem only occurs on Unix (and maybe Amiga OS ,,, ?) in r9078
Quote from: prissi on May 09, 2020, 12:28:48 PMAnyway, now using getenv, sinc the ~ problem only occurs on Unix (and maybe Amiga OS ,,, ?) in r9078
This finally solves it.
BUT I've noticed that it is not finding fonts in parent directories inside the home user directory (~/.local/share/fonts and ~/.fonts), only in subdirectories. It's weird because it is finding fonts in parent directories inside system directories (like /usr/share/fonts). Weird.
Is should not have worked at all, since it returned again the path with ~ to the folder search. Fixed (finally) hopefully in r9082.
Quote from: prissi on May 10, 2020, 01:02:09 PM
Is should not have worked at all, since it returned again the path with ~ to the folder search. Fixed (finally) hopefully in r9082.
Finally it is working as intended. Good job!