Forums Bug Reports drawtext color (7.0 beta16)

6.35 draws the text in white for "/drawtest 00" and in black for "/drawtest 01" - as expected.
7.00 beta16 oddly draws in white (or better: in color 00) for both commands ...

PS: Big Thanks for the new version!
PPS, as related to colors: In general, I like the new internal check for "same foreground/background colors". Scripted sollutions had been a bit long winded. However, now there's no way left to "enforce" same colors (for whatever reason)... maybe new switches for echo and aline...? But then, I'm sure there will be a discussion about the feature anyway and I don't want to anticipate it here in bug reports.

Must be a typo, because I get black text for 00 and 01 on 7.00

Nope, but it depends on your $color(background).
Note that I didn't change the colors of the palette itself, I only picked a different color for "background" at view > color.
The behaviour is in some way related to aforesaid new feature. But, in my opinion, that feature must not affect /draw* at all.

If you got white (00) for "background" (not at /drawfill - in the dialog), it will drawtext 00 in $color(normal) and 01 in black. If you set a black (01) BG, it will drawtext 00 in white and 01 in $color(normal). And if you picked red (04) as your background color, it will drawtext 00 as white, 01 as black but... you guess right: not red for 04, but $color(normal).
Note that $color(normal) again may digress from the color you picked - if it's the same as $color(background). Example: if (for whatever reason) you set "normal text" and "background" both to white, mIRC attempts to draw the text in a readable way. The result ironically is quite the contrary: /drawtext 00 won't draw in "white" or "black" but in grey (15) - the very grey of the box in my example script

Thanks, I agree, the new foreground/background color check should not apply to /drawtext - this has been fixed for the next beta. I may add a switch to /drawtext to enable the option as well.

This seems to also be true for normal text.

04,04 test

Results in default text color on a red background.

This is a feature, it is just unwanted for /drawing

Far as I am concerned, it's unwanted for text as well. If I want something to be "hidden", it should be possible. If the foreground and background colors are specified, then it's meant to be the same and mIRC shouldn't try to "fix" what is done on purpose.

Example of usage:
Trivia scripts sometimes place random "hidden" characters between words to help prevent cheating. Yes, those can be bypassed, but it takes a little more knowledge to do so, so it does cut down on it.

Creating a bar of some sort can be done by using a "hidden" character repeated over and over. This one can be done by using control characters that aren't visible, but doubles the length of the line because you have to use a control character between every space.

When using hotlinking, if you need to hotlink multiple words and don't want a space between the words to be unclickable, you can "hide" a character between the words. That lets you click anywhere, including between the words and it's not visible unless highlighted/copied.

There are other reasons why you'd want to have the same foreground and background colors. Having this be a setting or switch or whatever is not a good idea either. Yes, a setting or switch is fine locally. But when sending something over the network (/msg, /say, etc), you can end up showing really messed up text that many users won't have any idea how to fix (such as for those trivia scripts).

I really strongly recommend NOT trying to fix what we purposely do.

I agree, it should be optional, should have a switch for /draw* /echo (maybe /msg ?) and an option in mirc to disable this for incoming message

This is actually a basic usability issue: it should never have been the case that users with one color scheme cannot read text from those with a different color scheme, eg. if you have your background set to white and someone else has it set to black, and you then say "^K1Hello", it will be invisible to the other user. Communicated text should always be visible.

A good example of this is the server MOTD for irc.paraphysics.org, where they use a white foreground color for some of the text which makes it invisible in the default mIRC color scheme.

I think it might be possible to resolve this issue without removing the feature: if only a foreground color is being used, mIRC will check for duplicate foreground/background colors and fix the foreground color if necessary. However if both a foreground and background color are used, no check is performed.

Does that make sense/sound reasonable?

Making this an option would result in more display inconsistency across clients unfortunately.

The feature is good in itself, but as you can see, some people use the same background and foreground color on purpose.
It has been like that for years and noone seems to complain .
Imo, the feature should be applied regardeless of how the line is, but it have to be optionnal (per channel and per network would be really good) or you will have frustrated users
Not sure how, people that don't want the feature will just disable it and will see the message as usual, others will make use of the feature.Most users are already overriding the display with a script and are already displaying a different line comparing to the original anyway

I have received many comments on this issue in the past, and it has been on my to-do list for years, that is the reason I made the change.

As Riamus2 explained, scripters want to be able to control the display of text for aesthetic or other reasons. If I make this an option, it will 1) make it impossible for scripters to know whether using a certain color format will appear the way that they expect since it will depend on a user's settings, unless 2) I add a special identifier that indicates whether this feature is on or off, which will 3) require scripters to display text in at least two different ways depending on the setting.

That is just too complicated. This was meant to be a small change to improve readibility, not to add another layer of complexity. I have removed this feature from the next version for now.

Yes, that sounds like the perfect solution. I have no problems with it changing the color to make it visible if no background color is used. It's only when the background color is used that it matters. If we use a background color, then it doesn't matter what mIRC's background color is because we're setting our own background color, so it shouldn't try to fix anything.

The good thing with the fix when no background color is applied is that Invision can drop Visufix, which also fixes text to make it visible, though it takes it a step further and tries to keep the color as close to the original as possible while still being visible instead of just making it the default color.

Likewise to me,
a) If no bg color for some text is given, one can asume that identical colors of text and $color(back) are by accident, and apply the feature.
b) If the text has bg coloring, one can assume that identical colors are indeed intended, and keep the display as-is.
I don't see a need for a general switch (options checkbox) plus $identifier, nor the need for switches for /echo and /aline either, if the feature will account for b).

My "bug" report was only about /drawtext - as you may have not 2-3 but an infinite no. of color "layers" in a picwin. In addition, /drawtext is imho not used incidentally but by "advanced" scripts. At least to a high degree one can assume any color overlaps are "intended" here.
And the possible switch for /drawtext you brought up would comfortably allow scripters to display their text visible even if they don't want to /drawfill or the like a specific color first, but use the window's default bg color.

I agree that the ideal solution seems to be to only apply this auto-color-change functionality when no background color is explicitly given. As others have stated, if someone chooses to specify fg and bg colors that are difficult or impossible to read, then that is their decision, and the text should be displayed without being changed.

-genius_at_work

As someone who used the default mIRC theme with color tweaks for over 10 years, I have to agree with this option. I always wanted the feature but it was just too much trouble to write a new theme just to have it.

I also noticed text being shown where it should have been 'hidden'. I came to the forum to see if anything has been reported about it and found this topic.

I use 'hidden' characters (color 1,1) in my server MOTD which are now shown and make everything look improper. I used them with good reason:

In the old days, I used to make a lot of drawings, usually lighter colors on a black background; I filled every line with the same amount of characters to get a nice black rectangle around it to make it look good for viewers using a white background. At first I used spaces to fill the empty space with blackness, but then I noticed there were IRC clients/addons that cropped multiple spaces to one single space. This problem could be solved in two ways: I could give every space a new colorcode to not have those clients/addons crop the multiple spaces. But that made drawings a bit hoggy, since the client had to parse a colorcode for every character. It also made lines very long and limited the possibilities. I chose for the second way: to use different characters than a space to fill my drawing. It didn't matter what characters I used to fill empty space because you wouldn't see them... But with the latest change in the beta, you do.

I see that in the latest BETA release 7.01, Khaled has restored it. This is a great relief to me... Thanks.