Panic while redering space in NotoSans-Regular #64
Comments
kchibisov
added a commit
to kchibisov/crossfont
that referenced
this issue
Feb 19, 2024
The servo crate is not maintained anymore. This also bumps freetype-rs along the way, since it had circular dependency. Closes: alacritty#64
|
See #65 I think we kind of can propagate this bump, given that only sctk-adwaita and alacritty depend on crossfont according to crates.io, thus it's likely not that big of a deal, given that we won't break binary crates, I think. |
kchibisov
added a commit
that referenced
this issue
Feb 19, 2024
The servo crate is not maintained anymore. This also bumps freetype-rs along the way, since it had circular dependency. Closes: #64
|
If you could, make this a patch number bump. That way, it gets automatically selected by the resolver |
|
Btw, thank you for being very quick to respond! |
It's a breaking change, so we can't do that. |
|
Understandable. Thank you very much again :) |
kchibisov
added a commit
that referenced
this issue
Feb 22, 2024
The servo crate is not maintained anymore. This also bumps freetype-rs along the way, since it had circular dependency. Closes: #64
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've been thorugh a a bit of a rabbit hole today because of a segfault in
freetype-rs. After reading logs and stack traces, it is caused by this crate using a way too low version offreetype-rs. From what I have gathered, the issue happens with some characters that are blanks.This is because
Face::load_glyphcan populate the slot with valid information, but no bitmap buffer, leaving it empty. However, in C, an empty slice is represented as (null, 0) but this is invalid in rust, causing a panic when trying to load it incrossfont. Here's the offending code: link.This issue was fixed in this commit, and later released as version 30.1.
Related issue: #44
The text was updated successfully, but these errors were encountered: