CosmicHorror

Hmmm, that looks like it may be selecting different fonts for different characters? That does seem really odd We're currently using a fork of `cosmic-text` to handle font stuff, so...

You can try adding that repo as a patch to the `Cargo.toml` file and see if it resolves the issue. We'll need an actual published version next time we go...

That's odd. I can reproduce the issue from #79, but I can't reproduce this issue on Arch Linux. I'll try to get a fedora VM setup this weekend to see...

I was able to reproduce this in an out-of-the-box Fedora 38 VM. #105 is going to change a lot of the font logic, so I'll have to take a deeper...

#105 is in and this now appears as a panic in one of our dependencies ```text thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/test/.cargo/git/checkouts/glyphon-bce1d8fb6a1f7cb1/80e8465/src/text_render.rs:110:26 ``` I'll work...

That seems like a reasonable approach. I'll play around with it, and see how clean things end up being sometime this week

That's a new one for me @luukvanderduim. It looks like the window for `inlyne` isn't returning any surface capabilities which makes sense as to why it fails on _every_ markdown...

Not as odd as I was expecting. Well if you want to troubleshoot a bit I would see if you can run some of the examples (like `mipmap` or `cube`)...

Thanks for the follow-up! It could be worth your time going ahead and filing an issue upstream. They'll be in a much better position to help I think the best...

Thanks for helping work through the issue! This would have been impossible for me to figure out on my own