Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load font from openttd config file directory, not from working directory. #7830

Open
SJang1 opened this issue Nov 12, 2019 · 4 comments
Open

Load font from openttd config file directory, not from working directory. #7830

SJang1 opened this issue Nov 12, 2019 · 4 comments

Comments

@SJang1
Copy link

@SJang1 SJang1 commented Nov 12, 2019

Version of OpenTTD

4eab70f

Expected result

Load fonts from openttd configuration file directory

Actual result

Load fonts from working directory. (even using -c option)

Steps to reproduce

I am using ./fonts/NanumGothic.ttf as a font config (in openttd.cfg, placed located where openttd is installed(built)).

small_font = ./fonts/NanumGothic.ttf
medium_font = ./fonts/NanumGothic.ttf
large_font = ./fonts/NanumGothic.ttf
mono_font = ./fonts/NanumGothic.ttf

When I try opening openttd on other directory where openttd is not installed, getting this kind of error and loads as a sprite font.

$ ./bin/openttd
Unable to use './fonts/NanumGothic.ttf' for medium font, FreeType reported error 0x1, using sprite font instead
Unable to use './fonts/NanumGothic.ttf' for small font, FreeType reported error 0x1, using sprite font instead
Unable to use './fonts/NanumGothic.ttf' for large font, FreeType reported error 0x1, using sprite font instead
Unable to use './fonts/NanumGothic.ttf' for medium font, FreeType reported error 0x1, using sprite font instead
Unable to use './fonts/NanumGothic.ttf' for small font, FreeType reported error 0x1, using sprite font instead
Unable to use './fonts/NanumGothic.ttf' for large font, FreeType reported error 0x1, using sprite font instead
Unable to use './fonts/NanumGothic.ttf' for medium font, FreeType reported error 0x1, using sprite font instead
Unable to use './fonts/NanumGothic.ttf' for small font, FreeType reported error 0x1, using sprite font instead
Unable to use './fonts/NanumGothic.ttf' for large font, FreeType reported error 0x1, using sprite font instead

but when I open openttd from the directory where it is installed, all fonts load correctly, works as expected.
or even if I make and add font at $(Working-dir)/fonts/NanumGothic.ttf it loads correctly

@floodious
Copy link

@floodious floodious commented Jan 11, 2020

Which OS are you using? Generally the dot "." and dot-dot ".." symbols are handled entirely by the OS/file system, not client applications. So although there are mechanisms for a client application to resolve the full path from one containing such symbols or links it is generally considered bad practice to do so where not absolutely necessary.

Is it possible for you to use an absolute full path ("/home/user/fonts/NanumGothic.ttf") instead?

Being bothered by these things having no standardized nomenclature I've ever found:
https://en.wikipedia.org/wiki/Path_(computing)

It seems unless I'm mistaken, there has never been a unifying standard specifying these symbols or the hard-links they represent within software file systems. If true, this would explain why there is no standardized nomenclature or implementation shared in common between systems. We've grown used to the Unix (Linux, MacOS) way of doing things along side MS-DOS on our most common platforms but realistically you can not expect these symbols to work in any standard way across different target platforms.

So for that reason you must remember when you're using these systems and their associated symbols you are communicating via the client application to the underlying OS and its interfaces. If a client application such as OpenTTD decided to "muck with" paths and filenames it was handed by the user it might cause failures to occur with more esoteric system-dependent features such as network file systems, hard or soft-links and other unexpected symbols appearing in the path.

When you tell the OS "./myfile", you're instructing it "current working directory/myfile".

@SJang1
Copy link
Author

@SJang1 SJang1 commented Jan 15, 2020

It's possible to use full path instead, but i'd prefer to use relative path.
I was using Fedora 31

I know that ./myfile is (current working dir)/myfile, but I've wanted to start the relative path at the config file directory.
so that, my config file is now using relative path, I wanted even not starting from actuall openttd and openttd config folder, everything works great, but it didn't, so I've opened this issue.

@floodious
Copy link

@floodious floodious commented Jan 16, 2020

If you want to use the search path defined by the client application, you must not include a path.

For example:
"small_font = NanumGothic.ttf"

I haven't looked closely at the current implementation yet, but it seems to search the system font paths in such a case and successfully loads the font I select. This does not work for me in previous versions (1.9.3) but does load the font successfully from the system path on the current working version.

Some applications use a specific symbol in these cases ("$config_dir") and some rely upon a path defined elsewhere to use during the search. It seems to me that these behaviors are handled within freetype, looks to be in fontcache.h (?) but someone with more knowledge could probably explain more clearly.

I agree that the configuration directory should be within the path used when searching for the font, but some ambiguity will exist no matter what in cases where the elements of the search path include multiple "/font/" directories, where some priority should be established.

In C, the preprocessor uses #include "path" to denote where the current folder or user-defined path should take precedence and #include <path> where the system path should take precedence. Even so, the actual behavior you get depends upon the preprocessor being used and its configuration, and whether there are multiple files or paths with the same names which create ambiguity and lead to first-found selection by precedence.

https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html

@floodious
Copy link

@floodious floodious commented Jan 16, 2020

Part of the reason font resources are defined by their identifier (name) rather than file is that a font family can exist with many variations such as bold, narrow and italic. These can usually be selected by specifying the name and variant properties including size and other parameters.

Documentation I've been able to find:
https://wiki.openttd.org/Unicode
https://wiki.openttd.org/FAQ_troubleshooting#My_User_Interface_is_too_small_to_read_.2F_My_font_is_unreadable_or_faulty

Neither of these documents go into any detail about the actual implementation or search path used. It may simply be impossible to select a font by filename without using a full absolute path, and there is nothing wrong with that.

The sole reason you might want to select a font from a defined "/fonts/" folder is if you want to use a font specifically in OpenTTD without installing it on the system, in addition to want to select sub-types of the font by name without specifying the absolute path to each individual file. This could be solved by defining a "/fonts/" resource path that could be automatically loaded on startup along with the fonts from the system path. That would allow fonts to be selected from a list within the application. That seems to require all new implementation, however.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.