Bug 412267 - Active fonts should not render fallback glyphs if missing
Summary: Active fonts should not render fallback glyphs if missing
Status: RESOLVED DUPLICATE of bug 97420
Alias: None
Product: kcharselect
Classification: Applications
Component: general (show other bugs)
Version: 19.08.0
Platform: Manjaro Linux
: NOR wishlist
Target Milestone: ---
Assignee: Christoph Feck
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-24 08:11 UTC by Brennan Kinney
Modified: 2019-10-24 08:01 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brennan Kinney 2019-09-24 08:11:50 UTC
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
Comment 1 Christoph Feck 2019-10-24 08:01:23 UTC

*** This bug has been marked as a duplicate of bug 97420 ***