Alan P JohnandSmit Barmase
5197cb4da9
Closes #50483 ## Findings As reported in the original issue, emojis in SVG preview were not rendering consistently with the editor. The SVG renderer uses `usvg`/`resvg` for parsing and rendering SVG files. The first problem was that emoji fonts were not rendering at all, which was fixed by enabling the `raster_images` on `resvg`. Beyond that it was observed that the default font fallback mechanism in `usvg` searches through the font database alphabetically without prioritizing emoji fonts. This caused emojis to sometimes render in non-emoji fonts that happened to contain glyph mappings for those characters. For example, on Linux systems with the default `uvsg::FontResolver::default_fallback_selector()`: - The character ✅ would fall back to `FreeSerif` (monochrome) - Instead of `Noto Color Emoji` (full color) Log output showed the inconsistent behavior: ``` WARN [usvg::text] Fallback from FreeSans to Noto Color Emoji. WARN [usvg::text] Fallback from FreeSans to FreeSerif. WARN [usvg::text] Fallback from FreeSans to Noto Color Emoji. ``` <img width="480" height="480" alt="Image" src="https://github.com/user-attachments/assets/e065608f-a98b-4e67-9429-4aed16810c2c" /> This created a jarring inconsistency where the same emoji character would render differently in: - The editor (correct, using platform emoji fonts) - SVG preview (incorrect, using arbitrary fallback fonts) ## Solution If the specified font in SVG is available on the system, we should show that. If not, we should fallback to what editors show today for that emoji. This PR implements emoji-aware font fallback that: 1. **Enabled `raster_images` build feature** to render emojis in SVG. 2. **Detects emoji characters** using Unicode emoji properties (via `\p{Emoji}` regex pattern), consistent with how we check for emoji in the Editor as well. 3. **Preserves user-specified fonts** by only intervening when the default font resolver would use a non-emoji font for emoji characters ### Font Family Selection I avoided completely reusing/rebuilding the logic for emoji font selection used by the editor as `uvsg` internally does quite a bit of the job and it felt like overcomplicating the solution. Instead using hard coded platform specific font family names. The hardcoded emoji font families are sourced from Zed's existing platform-specific text rendering systems: - **macOS**: `Apple Color Emoji`, `.AppleColorEmojiUI` Source: https://github.com/zed-industries/zed/blob/db622edc8b26bd138c91027a02792a84c083acbf/crates/gpui_macos/src/text_system.rs#L353-L359 - **Linux/FreeBSD**: `Noto Color Emoji`, `Emoji One` Source: https://github.com/zed-industries/zed/blob/db622edc8b26bd138c91027a02792a84c083acbf/crates/gpui_wgpu/src/cosmic_text_system.rs#L642-L646 - **Windows**: `Segoe UI Emoji`, `Segoe UI Symbol` Source: Standard Windows emoji font stack These match the fonts the editor uses for emoji rendering on each platform. To break down further into the similarity and differences in the emoji font resolution: **Similarities:** - Both now use the regex based emoji detection logic - Both prioritize the same platform-specific emoji font families - Both support color emoji rendering **Differences:** - **Editor**: Uses platform-native text shaping (CoreText on macOS, DirectWrite on Windows, cosmic-text on Linux) which handles fallback automatically - **SVG**: Uses custom fallback selector that explicitly queries emoji fonts first, then falls back to default usvg behavior ## Testing - Added unit tests for `is_emoji_character` in `util` crate - Tested emoji detection for various Unicode characters - [ ] Verified platform-specific font lists compile correctly (Only linux done) - [ ] Manual testing with SVG files containing emojis on all platforms (Only linux done) Release Notes: - Fixed SVG preview to render emojis consistently with the editor by prioritizing platform-specific color emoji fonts --------- Signed-off-by: Alan P John <alanpjohn@outlook.com> Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS, Linux, and Windows you can download Zed directly or install Zed via your local package manager (macOS/Linux/Windows).
Other platforms are not yet available:
- Web (tracking issue)
Developing Zed
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.
Sponsorship
Zed is developed by Zed Industries, Inc., a for-profit company.
If you’d like to financially support the project, you can do so via GitHub Sponsors. Sponsorships go directly to Zed Industries and are used as general company revenue. There are no perks or entitlements associated with sponsorship.