Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#149 closed bug (invalid)

Font settings not working

Reported by: Mikhail Malyshev Owned by:
Priority: normal Milestone: 4.0-2015R1
Component: Fontpanel.mui Version: 4.0-AmiKit8.2
Severity: minor Keywords:
Cc: OS Platform: AmigaOS3
Blocked By: Blocking:
Release Notes:

Description

(Advanced font requester)
Setting of font colour and outline colour does not work, has no effect.

Can also be seen in first MUI/Prefs/Info panel
Left MUI About text should be white with black outline.
Under OS3 it's black with grey outline

Attachments (4)

outlined_text.png (64.5 KB) - added by Thore Böckelmann 4 years ago.
outlined text settings
001.png (48.5 KB) - added by Mikhail Malyshev 4 years ago.
MUI info
002.png (34.9 KB) - added by Mikhail Malyshev 4 years ago.
003.png (84.6 KB) - added by Mikhail Malyshev 4 years ago.

Download all attachments as: .zip

Change History (22)

Changed 4 years ago by Thore Böckelmann

Attachment: outlined_text.png added

outlined text settings

comment:1 Changed 4 years ago by Thore Böckelmann

Priority: undecidednormal
Status: newpending

It is definitely working. See screenshot. Did you forget to enable the "Outlined" text style?

Changed 4 years ago by Mikhail Malyshev

Attachment: 001.png added

MUI info

comment:2 Changed 4 years ago by Mikhail Malyshev

Status: pendingnew

Attachment (001.png) added by ticket reporter.

Changed 4 years ago by Mikhail Malyshev

Attachment: 002.png added

Changed 4 years ago by Mikhail Malyshev

Attachment: 003.png added

comment:3 Changed 4 years ago by Mikhail Malyshev

Not working under OS3

https://muidev.de/attachment/ticket/149/001.png
https://muidev.de/attachment/ticket/149/002.png
https://muidev.de/attachment/ticket/149/003.png

comment:4 Changed 4 years ago by Thore Böckelmann

Milestone: MUI 4.0-2015R1
Resolution: invalid
Status: newclosed

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.

comment:5 Changed 4 years ago by Mikhail Malyshev

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.

comment:6 Changed 4 years ago by Mikhail Malyshev

The shadow effect has the same issues.
Only black text and grey shadow possible at the moment.

comment:7 Changed 4 years ago by Mikhail Malyshev

Resolution: invalid
Status: closedreopened

comment:8 Changed 4 years ago by Thore Böckelmann

Resolution: invalid
Status: reopenedclosed

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.

comment:9 Changed 4 years ago by Mikhail Malyshev

So this is not working on colour mapped screens even with OS4 ?

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)

comment:10 Changed 4 years ago by Mikhail Malyshev

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

comment:11 Changed 4 years ago by Thore Böckelmann

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.

comment:12 Changed 4 years ago by Mikhail Malyshev

  1. How does it work under OS4 on colour mapped screens? As I understood at the moment it does not, and draws grey.
  1. 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.

comment:13 in reply to:  12 Changed 4 years ago by Thore Böckelmann

Replying to Michael:

  1. 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.

  1. 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!

comment:14 Changed 4 years ago by Mikhail Malyshev

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).

PS: Interesting, Url text links are still colourable.

comment:15 Changed 4 years ago by Mikhail Malyshev

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)

comment:16 Changed 4 years ago by Thore Böckelmann

In 4460:

  • 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.

comment:17 Changed 4 years ago by Thore Böckelmann

In 4462:

  • 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.

comment:18 Changed 4 years ago by Thore Böckelmann

Milestone: MUI 4.0-2015R14.0-2015R1

Milestone renamed

Note: See TracTickets for help on using tickets.