-
-
Notifications
You must be signed in to change notification settings - Fork 289
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dark theme is rendering white text on a white background #1016
Comments
Duplicate of #265 |
@johnfactotum the solutions I saw there don't seem adequate. The text should render correctly by default if the user selects the dark theme. There shouldn't be any manual tweaking required whatsoever to get it to work. |
That's not really possible.
The reading system doesn't know whether it should have a white background or not. The background is set by the publisher, and it's impossible to know why they have set such a background, and it's impossible to say what color it should be instead if it's not correct. There are ways for the publisher to fix this if they want. If they haven't done that, then the invert filter is provided as a workaround for the user. |
@johnfactotum I've used the default Reader app on macOS, and IIRC the dark theme never had any issues before like this. If the publisher made a mistake (which does happen), there's no way for the user to edit the eBook, plus it's not practical to do so. It's not their responsibility. Why should the user have to manually trigger this? If the user selected "dark theme", that should be enough, the rest is the software's job. It's not their responsibility to configure the dark theme, it's the software's responsibility. Therefore the app should automatically use some sort of workaround instead. The manual tweaking should only be an escape hatch if the automatic method doesn't work. For example, if there's white text rendered on a white background, then just invert the text colour by default so it stands out. Just like you recommended, but do it by default. If the user can come to sort of decision for how to manually tweak it as you suggested, then you can replicate the same logic in code and make it automatic. The same logic would probably apply to many books, and each book can be tested against this logic to make sure it works and adapts for all of them. Anything that can be done manually can be automated. |
If you're talking about Apple Books, I don't believe it inverts anything at all, by default or otherwise. It does have a special attribute,
If it applies the invert filter by default, correctly formatted books would be rendered incorrectly by default.
What logic would that be, exactly? |
@johnfactotum I'm sure there's at least one way to detect if it needs to be inverted or not. If a human can determine it's illegible, then the same decision making process should be able to be broken down into programmable logic. I'm not exactly sure what that solution is. All I'm saying is it must exist, because otherwise a human wouldn't be able to determine the text is illegible. The same logic a human uses can be written in code. If for some reason that's really difficult, then maybe it could even be run through a machine learning script to determine whether to invert it, which is trained on many books. Obviously at that point it might be a lot of effort to solve, and it may be a low priority item. But IMO it's necessary for a truly fluid user experience. Perhaps it can be done one day. |
Well, I guess a very simple heuristic, that can be done without querying the DOM and doesn't even require a CSS parser (which we don't currently have), would be: if the CSS does not contain the string This doesn't account for images. A very simple heuristic for that might be: if the page contains small images (say something like less than 50px in either direction), then it's likely not a photo and should be inverted. This is pretty shaky, though. Another approach would be to treat different image formats differently:
But even then I would be hesitant to make something like this the default behavior. By default it should try as much as possible to render the book as authored. User overrides should be something that needs to be enabled manually. |
@johnfactotum if someone is using the dark theme and the author didn't adapt the book to work with dark themes, then it's already not being used as authored. Therefore wouldn't it be best to just make this the default behaviour if someone is using the dark theme? |
It's not possible to know whether this is the case or not. It can only guess. If the book's stylesheet contains By making it disabled by default, it would signal that the invert filter is a hack, a poor workaround, that should be discouraged, and not the proper way of doing things. And it's easy enough to toggle the invert filter now that the option is available directly in the primary menu (rather than being hidden in submenus) in the gtk4 branch. But I suppose, since the result, unlike some other kinds of overrides, wouldn't be that catastrophic if it goes wrong, and it would have a clear opt-out mechanism and is unlikely to contribute to the arms race between the user agent and the publisher, at the end of the day, taking all things into consideration, it would not be unreasonable to enable it by default. |
Fixes #1016. The main idea is taken from Readium CSS and is basically what Apple does, too. So there's not even a need to provide a way to opt out.
Describe the bug
The default dark theme is rendering white text on a white background, which is barley legible.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The dark theme should always render text that's legible, and it shouldn't have a white background because it's a dark theme.
Screenshots
Version:
The text was updated successfully, but these errors were encountered: