Improve TSF color filtering logic (re: QQPinyin) (#19117)

If an IME provider sets both `crText` and `crBk` we should respect this,
but the previous logic would incorrectly assert for `crLine !=
TF_CT_NONE`.

## Validation Steps Performed
 I'm not aware which TSF even sets these colors in a
way that's compatible with us in the first place...

(cherry picked from commit f2b30b4e1e6b6555bddb5d3c9ff8f400d5ebe4b2)
Service-Card-Id: PVTI_lADOAF3p4s4Axadtzgck4T0
Service-Version: 1.23
This commit is contained in:
Leonard Hecker 2025-07-15 00:19:10 +02:00 committed by Dustin L. Howett
parent 110e100384
commit 72cad7f3e2

View File

@ -719,17 +719,12 @@ TextAttribute Implementation::_textAttributeFromAtom(TfGuidAtom atom) const
// the others is likely not properly tested anyway, so we reject those cases.
// After all, what behavior do we expect, if the IME sends e.g. foreground=blue,
// without knowing whether our terminal theme already uses a blue background?
if (da.crText.type == da.crBk.type && da.crText.type == da.crLine.type)
if (da.crText.type != TF_CT_NONE && da.crText.type == da.crBk.type)
{
if (da.crText.type != TF_CT_NONE)
{
attr.SetForeground(_colorFromDisplayAttribute(da.crText));
}
if (da.crBk.type != TF_CT_NONE)
{
attr.SetBackground(_colorFromDisplayAttribute(da.crBk));
}
if (da.crLine.type != TF_CT_NONE)
attr.SetForeground(_colorFromDisplayAttribute(da.crText));
attr.SetBackground(_colorFromDisplayAttribute(da.crBk));
// I'm not sure what the best way to handle this is.
if (da.crText.type == da.crLine.type)
{
attr.SetUnderlineColor(_colorFromDisplayAttribute(da.crLine));
}