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".

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.

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

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.

@SJang1 : we finally triaged this bug and I made a fix for it. Basically, OpenTTD never looked in its search-paths for ttf files, which means only absolute files worked and relative files from your current working directory. This of course clearly is a bug, and as it turns out, an easy fix :)

Fonts are now (with my fix) searched for in all search-paths, so including ~/.openttd, shared-folder, etc. You can now safely use ./myfont.ttf or even myfont.ttf, or in your case ./fonts/NanumGothic.ttf where this file is located next to openttd.cfg, where-ever it might be :)

Still, the advise is to use font-config instead of loading your own TTFs; use for example medium_font = DejaVu Sans, bold instead of a .ttf file. This is more configurable and easier to use. But, it does require you to register your TTF to your OS.

When my PR is approved and merge, this ticket will auto-close. The next nightly will contain the fix, and the next release (1.11) will too!

Thank you for the bug-report!