"no default font found" issue on FreeBSD

[nunotexbsd]

While this is issue is being discussed on lapce/lapce#2748 ,
could we have some opinion on fontdb-0.14.1 used in https://github.com/lapce/lapce 0.3.1 about the error, "no default font found"

Same problem was found on some linux distros, but we can find a way of fixing it on FreeBSD.

Any help is welcome,

Thanks

[RazrFalcon]

load_system_fonts supports only Windows, Linux and macOS. See the docs.
If you want to add FreeBSD - you have to update this function. I never used FreeBSD, so I cannot help you here.

[ierturk]

I'm dealing with the same issue regarding Slint on the FreeBSD 14.0-RELEASE. The command cargo build finished succesfully by setting the environment variable FONTCONFIG_FILE as follow.

$ export FONTCONFIG_FILE=/usr/local/etc/fonts/fonts.conf
$ cargo build

Hope this being help

Also with following setting in the VSCode-OSS on the FreeBSD 14.0-RELEASE, the same effect can be gotten

{
    "rust-analyzer.server.path": "~/.cargo/bin/rust-analyzer",
    "rust-analyzer.cargo.extraEnv": {
        "FONTCONFIG_FILE": "/usr/local/etc/fonts/fonts.conf"
    },
    "terminal.integrated.env.linux": {
        "FONTCONFIG_FILE": "/usr/local/etc/fonts/fonts.conf"
    }
}

[nunotexbsd]

@ierturk

On lapce port 0.3.1 ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274852 )

CARGO_ENV+= FONTCONFIG_FILE=/usr/local/etc/fonts/fonts.conf
and
MAKE_ENV+= FONTCONFIG_FILE=/usr/local/etc/fonts/fonts.conf
result: "no default font found"

lapce ships and compiles 2 fondb crates, 0.14.1 and 0.16.0 and I patched the two:

--- cargo-crates/fontdb-0.14.1/src/lib.rs.orig  2023-12-26 12:01:12 UTC
+++ cargo-crates/fontdb-0.14.1/src/lib.rs
@@ -442,9 +442,9 @@ impl Database {
             };

             if read_global {
-                let _ = fontconfig.merge_config(Path::new("/etc/fonts/local.conf"));
+                let _ = fontconfig.merge_config(Path::new("/usr/local/etc/fonts/fonts.conf"));
             }
