font_kit cannot find font from given list on macOS

[justvanrossum]

I can't get glif to build on macOS. Probably something small, but since I know literally nothing about the entire toolchain I have no idea how to fix.

I've attached the error output of RUST_LOG=debug RUST_BACKTRACE=1 cargo run -- examples/Q_.glif as a textfile.

Any help pretty please? Thank you!

glif-build-error.txt

[justvanrossum]

I also tried to use the prebuilt macOS binary from a recent actions run, but I'm having troubles with that as well. But since that's not advertized, perhaps it's not expected to work.

[ctrlcctrlv]

error: failed to run custom build command for sdl2-sys v0.34.5

Your issue is related to #127. There is not so much I can do about broken Rust-SDL2 build, but given it's happened to two users I could consider opening issue upstream.

The fix we decided on for #127 was to tell users to install SDL2 themselves, then tell cargo to dynamically link to system SDL.

[ctrlcctrlv]

Regarding macOS binary, I do expect it to work, yes, but with caveats; given it is unsigned and not notarized, you are likely to have to do some things on your side to turn off security features. If your problem are related to notarization, then the problems are expected.

[ctrlcctrlv]

(By the way, if you are willing to stick around and test builds regularly, you could likely be a great asset to the project, as at present, besides CI, neither MFEKglif nor any other MFEK binary receives any testing on macOS; primary tested platform is GNU/Linux with Windows being tested once per month or so. This is simply a consequence of the fact I, its main developer, am a desktop Linux user, not really any conscious decision, we're still a small project with few members.)

[justvanrossum]

Regarding macOS binary, I do expect it to work, yes, but with caveats; given it is unsigned and not notarized, you are likely to have to do some things on your side to turn off security features. If your problem are related to notarization, then the problems are expected.

No, I did fix the executable flag on the binary, and worked around the notarization warning.

But:

• If start the app without arg, I get a non-functional file open dialog. (Everything is grayed out, no way to navigate anywhere, or select anything.)

• If I start the app with a path to a .glif file, I get an error dialog:
  

[justvanrossum]

The fix we decided on for #127 was to tell users to install SDL2 themselves, then tell cargo to dynamically link to system SDL.

If you tell me what that means in terms of concrete steps that I can do, I'd be happy to give it a try :)

[ctrlcctrlv]

Both errors you are seeing with the binary are notarization related. I am certain of this due to the greyed out open dialog. It is running in "low-access" mode, where it will allow the binary to execute, but refuse access to any files in the user's home directory. We saw this with FontForge as well. (See fontforge/fontforge#4082 , fontforge/fontforge#4520)

Regarding SDL, I am not totally certain, but if you install http://libsdl.org/release/SDL2-2.0.18.dmg then you should be able to build MFEKglif with --no-default-features which disables the SDL bundling.

[justvanrossum]

Regarding SDL, I am not totally certain, but if you install http://libsdl.org/release/SDL2-2.0.18.dmg

Ok, done.

then you should be able to build MFEKglif with --no-default-features which disables the SDL bundling.

Again, concrete steps... What do I type on the command line?

[ctrlcctrlv]

Regarding the downloaded binary, internet research tells me it may work to run:

xattr -dr com.apple.quarantine /path/to/MFEKglif

com.apple.quarantine really sounds like it might be the problematic flag. Source is https://disable-gatekeeper.github.io/

Again, concrete steps... What do I type on the command line?

cargo build --no-default-features --locked should build MFEKglif with dynamically located SDL2 library.

[justvanrossum]

I fixed one problem: I was trying to run the MFEKglif executable directly from my Downloads folder, which it indeed didn't have permissions for. Running it from a sane location does give a functional open dialog that allows me to select a .glif file. It then proceeds to crash just like in my earlier screenshot.

cargo build --no-default-features --locked should build MFEKglif with dynamically located SDL2 library.

  = note: ld: library not found for -lSDL2
          clang: error: linker command failed with exit code 1 (use -v to see invocation)
          

error: could not compile `MFEKglif` due to previous error

(I did install SDL2.framework in the location as specified in SDL2's readme)

[ctrlcctrlv]

The blamed line is interesting in the crash. I'd note that this code has to my knowledge never changed since very first alpha releases of MFEKglif, but it's possible that macOS has changed underneath us.

The file system-fonts.rs is really nothing so special, it just prepares two fonts for use in the UI: a sans and a mono. For the Sans, it asks the system to match a font to Segoe UI, sans-serif, on all platforms. This is fine because it'll fallback when not on Windows…or if you are an oddball Linux user with a bootleg Segoe UI installed, you'll just get that font instead, NBD.

Please apply this patch:

diff --git a/src/system_fonts.rs b/src/system_fonts.rs
index d336b64..8835270 100644
--- a/src/system_fonts.rs
+++ b/src/system_fonts.rs
@@ -18,9 +18,11 @@ pub struct Font {
 
 fn load_font(family: &[FKFamilyName]) -> Font {
     let source = SystemSource::new();
-    let font = source
-        .select_best_match(family, &Properties::new())
-        .unwrap();
+    let font = match source.select_best_match(family, &Properties::new()) {
+        Ok(f) => f,
+        Err(e) => panic!("Failed to select font for {:?} ! Error from fontkit {:?}", family, e),
+    };
+
     match font {
         FKHandle::Path { path, .. } => Font {
             path: Some(path.clone()),

This will at least give you a more helpful error on crash. 😄

[ctrlcctrlv]

(Good job GitHub, interpreting Might help resolve #220. as Resolve #220. 😆 🙄 )

[ctrlcctrlv]

In any case, post 084a25a, if you compile with RUST_LOG setting MFEKglif to DEBUG or higher, e.g. as—

make CARGOFLAGS='--no-default-features' testrun

Which expands to—

…
RUST_LOG="MFEKglif=debug,mfek_ipc=trace" RUST_BACKTRACE="" cargo run --no-default-features -- examples/Q_.glif

MFEKglif will log some debug lines about its interactions with font_kit:

[2021-12-16T13:44:30Z DEBUG MFEKglif::system_fonts] Looking for a UI font to satisfy request for [Title("Segoe UI"), SansSerif]
[2021-12-16T13:44:30Z DEBUG MFEKglif::system_fonts] OK: Found Some("/usr/share/fonts/TTF/DejaVuSans.ttf") (len 757076)

No matter what log level used, it will also give more useful error message if font_kit fails. (I don't know how to provoke a failure on Linux, so @justvanrossum will just have to try again on OS X 🤷 )

[ctrlcctrlv]

The artifact for 084a25a for macOS built: https://github.com/MFEK/glif/actions/runs/1587727679

[justvanrossum]

Here you go:

[ctrlcctrlv]

Thank you. I believe the issue is related to servo/font-kit#62. In that issue, @RazrFalcon writes that…

Currently, fonts for sans/serif/monospace/fantasy/etc. are hardcoded for Win and Mac. And there are only one font for each type.

And that is certainly still the case:

https://github.com/servo/font-kit/blob/59213db4fe2458eefc79ea8b39f17c9b5e046c1e/src/source.rs#L44-L48 (note comment by @pcwalton)

So, I believe the problem is that, on your Mac, Arial font does not exist. And it's using CoreTextSource instead of FontconfigSource as for me on Linux so there's no fallback from sans-serif.

Workarounds:

• Install an Arial font.
• Try this patch:

diff --git a/src/system_fonts.rs b/src/system_fonts.rs
index ddbb43c..70c7154 100644
--- a/src/system_fonts.rs
+++ b/src/system_fonts.rs
@@ -38,7 +38,12 @@ fn load_font(family: &[FKFamilyName]) -> Font {
 
 lazy_static! {
     pub static ref SYSTEMSANS: Font = load_font(&[
+        // Windows 10
         FKFamilyName::Title("Segoe UI".to_string()),
+        // macOS ??
+        FKFamilyName::Title("Helvetica".to_string()),
+        // macOS ??
+        FKFamilyName::Title(".SFUIText".to_string()),
         FKFamilyName::SansSerif
     ]);
     pub static ref SYSTEMMONO: Font = load_font(CONSOLE_FONTS.as_slice());

[ctrlcctrlv]

When 371547c compiles you can try that again if you don't want to apply patches for some reason :)

It should at least tell you exactly what's wrong…On my system this code results in this debugging output:

This is MFEKglif 1.1.0-beta1 (“First Hurrah”), compiled @ 2021年12月16日
[2021-12-16T15:06:48Z DEBUG MFEKglif::system_fonts] Looking for a UI font to satisfy request for [Title("Segoe UI"), SansSerif, Title("Helvetica"), Title(".SFUIText")]
[2021-12-16T15:06:48Z DEBUG MFEKglif::system_fonts] Skipped Title("Segoe UI")
[2021-12-16T15:06:48Z DEBUG MFEKglif::system_fonts] OK: Found Some("/usr/share/fonts/TTF/DejaVuSans.ttf") (matched @ SansSerif, len 757076)

[justvanrossum]

Ah, I couldn't find my issue because you renamed it :)

So:

1. The font issue is resolved, and I can run the binary built by the GH action
2. My original issue has not been resolved: I still can't build from the source

[ctrlcctrlv]

@justvanrossum Thank you. Sorry about that. I try too hard with the "one bug per issue" thing here. Regarding your second problem, please open a new issue and I'll surely get involved in helping you out with fixing it, if you have more time...thanks for your patience with this issue as well, I appreciate you trying all my attempts to fix it. :-)

Mind sharing a screenshot? 😎

[ctrlcctrlv]

By the way, I think that in general my development priorities have been jarring for people. I apologize for that. I am running MFEK project very much like a "capital F Free Software project" and much less like a "tool for type designers". So, in times of low third party support, Linux is the main targeted platform and outside testing a bit unfocused. 😊

[justvanrossum]

Understood, and that's fine of course. I was just curious where you're at, and now I know :)