Drawing clusters

[knokko]

It looks like this crate currently doesn't handle grapheme clusters well (interesting strings like "a̐éö̲y̆"). I downloaded this repository, put a̐éö̲y̆ inside glyph-brush/examples/lipsum.txt, and ran cargo run -p glyph_brush --example opengl --release. This string was supposed to be drawn on the bottom-right, but it didn't go so well.

Is this a bug/limitation of this crate? Or is there something I don't understand here? (Or do I simply need to try with another font?)

[alexheretic]

Glyphs are looked up in the font by char to a u32 glyph id. So grapheme support is more difficult.

You can improve some cases using unicode-normalization, e.g.

use unicode_normalization::UnicodeNormalization;
let mut text: String = include_str!("text/lipsum.txt").nfc().collect();

This isn't a free operation and often has no effect so isn't done by default. Of course, the font must also support the char/codepoint as a glyph in any case.

So the idea is that glyph-brush is the middleman that will dutifully pass the chars to the font and render resultant glyphs. Perhaps there are improvements to be made but I'm not sure what right now.

To make improvements we'll need test cases, strings & fonts that are not rendering the correct glyphs so we can analyse where stuff is going wrong and try to figure out if any changes can be made at this level etc.

[alexheretic]

Tbh I haven't found many cases where unicode-normalization actually helped.

If we just try your test case using DejaVuSans.ttf (instead of OpenSans-Light.ttf") - no unicode-normalization it seems better:

let dejavu = FontRef::try_from_slice(include_bytes!("../../fonts/DejaVuSans.ttf"))?;

[knokko]

Hm... so it was indeed mostly a matter of picking the right font. My testcase is indeed drawn nearly perfectly if I use DejaVuSans. In fact, if I append an extra character at the end (like a̐éö̲y̆a), it even works perfectly. (It looks like the last character is not handled well if it is complex, so appending a simple character solves this.)

The drawback of using that font is that it doesn't handle Chinese characters (like 小组创建). (Note that I blindly copied these characters and have no clue what they actually mean.) The font WenQuanYiMicroHei.ttf is able to draw these Chinese characters correctly, but fails to draw my initial testcase. Do you know of any 'universal' font that is able to draw any character? It would be nice to include such a font to deal with arbitrary user input.

[alexheretic]

You can use a fallback chain of fonts. Glyph-brush does support multi section/font layouts.

However, currently nothing is provided to help with actually splitting into the font sections.

On Wed, 31 Mar 2021, 21:34 Tim, @.***> wrote:

Hm... so it was indeed mostly a matter of picking the right font. My testcase is indeed drawn nearly perfectly if I use DejaVuSans. In fact, if I append an extra character at the end (like a̐éö̲y̆a), it even works perfectly. (It looks like the last character is not handled well if it is complex, so appending a simple character solves this.)

The drawback of using that font is that it doesn't handle Chinese characters (like 小组创建). (Note that I blindly copied these characters and have no clue what they actually mean.) The font WenQuanYiMicroHei.ttf is able to draw these Chinese characters correctly, but fails to draw my initial testcase. Do you know of any 'universal' font that is able to draw any character? It would be nice to include such a font to deal with arbitrary user input.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexheretic/glyph-brush/issues/134#issuecomment-811447059, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARZHV6QAE4UQQED62SXFODTGOBN7ANCNFSM42FMJOYA .

[knokko]

Ok, thank you for the very fast responses! It looks like there was no big problem with this crate after all (that last character issue is somewhat weird, but rarely a problem).