Custom RGB colors work on truecolor screens only. For colormapped screens the normal text color will be used, and this defaults to black. I have to guess here, but I'd say you are using a colormapped 8bit screen and (again) did not mention anything about that fact.

From your first screenshot you can see that outlining is working, but the grey outline pen is hardly visible against your colorful background.

On your second screenshot you set both text and outline colors, but did not enable the outline softstyle. That's why you still get plain text.

It's 16bit screen, either CGX or P96, on real amiga or under UAE, no difference.

MUI/Info
The outline is grey under OS3, and under OS4 it's white text with black outline.

There is no outline in 002, but the colours do not work.
Also MUI 3.9 allowed to set colours for group names without any problems for any depth screens.

If we can't have something in 8bit or less modes, the default settings should be somewhat different. A grey outline is obviously misleading. A black outline for white text and white outline for black text would have made more sense.

Ok, now I know what's the cause here. Using direct RGB pens requires cybergraphics.library V45+. This version is provided by AfAOS which extends cybergraphics.library V42 with support for RPTAG_FgColor and RPTAG_BgColor. This makes it possible to specify direct RGB colors with SetRPAttrs(). Without such a patch text can only be displayed using normal pens, which need to be allocated before and must remain valid for the complete life time of an application on a specific screen. Setting arbitrary RGB pens at any time is not possible. The outlined text on the Info page has the preparse string \033t\033P[ffffff] which means "outlined + white". But this "white" is not taken from an allocated pen, but directly as RGB value. Setting arbitrary colors i.e. for the the group title works exactly the same way.

Sorry, as long as cybergraphics.library V42 does not support direct RGB pens this feature cannot work as one might expect it. The same applies for alpha blended text. Like it or not, AmigaOS3 has its limitations and not all possibilities of AmigaOS4 can be emulated or patched in completely. That's one of the reasons why AmigaOS4 exists in the first place and is still actively developed. AfAOS makes lots of things possible, but not everything.

As a temporary solution for OS3 and colour mapped screens under OS4 it might be possible to implement a case and use one of the pens instead when such attributes are present? Even if it's hard coded white (usually texts are black and it will kind of work/do the trick). And for custom settings it might be possible to use one of the MUI pens instead of specified RGB (like the shell has colour defining commands for the strings)

A simpler solution for fallback comparability!
If the colour specified has any RGB component above F0 set the pen to white.
If all components are below 10 (like 0f0f0f) then set black pen.
And for anything in between, use background pen (usually grey).
This will allow the function to do it's job as usual and still have a reasonable effect on colour mapped screens and in cases where the direct draw RGB text is unavailable

That's not a very brilliant idea. Anything between "almost white" and "almost black" would be drawn with "background" color. Really great for a "background" colored background. I would forward all complains to your address then.

A plain AmigaOS3 has its limitations which cannot be worked around in each and every case. Accept this or stick with MUI 3.8. It is possible to add certain features by running certain patches, but even then you still don't get the same rich feature set of AmigaOS4.

How does it work under OS4 on colour mapped screens? As I understood at the moment it does not, and draws grey.

The kludge is to make the feature somewhat usable for all systems and cases.

Of course when we have RGB support we use RGB. And the colour separation can be tweaked to extremes, either white or black, what ever is closer. But keeping it as is - grey is really not ideal, and this also prevents us from colouring/hi lighting text at least as an alternative white colour, currently we are limited to black only, so it's a downgrade from your side to what we had in earlier MUIs.

Hmm, maybe there is an option to write a small additional function patch that provides the missing function for older CGX/P96 similar to AfA but without the overload of AfA. Looking at AfA source, it's a very small piece of code.
But that still does not solve the colour mapped screen problem, hence a fall back mechanism is required, and simple white V black that are almost always available are a reasonable choice.

How does it work under OS4 on colour mapped screens? As I understood at the moment it does not, and draws grey.

Colormapped screens are colormapped screens, no matter which system is used. An such screens cannot handle direct RGB colors. Hence any custom RGB color will be ignored and text will be displayed in black.

The kludge is to make the feature somewhat usable for all systems and cases.

