Improving text contrast in label and binder colors

I love being able to color-code scenes with the “label” feature. I use this to show which scene is in whose point-of-view using the labels. However, because I now have quite a few POV characters, I’ve had to use some “bright” label colors, and I now see that they are not as legible as they should be.

I’d like to recommend you use a different algorithm to compute whether to use white or black text. This algorithm computes the brightness based on the “value” in the HSV color space, reliably returning “white” or “black” for the color for the foreground text. This would improve readability significantly.

I see that you’re doing something similar to this with the label colors, but it can still result in white text with bright labels where black text would be much more readable. As an example, on the Mac version of Scrivener, assign the “green” color to a new label from the Apple color palette. The text on that label is barely readable when you use a “dark” system color theme.

I also noticed that the colors used in the Binder are always white or black, and aren’t defined independently for each background color. This is less of an issue in the binder because the background color values are shifted when you switch from dark to light system themes on the Mac, but if each value was computed separately, you wouldn’t need to change the label color values at all.

Following is a Python code example of this label color computation, converting from RGB color values to HSV for purposes of determining the label text color (white or black). I realize you don’t code Scrivener in Python, but since I don’t know what language you use, I figured it would still be useful as functional pseudocode.

def determine_foreground_color(rgb):
    """
    Determine whether to use black or white as the foreground color
    based on the brightness (Value) of the background RGB color.
    
    Args:
    rgb (tuple): A tuple of (R, G, B) values in the range 0-255.
    
    Returns:
    tuple: A tuple of (R, G, B) for the foreground color.
    """
    # Step 1: Convert RGB to HSV
    r, g, b = [x / 255.0 for x in rgb]  # Normalize RGB values to the range 0-1
    max_val = max(r, g, b)
    min_val = min(r, g, b)
    delta = max_val - min_val

    # Calculate Hue
    if delta == 0:
        h = 0  # Undefined hue
    elif max_val == r:
        h = (60 * ((g - b) / delta)) % 360
    elif max_val == g:
        h = (60 * ((b - r) / delta)) + 120
    else:
        h = (60 * ((r - g) / delta)) + 240

    # Calculate Saturation
    s = 0 if max_val == 0 else delta / max_val

    # Calculate Value (Brightness)
    v = max_val

    # Step 2: Determine the foreground color
    if v > 0.5:
        return (0, 0, 0)  # Black foreground
    else:
        return (255, 255, 255)  # White foreground

# Example usage
background_rgb = (200, 100, 50)  # Replace with actual background color
foreground_rgb = determine_foreground_color(background_rgb)
print("Foreground color:", foreground_rgb)
1 Like

I wonder if this might be useful to address the ‘twisties’ (chevrons?) in the binder sometimes being difficult to see? They are fine in the Default and Mellow Yellow themes, but in some of the others they can be difficult to see.

I’ve seen other conversations where altering the ‘twisties’ to a different visual representation is not a trivial undertaking (for a user, I can’t intelligently comment on the programmer perspective). If this, or something akin to it, was a practical suggestion I’d welcome implementation - particularly if it wasn’t an inordinate amount of effort for time-poor application maintainers (I think the ‘s’ is optimistic?) .

In some cases I’m finding that while a theme is good, the visibility of the ‘twisties’ user interface element can make them difficult to see - from my perspective. Fully appreciate once you get to UI there will be a huge diversity of views. One persons ‘fix’ could be anothers ‘you’ve completely stuffed it and it was great before!’ type moment. Hopefully additional contrast is non-controversial.

Antoni Dol has a theme called Tropical Night that he created that adds its own “twisties/carets” that are beautiful and easy to see with a lot of personal touches. One of the most beautiful themes I have ever seen. Message him about it.

1 Like

Thank you, yes you provided enough information for google to be effective (shocked…). I also saw he has authored a book along the same lines (same $ at least on the www I saw). I might take a look at his book between drafting and edit time…

Hopefully the caret/twistie things is something that is doable at a dev level by L&L. The triangle (that Antoni has used) is a significant improvement over the chevron.

That said If in the view of L&L I’m basically the old guy in the parking lot screaming at clouds…then so be it. It’s not a hill I want to die on. In the overall scheme of things the software works bloody well, and I just don’t use themes which have the issue (to me.)

Also, to be really honest, it’s hard as a user to know how ‘easy’ some of this stuff is or isn’t for devs to ‘fix’. And L&L could well be sitting there going “Well, yeah, we could fix that…but we could also fix ‘this’ (or add this) which will benefit far more users”…in which case, you know, common sense prevails…

2 Likes

I can’t speak to changing the icon contrast, since those are either pixels or vector graphics, but it’s trivially easy to do the HSV font color computation when the user defines the label color. It could be done as the new color is saved as a new property for the text color when placed on the new background color.

I’ve done something like this in a very complex web page I generate in a Ruby on Rails app for a work program I wrote. I do it on the fly while the page is being rendered and it doesn’t noticeably affect the web page load time. I’m sure a C++ / Objective-C / Swift / whatever-language-it-is app like Scrivener could do this in no time flat.