Ticket #4539 (new defect)

Opened 7 months ago

Last modified 7 months ago

bolding without color spec does not work in 256-color mode

Reported by: ossi Owned by:
Priority: major Milestone: Future Releases
Component: mc-skin Version: master
Keywords: Cc: egmont
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

the modarin skins contain this piece:


[viewer]

...
viewbold = ;;bold


this doesn't appear to do anything at all in 256-color mode, so for example bolding in manual pages is not effective.

this works in 16-color mode.
underline works fine in either mode.
it does work when a color is specified.

i tested this with konsole and xterm, so i'm guessing it's not term-related.

Change History

comment:1 Changed 7 months ago by zaytsev

  • Cc egmont added

Wasn't there some trick like in 16-color mode upper colors are shown in bold, and in 256+ mode one has to do some magic? But I think it used to work :-( Did you try to bisect it at least in a very rough way, or you are sure it never even worked?

comment:2 Changed 7 months ago by ossi

i just started using themes, so i have no clue whether this is a regression.

from what i can tell, 256-color mode isn't in any way special - "bold" is just an attribute one sets on the char cell. of course, the semantics of that are somewhat questionable when the palette itself already contains all levels of brightness (unlike the "normal" 8-color palette), but whatever.

the _default_ color is color250, and when i include that in the viewbold def, it actually works, so this isn't some "attribute compatibility problem". it seems like the fallback path is somehow broken. but then, why would the other combinations just work?

btw, i'm using a slang-based build (ncurses has some input-related problems, so is no option for me).

comment:3 Changed 7 months ago by ossi

argh, i messed up the theme names. setting color250 explicitly does not work, but 'white' does. so this actually is an attribute compatibility thing.

the terminal emulators have options like "draw intense colors in bold font" or the inverse "show bold text in bright colors", and with the right settings it actually works (unlike with my usual vga rasterfont). it's only the "remapping" of boldness to higher brightness which does not work for colors outside the "base" range, which seems logical enough.

for maximal compatibility, it would still make sense to adjust the skins, to either use white for the default color, or use a separate color for bold instead of (or in addition to) the attribute.

comment:4 Changed 7 months ago by zaytsev

Yeah, this is actually what I meant. I'm not sure how to adjust the skins to make this less obtuse. Maybe you can suggest a patch.

comment:5 Changed 7 months ago by ossi

the minimal patch is to just s/ ;;bold/ white;;bold/ in *256*.ini (and maybe the 16M ones as well), but this has the tiny catch that these specs also appear outside viewbold lines. some of these are clearly affected by the problem as well but might need another color, while some others actually have a usable default color. i didn't investigate further. i would recommend inviting all the original authors to have them ponder the "artistic implications" of changing things, and how the fonts being actually rendered in bold or not affects the picture in their view.

Note: See TracTickets for help on using tickets.