You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This character not rendering has been a long-standing issue in Blitz's TodoMVC example, and font-fallback failure in Fontique was determined to be the root cause by Fable which had this to say:
The ❯ (U+276F, Dingbats block, script Common) isn't in the Helvetica Neue/Helvetica/Arial stack, and fontique's fallback is script-based (one CoreText-picked family per script sample) with no per-character last-resort search, so no font covering U+276Fis ever tried → .notdef. This is an upstream parley/fontique limitation.
I had GLM-5.2 write a test for it, and it had this to add:
The character has Common Unicode script, so parley's itemizer assigns it the Latin script when surrounded by Latin text (Common/Inherited scripts inherit from surrounding context per UAX Fix issues in Cursor and simplify logic. #24).
The default system fallback for Latin (e.g. Helvetica on macOS) doesn't cover U+276F
One font present on my system (macOS) that does cover this glyph is "Zapf Dingbats".
The following test reproduces the issue on macOS (not tested on other OSs). It must be run with the system feature enabled:
#[cfg(all(target_os = "macos", feature = "system"))]#[test]fn font_fallback_heavy_angle_quote(){letmut env = TestEnv::new(test_name!(),None);// Load system fonts so that fontique can find a fallback for U+276F.
env.font_context().collection.load_system_fonts();let text = "\u{276F}";let builder = env.ranged_builder(text);letmut layout = builder.build(text);
layout.break_all_lines(None);
layout.align(Alignment::Start,AlignmentOptions::default());let glyph_id = layout
.lines().flat_map(|line| line.items()).find_map(|item| match item {PositionedLayoutItem::GlyphRun(glyph_run) => glyph_run.glyphs().next(),PositionedLayoutItem::InlineBox(_) => None,}).map(|glyph| glyph.id).expect("expected a glyph for the ❯ character");// The fallback font should have a real glyph for ❯, not a `.notdef`.assert_ne!(
glyph_id,0,"the ❯ character (U+276F) should not resolve to a .notdef glyph when a fallback font is available");
This character not rendering has been a long-standing issue in Blitz's TodoMVC example, and font-fallback failure in Fontique was determined to be the root cause by Fable which had this to say:
I had GLM-5.2 write a test for it, and it had this to add:
The following test reproduces the issue on macOS (not tested on other OSs). It must be run with the
systemfeature enabled:}