-            let _ = fontconfig.merge_config(Path::new("/etc/fonts/fonts.conf"));
+            let _ = fontconfig.merge_config(Path::new("/usr/local/etc/fonts/fonts.conf"));
         }

         for fontconfig_parser::Alias {

and

--- cargo-crates/fontdb-0.16.0/src/lib.rs.orig  2023-12-26 12:04:32 UTC
+++ cargo-crates/fontdb-0.16.0/src/lib.rs
@@ -443,9 +443,9 @@ impl Database {
             };

             if read_global {
-                let _ = fontconfig.merge_config(Path::new("/etc/fonts/local.conf"));
+                let _ = fontconfig.merge_config(Path::new("/usr/local/etc/fonts/fonts.conf"));
             }
-            let _ = fontconfig.merge_config(Path::new("/etc/fonts/fonts.conf"));
+            let _ = fontconfig.merge_config(Path::new("/usr/local/etc/fonts/fonts.conf"));
         }

         for fontconfig_parser::Alias {

result: "no default font found"

Maybe I missing something...
Could you have a give a try at PR above?

Thanks

[nunotexbsd]

Sorry, I closed this PR by mistake

[RazrFalcon]

fontdb doesn't care about FONTCONFIG_FILE or fontconfig in general. See how load_system_fonts function is implemented. You have to patch it to load the system fonts directory(s).

Hmm... I guess we do support FONTCONFIG_FILE after all, but you still have to patch load_system_fonts to support FreeBSD.

[ierturk]

This the implementation in Slint and related discussion

https://github.com/slint-ui/slint/blob/d1529af3cc079c724fcbe1a4101a14013eda8b76/internal/common/sharedfontdb.rs#L26

slint-ui/slint#1240

[nunotexbsd]

Ok, I see in lib.rs:

    /// Attempts to load system fonts.
    ///
    /// Supports Windows, Linux and macOS.
    ///
    /// System fonts loading is a surprisingly complicated task,
    <snip>

#[cfg(target_os = "windows")]
{
}

#[cfg(target_os = "macos")]
{
}

#[cfg(target_os = "redox")]
{
}

#[cfg(all(unix, not(any(target_os = "macos", target_os = "android"))))]
{
}

Any sugestion for a new 'freebsd' block or use a existing one so I can patch and test?

[RazrFalcon]

Hm... right now we're treating all Unixes as Linux (except for macos and android), which is probably incorrect. Or at least overly generic.

Either way, right now building on FreeBSD with fontconfig build feature enabled you should load fonts just fine. Or FreeBSD doesn't use fontconfig? If so, at what locations does it store fonts?
According to quick googling, FreeBSD uses the same fonts location as Linux, aka /usr/local/share/fonts. So it should work just fine...

Can you check you're building fontdb with fontconfig feature enabled? If so, then check the load_fontconfig function to figure out why the default config isn't resolved.

The fontconfig root config file resolving logic is very convoluted, like everything in fontconfig, therefore we might simply not covering some edge case.

[nunotexbsd]

@RazrFalcon

lapce 0.3.1 is finally running and fontdb needs:

-            let _ = fontconfig.merge_config(Path::new("/etc/fonts/fonts.conf"));
+            let _ = fontconfig.merge_config(Path::new("/usr/local/etc/fonts/fonts.conf"));

Also FONTCONFIG_FILE is an environment variable, not some kind of build parameter.

It was nice to have some build variable that controls this config.

[volkertb]

@RazrFalcon

lapce 0.3.1 is finally running and fontdb needs:

-            let _ = fontconfig.merge_config(Path::new("/etc/fonts/fonts.conf"));
+            let _ = fontconfig.merge_config(Path::new("/usr/local/etc/fonts/fonts.conf"));

Also FONTCONFIG_FILE is an environment variable, not some kind of build parameter.

It was nice to have some build variable that controls this config.

In Clear Linux OS, the file is located in yet another path: /usr/share/defaults/fonts/fonts.conf

Simply making hard-coded assumptions about the location of fonts.conf does not seem to be the proper OS- and distro-neutral way to go. The path really needs to be properly detected or resolved.

[panekj]

The distro/OS neutral way of doing this is having the config in /etc, that the distro or OS you are using is deliberately not doing that is fault of their own.

[volkertb]

It is explained in this answer. Apparently, it has something to do with the fact that Clear Linux OS is a stateless distro.

Also, according to this answer in the same thread, libfontconfig can be used to resolve the file in a distro-independent manner.

The environment variable FONTCONFIG_PATH is mentioned as well, but lapce appears to ignore that environment variable, even when I explicitly point it to /usr/share/defaults/fonts/fonts.conf.

Apparently, Alacritty used to have the same issue on Clear Linux OS, but that eventually got fixed, since I've been able to build and run Alacritty on this OS just fine.

@panekj Do you have any reference to documentation that defines /etc/fonts/fonts.conf as the "official" standard Linux or POSIX location for this file?

[panekj]

Do you have any reference to documentation that defines /etc/fonts/fonts.conf as the "official" standard Linux or POSIX location for this file?

https://www.freedesktop.org/software/fontconfig/fontconfig-user.html

[volkertb]

Do you have any reference to documentation that defines /etc/fonts/fonts.conf as the "official" standard Linux or POSIX location for this file?

https://www.freedesktop.org/software/fontconfig/fontconfig-user.html

Fair enough. And I just checked, and Clear Linux OS doesn't have the environment variable XDG_CONFIG_HOME defined out of the box either.

[RazrFalcon]

@volkertb

Simply making hard-coded assumptions about the location of fonts.conf does not seem to be the proper OS- and distro-neutral way to go. The path really needs to be properly detected or resolved.

That's Linux for you. There is no such thing as "default".

[RazrFalcon]

@nunotexbsd great. Then you can replace the current line with:

#[cfg(target_os = "freebsd")]
{
    let _ = fontconfig.merge_config(Path::new("/usr/local/etc/fonts/fonts.conf"));
}

#[cfg(not(target_os = "freebsd"))]
{
    let _ = fontconfig.merge_config(Path::new("/etc/fonts/fonts.conf"));
}

[RazrFalcon]

As for Clear Linux, just set FONTCONFIG_FILE or XDG_CONFIG_HOME in your .bashrc or whatever you use.

[nunotexbsd]

I think we can close this PR now.
fontdb works as expected and paths are respected.

Thanks all

[RazrFalcon]

@nunotexbsd So what was the final solution? Setting FONTCONFIG_FILE?

[nunotexbsd]

@nunotexbsd So what was the final solution? Setting FONTCONFIG_FILE?

I was looking for solutions for packagers (poudriere) and using src fontconfig.merge_config will give me the ability to have a pkg working without FONTCONFIG_FILE or XDG_CONFIG_HOME vars configured or not by end user.

If fondb added a build option to do this adjustment, I used that, but since it's using corrects fonts path, I will patch it to adjust to FreeBSD.

Just a side note: FreeBSD respects paths too, but it adds a PREFIX that separates files from OS to the others installed by user (src, pkgs, etc)

/usr/local/etc/fonts/fonts.conf == $PREFIX/etc/fonts/fonts.conf, where PREFIX defaults to /usr/local.

Just an example, we could delete /usr/local from system and continue to have a cleaned OS system.

[panekj]

Adding a compile-time option to specify prefix sounds like most sensible way to resolve that, as package/system maintainers we would like for all packages to be integrated with system libraries/software.

Adding hardcoded paths might resolve it as well, but its prone to breaking anytime downstream changes paths.

[RazrFalcon]

Adding a compile-time option to specify prefix sounds like most sensible way to resolve that

Except it's not that easy to do in Rust. And I still have no idea what path exactly have to be configured. Once again, I don't use FreeBSD. If someone would send a working patch - I might merge it.

as package/system maintainers we would like for all packages to be integrated with system libraries/software

It's not my fault that fontconfig sucks. It's way too slow, limited and clunky.
And before you ask, yes, I've tried using fontconfig before: servo/font-kit@adff939

[panekj]

Adding a compile-time option to specify prefix sounds like most sensible way to resolve that

Except it's not that easy to do in Rust. And I still have no idea what path exactly have to be configured. Once again, I don't use FreeBSD. If someone would send a working patch - I might merge it.

But you don't have to use FreeBSD, nor know the absolute paths. It's enough that we know etc/fonts/{local,fonts}.conf are the config file paths.

    #[cfg(all(
        unix,
        feature = "fontconfig",
        not(any(target_os = "macos", target_os = "android"))
    ))]
    const fn prefix() -> &'static str {
        if let Some(prefix) = option_env!("FONTDB_PREFIX") {
            prefix
        } else {
            "/"
        }
    }

            if read_global {
                let _ = fontconfig.merge_config(Path::new(Self::prefix()).join("etc/fonts/local.conf"));
            }
            let _ = fontconfig.merge_config(Path::new(Self::prefix()).join("etc/fonts/fonts.conf"));
        }