Of course when we have RGB support we use RGB. And the colour separation can be tweaked to extremes, either white or black, what ever is closer. But keeping it as is - grey is really not ideal, and this also prevents us from colouring/hi lighting text at least as an alternative white colour, currently we are limited to black only, so it's a downgrade from your side to what we had in earlier MUIs.

Please state the exact version when you think it did work. Without any proof your statement are worth nothing. Direct RGB colors without a SetRPAttrs() function which really supports the required attributes cannot work in a reliable fashion.

Furthermore it is not possible to enforce white or black colored text, because this requires an allocated pen. If you know how the pen allocation system of graphics.library works, then you should know that you cannot assume a specific pen to refer to a specific color unless you obtained it yourself. But since MUI has no reason to obtain either a black or white pen and the system pens can refer to any color there is no way to enforce a specific color. Of course MUI could obtain a black and a white pen for colormapped screens just for this purpose. But then there is no guarantee that these pens will ever be used and in some other tickets you already complained that MUI wastes too many pens. Yes, I know, next you will tell me that usually there is a black and a white pen already and this would not waste any further free pens. But in the end any replacement color would be as bad as black color. What would you expect red color (ff0000) to be replaced by? White or black? What about green (ffff00)? Anything would be as bad as black, because you end up with the a different color than the intended one and the result might be readable or not, depending on the background which the text engine has absolutely no knowledge about. Imagine red text on white background to be replaced by white text. Really great. I know, the same logic applies for red text on black background to be replaced by black text. Face it, there is no generic way out this for every case. Colormapped screens impose certain restrictions and no matter how you try to work around these restriction there will always be a case where this workaround fails utterly.

And to which "grey" color are you referring to all the time? None of your screenshots shows any grey text, but only black text with grey outline/shadow at most. If you get grey text anywhere you once again failed to provide the facts to prove this.

Hmm, maybe there is an option to write a small additional function patch that provides the missing function for older CGX/P96 similar to AfA but without the overload of AfA. Looking at AfA source, it's a very small piece of code.

Go ahead. I won't stop you. But don't expect this kind of patch to be provided by us.

But that still does not solve the colour mapped screen problem, hence a fall back mechanism is required, and simple white V black that are almost always available are a reasonable choice.

Colormapped screens belong to the past. Both the present and the future are ruled by truecolor screens. You are able to read text on colormapped screens, that is enough. All other fancy stuff is possible on truecolor screens only. Period!

As you have pointed out, on colour mapped screens text will ALWAYS be BLACK.
OK. Then we can have the outline always white for this case. Still better then grey. (and we do not have coloured text (RED,GREEN whatever) anyway so there is no chance of white text with white outline, and even on white background we will see the text (either text or it's shadow)

For the shadow effect, when its present, we can force white text and black shadow (the inverted look, like its done for 3D groups in current MUI3.9).

This will be a reasonable compromise. And yes, sadly no colouring for text on OS3 and colour mapped OS4 for now.

And on colour mapped screens we usually do not config many colours anyway, so default B&W pens are ok the chances of them being anything else are extremely low and they are used in mui everywhere anyway, so no extra pens.

'grey' - the default OS background colour, can be a pale shade of any colour really if user tweaked it, but usually grey (and still it's a mid grey if you look at it from colour to greyscale perspective).

In other words, the colour settings are ignored as they are now,
but the outline and shadow switches act as special drawing cases in B&W only.
This should be a simple case statement, and will be satisfactory for screens where RGB settings are unavailable.
Outline ON ⇒ Black text with white outline
Shadow ON ⇒ White text with black shadow (like in 3.9 groups 3D switch)

mastertext.c: use the system SHINE pen for shadowed text and the the inner outlined text in case the normal text pen would be used. This is a compromise for systems and screens which cannot handle direct RGB colors. Although the result will not be the desired color one still gets shadowed or outlined text which can be recognized as such. This refs #149.

mastergfx.c, mastertext.c, Area.c: objects with colored fonts will now obtain a pen to be able to use this colored font even on a colormapped screen. This closes #146. Furthermore the text engine will now fallback to the HALFSHADOW pen for shadowed and outlined text in case the SHADOW pen equals the TEXT pen. This refs #149.