Encoding absolute color in UILabel only valid when font color is white in 3.06+

[wishful_st]

Hi there,

I believe prior to 3.06, when using encoding in the UILabel via [FF0000][-] markup, it would absolutely change the color of the font, regardless of the UILabel's widget color setting.  However, On 3.06 and later, it seems this has changed and that the encoding markup seems to be valid only for a white widget color (and after experimenting with different colors, there seems to be some math going on - possible additive?  That is, the encoding color is added to the widget color)

Is this the desired behaviour, and if so, does that mean if I wanted a default color other than white, then I'd have to specify it in the encoding?  It seems to defeat the purpose of the encoding tags if it was additive since you may not know what the base color is.

Thanks!

[ArenMook]

Widget color tint now blends with all other colors of the label -- both the gradient and the embedded colors. This is an intentional change. You can get your look back by specifying the color in front of your text instead of setting the tint color.

[ChrisPruett]

Thread necro.

So if I'm reading you correctly, it's no longer possible to use embedded colors to tint black text?  That seems... restrictive.

What is the use case that prompted the behavior change for this?  I feel like the embedded color should always override the tint color (though perhaps not the gradient color).  We highlight important text in red, etc.

[ArenMook]

You can still achieve the tinting if you embed the darker color instead of using the widget's tint color. Widget's tint color is the "final multiplier".

1. [000000]Black text[ff0000]Red word

[ChrisPruett]

Sure, but that's a lot more arduous than the old system.  We have text that is black by default but (depending on the text we jam into the label, which is dependent on game state) may be any number of colors at the same time.  Relying on markup to select the final color was exceedingly useful for this use case.  Now I suppose we can set the text color to white and use markup to mark all of it black in 90% of the cases... but it's going to be error-prone and a lot of work to support (we have a lot of text).

If we're voting, put me down for "markup should override final color."  I still don't understand the use case that prompted this change, but it complicates my use case quite significantly.

[ArenMook]

Adding gradient support is what prompted this change. Gradient color is blended with the tint color, so for consistency embedded color is now also blended with the tint color. If I didn't do this, then gradient would behave one way and tint color would behave another way, and the code would somehow need to separate the two.

[ChrisPruett]

I follow your line of thinking, but, in our personal use case, gradient support is not something we need or use regularly, where as reliable markup tint is something we need and use regularly, so this change is one we would prefer not to have. 

Allowing the blend to be gradient + tint when there is no embedded color and gradient + embedded color (no tint) when an embedded color exists would probably have worked better, at least for us.  We see the embedded color as a tint override.

I guess I'll write a version of UILabel that supports this.  My vote is still "current version is worse than previous version."