| Summary: | Active fonts should not render fallback glyphs if missing | ||
|---|---|---|---|
| Product: | [Applications] kcharselect | Reporter: | Brennan Kinney <polarathene-signup> |
| Component: | general | Assignee: | Christoph Feck <cfeck> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | wishlist | CC: | polarathene-signup |
| Priority: | NOR | ||
| Version: | 19.08.0 | ||
| Target Milestone: | --- | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
SUMMARY While troubleshooting an emoji rendering setup, I inspected fonts with KCharSelect but was mislead which fonts had which glyphs as fallbacks were being deceivingly rendered when the font did not contain the actual glyph. Installing noto-fonts-emoji Selecting DejaVu Sans or Bitstream Vera Sans fonts in the dropdown, and then the sectino/view: `Symbols -> Emoticons`. Both show mostly black/white emoji, but a few are in colour like 1F624: 1F60E 😎 - "SMILING FACE WITH SUNGLASSES" 1F624 😤 - "FACE WITH LOOK OF TRIUMPH" When changing font to "Noto Color Emoji", all emoji are rendered in colour, including 1F60E. 1F624 is the exact same as what was shown in the earlier mentioned fonts(with my current setup at least), so it has been displayed as a fallback. Bitstream Vera fonts should not contain any emoji, so again, this is shown falling back to both DejaVu, and if not available further back to Noto Color Emoji. I have since learned how to identify this fallback order, and that Bitstream Vera didn't have the black/white emoji that KCharSelect implied it did via confirming font used with this command: fc-match serif VeraSe.ttf: "Bitstream Vera Serif" "Roman" fc-match serif:charset=1F60E DejaVuSans.ttf: "DejaVu Sans" "Book" fc-match serif:charset=1F923 NotoColorEmoji.ttf: "Noto Color Emoji" "Regular" I assume KCharSelect showed 1F60E correctly when viewing Noto Color Emoji as it renders the font glyph views with that specific font, thus, no need to render a fallback. Perhaps this is out of scope of KCharSelect and it's working as intended(character selection regardless of how it's rendered by active font), not for inspecting an actual fonts contents. I understand that the current implementation is likely rendering the glyphs in a standard way like regular text with the selected font applied. Thus it's likely more effort than it's worth to resolve this. STEPS TO REPRODUCE 1. Select "Bitstream Vera Sans" as font. 2. Enter "1F60E" in search field. 3. A result should appear, but it's not actually from the font but a fallback. OBSERVED RESULT Fallback font rendered, no indication of such. EXPECTED RESULT No result, does not exist in the selected font. Or should indicate it's rendering a fallback. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro KDE (up to date), Kernel 4.19.69-1-MANJARO KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.61.0 Qt Version: 5.13.0