Created attachment 161516 [details]
screenshot of the problem

SUMMARY

The emoji handling in Konsole has recently been greatly improved (thanks for this), but I found a nit in the handling of a particular class of emojis. I think probably Konsole is not recognizing that these characters are emojis and giving them the appropriate additional padding.

This problem occurs with all unqualified emojis unless (a) the emoji ends with an emoji presentation selector (FE0F), or (b) the glyph is sufficiently wide to force the font rendering engine to push the following character into the next alignment box. The "wavy dash" emoji 〰️ is wide enough to do this at 10pt in Noto Sans Emoji. 

Some unqualified emoji are given a text rendering, e.g. the unqualified version of the play button ▶️. In this case it is possible that the emoji will be rendered in a monospace font appropriate for a terminal and as a result the spacing will look correct, despite the fact that this could cause misalignment with other columns for which wider spacing is enforced. It's not clear to me what the correct behavior is, in this case.

(Note, all emoji in this bug report are fully qualified for better handling in browsers and email clients. The bugs appear when the unqualified versions of these emoji are used.)

STEPS TO REPRODUCE
1. curl -s https://www.unicode.org/Public/emoji/15.0/emoji-test.txt | grep unqualified

OBSERVED RESULT

Most unqualified emoji are not given the extra space of padding that qualified emoji receive.

EXPECTED RESULT

Unqualified emoji look the same as other emoji, at least if they are rendered in the emoji font. (In other cases, correct behavior is more complicated, as discussed above.)