alacritty: OpenType Bitmap fonts crashes alacritty

@dnkl Hmm, it’ll probably make sense, I’ll try to take a look on it, once I finish my other things in our font crate…

Annnd here is the result, thanks for the patch!

Index: 109, FLAGS: NO_BITMAP | MONOCHROME | TARGET_MONO
thread 'main' panicked at 'LOAD GLYPH FAILED: InvalidSizeHandle', src/libcore/result.rs:1165:5
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::continue_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::result::unwrap_failed
  10: core::result::Result<T,E>::expect
             at /build/rustc-1.39.0-src/src/libcore/result.rs:960
  11: font::ft::FreeTypeRasterizer::get_rendered_glyph
             at font/src/ft/mod.rs:348
  12: <font::ft::FreeTypeRasterizer as font::Rasterize>::get_glyph
             at font/src/ft/mod.rs:146
  13: alacritty::renderer::GlyphCache::static_metrics
             at alacritty/src/renderer/mod.rs:360
  14: alacritty::display::Display::new
             at alacritty/src/display.rs:137
  15: alacritty::run
             at alacritty/src/main.rs:143
  16: alacritty::main
             at alacritty/src/main.rs:112
  17: std::rt::lang_start::{{closure}}
             at /build/rustc-1.39.0-src/src/libstd/rt.rs:64
  18: std::panicking::try::do_call
  19: __rust_maybe_catch_panic
  20: std::rt::lang_start_internal
  21: std::rt::lang_start
             at /build/rustc-1.39.0-src/src/libstd/rt.rs:64
  22: main
  23: __libc_start_main
  24: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Nah, let’s try to see if we fail somewhere silently. @multun just try this patch, forget about previous one.

patch.txt

if I read Alacritty correctly, it should use the pixelsize value as is in this case (as the font isn’t scalable) in the call to to_freetype_26_6(). Is this correct?

As long as face.non_scalable is Some(_), yeah.

Looks like Alacritty doesn’t check for errors when setting the size?

If we would fail here, we’d immediately leave the font crate though. And we’re getting an error from a system font library, not unwrapping a Rust Result<_, _>.

I think this is related to the font size selected. In the test program provided by @multun (where we all get error 0x24), I get error 0x17 from the FT_Set_Char_Size() call.

I can make it work by selecting a different size, known to exist in the font, by replacing the call to FT_Set_Char_Size() with a call to FT_Set_Pixel_Sizes(), which takes an explicit pixel size instead of a point size.

In short, I believe when selecting size in a freetype face object that is backed by a bitmap-only font file, one must select a (pixel)size that exists in the font.

I’m fairly sure FT_Set_Char_Size() is supposed to work too, assuming you give it a point size + DPI value that translates to a pixel size that actually exists in the font file.

FWIW I also can’t repro the issue with freetype 2.10.1.

@multun it’s 2.9.1. As you can see the error is from freetype, so I don’t think alacritty can do something about it?

P.s. I can try recent freetype tbh, let me see whether I can repro with it.

I mean we still need a proper backtrace from alacritty, could you post bt full from gdb?

I just tried with another font, and I think all OTB fonts fail something super strange also happens when there’s a font available in both pcf and otb format. alacritty then opens, but display no characters (only the cursor)