It's not my fault that fontconfig sucks. It's way too slow, limited and clunky.

No one is blaming you, I'm just explaining the motivation behind compile time option.

[panekj]

I also noticed another issue, fontconfig feature limits itself to unix excluding macos and android (while also having a comment // Linux but the cfg doesn't target linux) but fontconfig works on other platforms whether that's *BSD, Windows, macOS or other.
While those might be not the most popular platforms to use fontconfig on, they certainly are a possibility. It would be good to either document that limitation or implement fontconfig feature for all platforms.

[RazrFalcon]

It would be good to either document that limitation or implement fontconfig feature for all platforms.

It is documented:

fontdb/Cargo.toml

Line 39 in c3274d0

# Enables minimal fontconfig support on Linux.

The reason we only mention Linux and not Unixes is because only Linux is "supported" right now, if you can call it "support".

And the only reason fontconfig "support" is present to begin with is because Linux distros decided that putting fonts into a hardcoded directory is too easy.
Ideally, there shouldn't be any fontconfig code in fontdb.
PS: I'm aware that recent Windows and macOS versions started doing weird shenanigans with fonts as well.

And yes, fontconfig is intentionally disabled for Windows and macOS. I know you can use fontconfig on them, but you absolutely shouldn't. The whole point of fontdb is to get rid of fontconfig and other needless abstractions.

As for FONTDB_PREFIX. I'm not sure what it solves. fontdb reads fonts.conf at a path specified by fontconfig's documentation. It's not fontdb fault that someone decided to move it.
Instead, we could/should hardcode FONTCONFIG_PATH.
Or even better, we can just hardcode /usr/local/etc/fonts/fonts.conf and call it a day.

Linux support is already 90% of fontdb system fonts loading logic. I don't want to make it even more convoluted.