Dark mode and inline SVG

[chrisridd]

I'm using some inline SVG in my own personal books to include some vector art diagrams in the chapters. This works OK so far in the kepub engine.

What happens to SVG artwork when you run the reader in dark mode? The SVG hardcodes colours, so will I end up with black artwork on a black background?

Dark mode's a feature of some popular OSes. AIUI in web browsers there's some sort of mechanism in the CSS to detect dark mode and set colours appropriately. Does Kobo's dark mode support that, or is its dark mode more simplistic?

I don't think my Aura ONE has the new fangled dark mode support, otherwise I'd test...

[John F]

Originally Posted by chrisridd

I'm using some inline SVG in my own personal books to include some vector art diagrams in the chapters. This works OK so far in the kepub engine.

What happens to SVG artwork when you run the reader in dark mode? The SVG hardcodes colours, so will I end up with black artwork on a black background?

Dark mode's a feature of some popular OSes. AIUI in web browsers there's some sort of mechanism in the CSS to detect dark mode and set colours appropriately. Does Kobo's dark mode support that, or is its dark mode more simplistic?

I don't think my Aura ONE has the new fangled dark mode support, otherwise I'd test...

Dark mode is more simplistic.

[jackie_w]

Never mind.

[DevonHess]

I was under the impression that dark mode literally just inverted the screen.

[Quoth]

Originally Posted by DevonHess

I was under the impression that dark mode literally just inverted the screen.

Some methods do, such as some patches. Better designed dark modes only invert text. On modern systems it's invented to save battery on OLED screens. It's better to simply turn down the rear light on LCD or front light on eInk as the fonts are optimised for black text on a white background. On old mono CRTS they used black background and bright text to save tube life, power and allow better focus.

[DevonHess]

Originally Posted by Quoth

Some methods do, such as some patches. Better designed dark modes only invert text. On modern systems it's invented to save battery on OLED screens. It's better to simply turn down the rear light on LCD or front light on eInk as the fonts are optimised for black text on a white background. On old mono CRTS they used black background and bright text to save tube life, power and allow better focus.

Sorry, I meant Kobo eInk devices specifically.

[chrisridd]

Originally Posted by Quoth

Some methods do, such as some patches.

I'm not too worried about how the patches behave. Which method does Kobo use in recent firmware releases on certain recent devices?

[Quoth]

Originally Posted by chrisridd

I'm not too worried about how the patches behave. Which method does Kobo use in recent firmware releases on certain recent devices?

They invert the text only, so for example a Line art drawing is not affected, but will be in a white box. So illustrated books do display the images correctly, but look ghastly in dark mode with white text and black background. The font doesn't look as nice either.

Just tested on Sage with 4.35.x FW and "Arabel and Mortimer Stories" (books 1 to 6 of originals) converted from azw3 to epub2.

The page turn flash is also more objectionable in Dark mode. It's best kept to save power on OLED phones and tablets. Turning down the front light works better at night, or no front light at all and suitable small angle-poise lamp just to illuminate the ereader, with a suitable bulb in it (I use the yellow stick filament LED types, very like halogen/daylight with no obvious blue. The yellow coating on the sticks is actually a phosphor).

[DNSB]

Originally Posted by chrisridd

I'm not too worried about how the patches behave. Which method does Kobo use in recent firmware releases on certain recent devices?

I'm tempted to say both. The dark mode from the ereader Settings menu inverts text when reading but leaves images uninverted. The invert screen which requires a reboot to work inverts everything—text, menus, images.

I use NickelMenu to handle either with the following (change main to whatever other places you want to see this option):

#
menu_item : main    : Dark Mode          : nickel_setting : toggle : dark_mode
menu_item :main     : Invert & Reboot    : nickel_setting :toggle: invert
    chain_success      : power           : reboot
#

[graycyn]

Originally Posted by chrisridd

I'm using some inline SVG in my own personal books to include some vector art diagrams in the chapters. This works OK so far in the kepub engine.

What happens to SVG artwork when you run the reader in dark mode? The SVG hardcodes colours, so will I end up with black artwork on a black background?

OK, I have a little personal book made strictly for myself with an SVG image and it happens to be on both my Sage and on my Kindle Oasis currently, so...

For background info, the SVG was made by myself in Inkscape, saved as plain SVG and is a black line-art image on transparent background.

On Kobo Sage, running stock firmware 4.35.204 (which I believe is the current version), in dark mode, I get black artwork on black background. It disappears, in other words, just as you suspected it might.

For fun, I kepubified the book, and checked in kepub format, same thing. Black on black.

On a Kindle Oasis 2, using epub via Send-To-Kindle which delivers KF8 format, same SVG image inverts to white on black.

Hope that helps.

[Quoth]

Don't use transparency. It doesn't even make sense. Like files for paper print, use white (which is regarded as transparent on print), then the images work properly in Dark Mode.

Amazon doesn't allow transparency.

[jgneff]

I doubt e-readers have support for SVG filters, but the following added to your SVG file works pretty well in most browsers for general dark-mode support. Just add it right after the opening svg element.

<filter id="darkmode">
    <!-- Same as CSS 'filter: invert(1)' but in linear RGB -->
    <feComponentTransfer>
        <feFuncR type="table" tableValues="1 0"/>
        <feFuncG type="table" tableValues="1 0"/>
        <feFuncB type="table" tableValues="1 0"/>
    </feComponentTransfer>
    <!-- Same as CSS 'filter: hue-rotate(180deg)' -->
    <feColorMatrix type="hueRotate" values="180"/>
    <!-- Gamma function: C' = amplitude * pow(C, exponent) + offset -->
    <feComponentTransfer>
        <feFuncR type="gamma" exponent="2.2"/>
        <feFuncG type="gamma" exponent="2.2"/>
        <feFuncB type="gamma" exponent="2.2"/>
    </feComponentTransfer>
</filter>
<style>
@media (prefers-color-scheme: dark) {
    svg {filter: url('#darkmode');}
}
</style>

It inverts the colors (really just to go from light to dark), swings back around 180 degrees to the original color hues, and then converts the gamma back to sRGB from linear RGB. You can try changing or removing the gamma function if it's too dark even for dark mode.

[chrisridd]

Originally Posted by graycyn

OK, I have a little personal book made strictly for myself with an SVG image and it happens to be on both my Sage and on my Kindle Oasis currently, so...

Cool!

My next problem is trying to figure out how Kobo handles fonts in the SVG. It seems to replace everything I'm trying with one of the serif fonts. Have you figured out what they're doing with fonts, or is the answer just to convert all text to curves?

[graycyn]

Originally Posted by Quoth

Don't use transparency. It doesn't even make sense. Like files for paper print, use white (which is regarded as transparent on print), then the images work properly in Dark Mode.

Amazon doesn't allow transparency.

Personal book for myself and no other, I can do what I want, especially since I rarely use dark mode.

I agree though, were I publishing, transparency would be a very bad idea. Most use cases would render black on black in my experience.

[graycyn]

Originally Posted by chrisridd

Cool!

My next problem is trying to figure out how Kobo handles fonts in the SVG. It seems to replace everything I'm trying with one of the serif fonts. Have you figured out what they're doing with fonts, or is the answer just to convert all text to curves?

Can't help you there, my image is just a little vector graphic, no fonts involved. I do remember way back when, experimenting with SVG title pages, and I think I found that they worked best for me if I converted everything to a path. But that was a while back.