In the latest beta, when I select dark mode, the page background becomes dark, instead of staying white as in MacOS. This makes the text difficult to read and dark mode unusable here.
As this wasn’t fixed in beta 19, I thought I’d provide more info and ask whether there is a workaround.
I’m using the tutorial to make reproducing this easy and to show that the issue is present in any document. I’ll use two pages from the tutorial, the one on the binder and the one on the editor, in scrivenings mode. All the appearances options have been reset to default after the switch to dark mode.
In Mac OS, Dark Mode behaves the way I want it to by default, i.e. the interface is dark but the page remains black on white:
I seem to be limited to three pics per posts so I’ll continue in the next two posts…
If I switch to Dark Mode in Windows, the first page is mostly correct (though it’s not what I want as the page isn’t white anymore as in the Mac OS dark mode, but more on that later):
Not sure why some of the bold text appears highlighted though, it doesn’t seem correct.
However, the second page is definitely not correct, because the text is dark instead of white, making it illegible against the dark background:
The bold parts are not highlighted though, so it looks like you have one issue or the other depending on the page.
The incorrect “dark on dark” scheme above is what I get on my current manuscript for all my pages when I switch to dark mode (even with all options reset to default). There is no such issue with the default mode.
I have tried to change the color of the text and background in the editor (options/appearance/color) but I couldn’t find an option that allows me to get a white background in the editor window and black text, as in the Mac OS screenshots (default dark mode on Mac OS).
Is there workaround until this bug is fixed?
Thanks!
To clarify, on the Mac when you first used Dark Mode you were asked whether you would prefer the editor to stay light, or to be dark as well. There isn’t actually a default condition here, much like there isn’t a default look for macOS itself—unless you consider which radio is selected when that introductory dialogue appears. The setting itself can be freely toggled as desired with the Scrivener ▸ Appearance ▸ Keep Main Editors Light menu command (⇧⌥⌘L), and as well it can be toggled with the Use dark appearance in main window editors setting, in the Appearance: General Interface: Options preference pane.
So technically speaking there isn’t anything to “fix” here, this isn’t a “bug” and nothing is “incorrect” (personally I find the light editor look to be an eye strain, unless I dim the settings on it way down to almost dark—but that’s just a point of opinion of course). There is no “workaround” because the whole theme system exists to let you change how stuff looks. So while as far as I can see, Dark Mode on Windows is still a work in progress, you can certainly achieve the kind of look you are going for by adjusting your settings (and restarting the software frequently, hence WIP)!
[size=80][/size]
P.S. The tutorial will be an unfortunate example to use in this case, specifically because it was created at a point in time when text colour tended to turn black instead of having no assignment, and styles saved the background colour when they shouldn’t have (and bullets too it seems, sometimes). So that project will indeed be largely unreadable in dark mode. That is of course something that will be fixed for the launch tutorial, it’s a problem of formatting, not the software.
Thanks for this reply.
A few things:
-
It would be great if such an option was offered in windows. There is no option to keep the editor light when enabling dark mode, or to change this afterwards, as is the case on Mac OS. I’m aware that provided the default dark mode theme is legible, it’s a subjective thing, but the Mac version got it right as far as I’m concerned
. -
Regarding the bug, are you suggesting that the tutorial wasn’t formatted the same way in the section about the binder (mostly correct in dark mode) and the section about the editor (not legible in dark mode), when both sections look correct in Mac OS dark mode and Windows default mode? Surely Mac OS is reading the same formatting differently because it doesn’t show in dark mode the issues that the Windows dark mode shows?
-
If yes, please could you let us know how to change the formatting to get dark mode to behave correctly (i.e. not dark on dark, and with bold not highlighted)? I used the tutorial so that you could reproduce easily, but I have this issue in my current manuscript, that was created with Scrivener 3.0. All the pages are not readable in dark mode in Windows due to the dark on dark theme. They are perfectly readable in mac OS dark mode, withouf any formatting issue. Same with the tutorial.
-
Please look at screenshots 5 and 6. What about the parts that are highlighted instead of being in bold in screenshot 5 (binder section). Bold is not highlighted in screenshot 6 (but the text is not legible). Are you saying that this is also a formatting issue specific to that document? Why would you format one section one way, and another a different way, and why would there be no issue in the Mac dark mode and issues in the Windows dark mode, with the same document? Again, compare the screenshots #1 and #2 in Mac OS dark mode (both pages legible, no bold highlighted issue) and the windows dark mode #5 and #6 (either bold is highlighted, or the text is not legible because of dark on dark theme).
-
You are being very vague about the way it’s possible to reproduce the mac look for dark mode in windows. I have looked at all the options in appearance/colors and I couldn’t find the option that allows to change, specifically, the editor background and the text color, so I can set the background to white and the text to black. I also doubt that this will solve the bold is highlighted issue, but I’m happy to try.
I’m aware that, like compile, dark mode in windows is a work in progress, but I worry about issues such as this not being fixed. I’ve reported a few bugs in compile (two of them fairly serious, see https://forum.literatureandlatte.com/t/compile-problems-with-front-matter/46238/1) that have not been confirmed as being logged, and I’m concerned that it could be because they are dismissed the way you are dismissing these issues with dark mode.
Thanks!
To answer #3 above in case anyone else has the same issue, edit / select all / format / text color / remove color solves the dark text on dark background issue in my manuscript. The text becomes readable (light on dark). So that issue is indeed a formatting issue, even if it’s only one in Windows and not in Mac OS. Thanks for the help.
The above doesn’t solve the issue in the tutorial (in the editor section I used as an example to show the issue), but that’s not really a problem to me 
However, I post screenshots so you can decide whether there is a bug with the highlighted bold issue or not:
In my manuscript, bold doesn’t show as highlighted in dark mode, so i suspect it’s a formatting issue in the tutorial.
If I knew exactly which options I have to change to get the editor page white and the text black, that would be great, but of course I can live with dark mode as it is, it’s legible at least (except for links, the default dark blue is not legible on a dark background, but I’ve changed it to a lighter blue and that’s fine now). Hopefully there will be a “light editor” option in the release, but I agree there are far more important issues to resolve.
Another observation that points to a bug in the Windows Dark Mode version:
I have opened my mac document (master), selected all the document in scrivenings, and removed all color. This doesn’t make any difference in the Mac because there is no issue in Dark Mode on the Mac. But that way I was hoping I wouldn’t have to remove the text color every time I update the PC version of the document.
I then made a copy of the document (I only work on a copy with the Windows beta), and the text was still black when I opened it in Windows Dark Mode…
If I reselect all the documents in Windows, remove color, then the text becomes legible again.
So it looks like the windows version is causing the formatting issue. It’s not in the original document, at least not on the mac.
I attach two new screenshots of the tutorial from the Mac OS version in dark mode with the light editor disabled, and you can see that there are none of the formatting issues present in dark mode in Windows. No highlighted bold in the binder section, no unlegible text in the editor section:
Please compare with the two screenshots above of the the same document in windows, and confirm that you don’t think there is a bug (or two 
) in Dark Mode in windows.
Again, I’m not posting this because of issues in the tutorial, I only use the tutorial so that you can easily reproduce the issues with Dark Mode and compare behaviour between Mac OS and Windows on the same file.
Okay, firstly I thought you were mainly just referring to the lack of a light mode editor mode within dark mode as being the problem. I readily agree there are important tweaks to be made to the text editor and its associated algorithms—that’s what I glossed over a bit when I said it’s a WIP. Glossing over isn’t the same as dismissing them.
To go into further detail on some of these:
- The reason for colours looking less legible is the Mac version’s extensive system for ensuring text remains as such even when coloured. It has a default setting of desaturating coloured text that falls outside of certain thresholds we’ve tested, and brings them back into a range of saturation and brightness that is better suited to a dark background. E.g. if you compare the blue used for headings and interface labels in the tutorial, on Windows the colour remains the same as in light mode (I think), and is to my eye a bit difficult to read. On the Mac the blue is considerably brighter and less saturated.
- “It would be great if such an option was offered in windows. There is no option to keep the editor light when enabling dark mode, or to change this afterwards, as is the case on Mac OS.” Right, that’s something on the todo list, I don’t think anyone would disagree with that. I think the way they have it implemented though, it would take a specific theme to do it.
- Working similarly to the text colour desaturation algorithm is a background colour (highlight/styles/etc.) adjustment that mutes everything, and this one cannot be turned off (because it would very rarely ever be desirable to do so as there is a strong conflict between light and dark where it comes to what is readable behind text). In addition to the technical note below on white highlights—you wouldn’t even see a shock white highlight in the Mac version, even if you deliberately set it. You’ll get dark grey highlight if you try. This goes for those tip boxes as well—on the Mac version the bright yellow is muted down to a dull brown. So this as well is something that needs to be fixed.
There are also some things that are down to differences between the platforms (and perhaps some things we’ve coded in specifically as well, which may fall under the previous category, but I’m not positive without delving through archives—they may or may not be easy to fix:
- Text not appearing black on the Mac, I think that black text in the Mac editor is ignored (everywhere), and treated as having “no color”. If you pop open TextEdit on your Mac and set View ▸ Use Dark Background for Windows off, deliberately colour some sample text black then when turning dark backgrounds back on you’ll see the text is pure white. Where this can be a problem is that literally coloured black text does tend to leak in from Word, Web copy and so forth—and in normal circumstances it is impossible to see, so you don’t really know it has happened.
- Using white as a background colour to mean “no color” is something the Mac has done for a long time. There was actually a bug that popped up in 10.12 I think, where they broke that behaviour and suddenly everyone that had ever used highlights in Scrivener had white highlights in their editor. We had to patch that out ourselves, though Apple did later finally fix it. Point being: the Windows editor has to be aware of that, and by and large it is—but what you’re seeing are artefacts from when it had a spotty implementation for doing so.
- Another thing that would be nice to have fixed is the treatment of cf0 in RTF, as this ends up being black on Windows, but is how the Mac stipulates “no colour”. This has long been a point of friction between the two platforms. Black text is treated as no-color on Mac, but in the Windows editor it is treated literaly. You can search for “black text full screen” in the Windows bug/tech boards here and find this going back all the way to day one.
It’s just now a whole lot more obvious if you use a dark background colour everywhere.
Should it be fixed? I think so, especially in dark mode—but it might not be easy to do so universally (consider that one might actually want black in some cases, how do we distinguish between the two intentions?). Again, it has been around since beta 1 in 2010, so, yeah.
I don’t actually see bold all by itself doing what you describe. I do see some character formatting styles carrying their “highlight” of white text along with them (and weird things like some bullets). This is what I referred to as some early issues from way back when this project was made. Are you seeing this happen in newly created samples, and if so what does it take to see it? Myself if I create a style that looks just like those examples, or even if I take the present-tense Mac tutorial and open it on Windows, I don’t see this problem. That’s what I meant by us needing to clean up the formatting in this project. It has artefacts caused by old bugs in it that have since been fixed, but have left a permanent trace thanks to how RTF works, best I can tell.
I haven’t tried it extensively, but my advice would be to avoid highlights in general (since they don’t mute), and make sure your default formatting on the Mac isn’t accidentally black text, and that when you paste in from web pages and such, either use Paste and Match Style, or be sure to clear text colour after doing so. It’ll honestly probably be easier to fix patchwork problems like that on Windows where you can see it, though—especially since the Documents ▸ Convert ▸ Text to Default Formatting command will strip out cf0 formatted text.
So to combine with the above, how does your experience look if you do the following:
- Create a tutorial using the Mac and save it to PC.
- Select all of the documents within it and reset the formatting to default.
There are still some issues, like pure colours, table cell highlights and so forth (and lists are still… yeah), but again the many woes in this ancient alpha-built tutorial you’re using as an example will not be present. When I made that first copy, the style engine itself wasn’t even working at a fundamental level when I started with it. They got that patched up so I could make the tutorial—so I’m not surprised there are old glitches with it.
Sorry, it’s in the same place it has been since v1, so I didn’t think to annotate that statement. It is for the moment in Appearance: Colors: Editor section, with the Editor and Text settings. This is where you will need to restart frequently if you’re picky and don’t just want black on white.
Again, I don’t know what you mean by bold text being highlighted, but if the background is white and the highlight is white, the tutorial will go back to looking exactly like it does always if you set the editor to white and the text to black, in settings. That formatting has always been there, that’s what I’m getting at, just like most of the text has always been black in that project—it’s just an invisible problem when you have a white highlight on a white background.
Thanks for the detailed reply. To be frank, you did say that there was nothing “incorrect” in the behaviour I was reporting, so that’s as close to dismissing as I can see, but let’s put that behind. It’s good to see that you agree that there are some things to fix in dark mode.
Let’s also put the tutorial behind us, it’s clearly not helping. If you don’t see the issues with the screenshots between the clean way the Mac OS version displays the file and the mess that the Windows version makes of it, then let’s hope that you’re right and that something is simply broken beyond repair in that tutorial. I have no interest in the tutorial, I don’t make tutorials myself, so let’s close that one.
I’m going to focus on the outstanding issues in dark mode with my manuscript, which is a clean manuscript. There is no copy and pasted content from websites or whatever. Just text typed by my own little hands. In most sections there is no formatting, most paragraphs are the “no style” default.
Until Scrivener for Windows is out of beta, or at least until it’s usable as an editor, as compile doesn’t work yet, I have my master file (I’m working on it at the moment) that I only edit with the Mac, and whenever I’m testing the windows beta I make a copy of whatever current version I have of my manuscript and I only open the copy in the Windows version, to make sure that the beta doesn’t break anything. This means that I can’t correct the issue I see in Windows, as if I was moving now to the Windows version. I need to correct them, supposing it’s a formatting issue as you suggest and not a bug in the windows version, in the “master” file, i.e. in the Mac version of Scrivener.
So here is what the outstanding issue is with dark mode in Windows:
-
If, in Windows (as I reported in one f the two posts that you might have missed before your latest reply), I select the text and remove the color, the text becomes legible (light on dark). That’s good.
-
HOWEVER, if I remove the text color in the mac file (I also removed the highlights just to be sure, even if there are none), so that I don’t have to do this every time I copy the master file to check the windows beta, THE TEXT IS NOT LEGIBLE again (dark on dark). I have to remove the color in Windows to make it legible again. I don’t see how this would point to a formatting issue in the Mac original file. How come the same command has only an effect in Windows? Don’t you agree that if I remove the text color in the original Mac file, when I open the copy of the file in Windows I shouldn’t have to do it again?
Regarding the light editor mode, I have solved it, thanks. It’s because the change of colors for these options do not apply until you restart, but the software doesn’t ask you to restart as it does when you switch between default and dark mode. As some other options do have an immediate effect, I couldn’t see that the editor/text effect needed a restart. Thanks for the hint. Hopefully this will be fixed in final and the restart won’t be necessary.
Just to be clear, I’m not complaining about my specific situation, I’m aware that this is a forum to report bugs in a beta. I’m only concerned that there is a bug that corrupts the formatting and causes this issue specifically in the windows version, just like bulleted lists are corrupted when you go from the Mac to Windows.
By the way, I found an issue that is probably already reported, which that in the Windows version, when you “select all” in scrivenings, all the sections are not selected, only the one where the cursor is. So I’m not sure how to select all the document (for example to remove the text color) in the Windows version. In Mac OS, if I select all in scrivenings, all the sections are selected. Please let me know if I need to report this separately or if it’s already been logged.
If I understand AmberV correctly, what is trying to say is that it may ‘always’ be a problem when importing from one operating system to another due to fundamental structural differences on how two different company’s view what some don’t see as a problem. In this case backgrounds colors and how two sides view them. It can change later when coded into the operating system as well.
It’s the same problem users face when importing a document between the two. Say from Word to WordPerfect. The two do their best but not everything will transfer properly.
The programmers at L&L are going to do their best but as stated its a WIP (Work In Progress) and will take time. Probably well after the new version is released along with others.
Thanks for this.
That’s not my understanding.
My understanding is that Amber was saying that this isn’t a bug, but a formatting issue.
This means that the text was formatted with the mac version in a way that causes issues when the PC version reads it (for example, if some text color is specified). She suggested I get rid of this formatted, and I when I do in the windows version, it works.
However, if this was indeed a formatting issue (some text color applied to the text), it should be possible to remove it in the mac version. This is not the case.
I don’t find your comparison with Word and Worperfect useful. These are two different companies. We’re talking here about the same software on two different platforms. It’s as if there was some issues between Word Mac and Word PC.
I think part of the functionality (and ambition) is for the Scrivener 3.0 documents to be inter-changeable between the mac and the PC platform. Especially until it becomes possible to compile on the PC, or for the PC version not to corrupt the formatting of the manuscript, it’s not realistic to be told to correct the “formatting” issue in windows, at least for users that have a choice and have a fully working, fully functional Mac version. That will be acceptable when/if the PC version is 100% usable and there is no way to go back to the Mac version.
However, I agree that it’s entirely possible to live without the dark mode, and that there are far more important issues to resolve. As long as this isn’t brushed under the carpet and is logged as an issue, I really don’t mind how long it takes to fix it. I’d rather have a working compiler and an editor that doesn’t destroy my lists.
Sorry, my explanation for precisely what I was dismissing was in the first paragraph of the previous post (and the entirety of my first response). I was referring to how I thought you were saying the thing that need to be fixed is that Dark Mode should have a light editor instead of dark. Your initial description was:
“In the latest beta, when I select dark mode, the page background becomes dark, instead of staying white as in MacOS. This makes the text difficult to read and dark mode unusable here.”
And in follow-up:
“…In Mac OS, Dark Mode behaves the way I want it to by default, i.e. the interface is dark but the page remains black on white.”
Which to my mind says nothing about the very specific rendering flaws in the tutorial, and is saying that the fact that we don’t have a light mode editor in dark mode is the flaw, a phrasing I would still object to.
So it probably doesn’t help that when I responded there were only four screenshots up, and the entirety of your report was focussed on whether the editor should be light by default.
Did you try, as suggested, using a fresh copy of the tutorial from the Mac? You should see most of these issues in the beta copy of the tutorial are indeed wonky formatting within it. I don’t believe it is even possible to reproduce these problems today, but once again if you can, please let us know how.
We could create code specifically to make the broken beta tutorial from 2017 look nice, but I think it’s better to just fix the tutorial. It’s an example of something no word processor should ever create. This one did—early in its alpha phases before the beta was even released—but as far as I can tell it no longer does.
The main outstanding issue between the two (other than the colour treatment algorithms) is the one that I addressed at length, and that is how the Mac RTF generator uses cf0 to indicate no-color text, which the QT RTF parser reads as black text—which is why when you remove the colour on the Mac it stays black, because (to reiterate) the way it removes colour is the way the PC version sets black. I do believe that is something we can solve, and should, but it is also something very easily self-corrected with the Documents ▸ Convert ▸ Text to Default Formatting on the PC, for the time being.
Hopefully with that tip in mind, and the Alt,d,c,d menu accelerator in mind, you can nuke the problem at the binder level before getting into even looking at the project. It’s so easy to do, that it doesn’t really matter if your workflow is one-way and doesn’t involve bringing Windows modifications back to the Mac—in fact that’s something I routinely do when switching platforms anyway, because of the myriad font differences and so forth—the font I prefer on the Mac looks awful on Windows in general for some reason (Type 1 PostScript OTF turns into pea soup in my experience). It most certainly is a workaround for this specific problem however. As I’ve said several times now (first in a glossing over of how all of this is WIP), we need to fix that, but I’m not sure where it is in the stack of priorities.
Everything gets logged as an issue. You wouldn’t believe the minutiae that I file every day. Yesterday I logged how you can’t right-click in the inspector keywords listing area to more conveniently bring up the same menu you get when clicking on the ••• button specifically, not but centimetres above it. This is a convenience we’ve built into the Mac version, but it is missing on the Windows version. It’s ultimately trivial, and there are dozens of things they should be spending their time on rather than that (such as auto-completion of existing keywords in that same area when typing)—but it is logged, and will remain logged until it is fixed, and I can remove the styling that deletes the passage from the Windows user manual that refers to right-clicking.
Today I filed that Edit ▸ Find ▸ Use Selection for Find should also propagate the selected text string into the Edit ▸ Find ▸ Project Replace tool. I doubt anyone is foaming at the mouth over how that doesn’t currently happen, but it is logged, and will stay that way until fixed.
The black text bug is logged. With every beta release, it is looked at again as I can see from the milestone reporting. It is not forgotten; it is problematic.
Yeah, I don’t know what is going on there. Guess what else is logged? 
OK, if you had not read the whole information it starts to make more sense. I guess it’s just bad luck: 3 weeks without a reply to my initial post, and you don’t even let me finish before replying when I post more information
However, if you read carefully the initial problem description that you quoted, I am not just talking about “light” editor in dark mode. I am saying that the background becomes dark instead of staying white, which makes the text not legible and the dark mode unusable. That’s because the text was dark as well, which it shouldn’t have been. White on dark (as it should be) doesn’t make dark mode unusable. In the follow-up, well, I was not finished when you replied. If you read the three posts, it’s clear that I’m not talking about the absence of light editor. I made it clear that I was posting more due to the image limitations per post, but you might have missed that too.
I’ve also asked you a few times to look at screenshots #5 and #6, that should have been a good hint that you were missing some information. I’ve also said countless times that I DON’T CARE ABOUT FIXING THE TUTORIAL and am only using it as an example, but for some reason you seem to find it entertaining to make me sound like an idiot who wants developers to spend time fixing that document. It’s getting old so I would appreciate if you could stop it. Despite what you seem to think, I’m not an idiot. Or maybe you only read the first lines of every post, in which case you might have missed that as well. I even said that fixing dark mode isn’t a priority, so if someone if foaming at the mouth, it’s not me.
Anyway, I guess I should have posted a screenshot in my initial report to show what I meant, it would have spared us this longwinded and convoluted discussion.
So can we move on now?
To clarify, I was using the same file (literally) as I said many times. My scrivener files are on Dropbox and shared between the mac and the PC (though not at the same time, obviously), and the tutorial was there. I guess it was indeed a PC version of the file that had been copied there during an installation. I found an old backup of the mac tutorial on the mac system disk, and it’s indeed a bit cleaner when opened in Windows. However, the text is still dark by default, and you’ve explained why. The Mac OS version had NO ISSUE displaying either version: broken PC tutorial, old Mac Tutorial, all looks as expected on the Mac, whether in light editor or dark editor. I understand why now, so thanks again for the detailed explanations, I’m glad to hear you intend to fix this…
USING THE MAC TUTORIAL AS AN EXAMPLE, documents/convert/remove all formatting is not an option as a temporary workaround. It messes up all the formatting by adding bold everywhere:
“Remove text color” is easier and less damaging for those who like the dark editor mode, it only needs select all in scrivenings to work.
As far as I’m concerned, the “light editor” (black text on white) mode does solve that problem entirely, once and for all, and it’s much easier than messing with the formatting, as the manuscript is readable right away, so I’m good with this workaround for now.
Finally, I have no doubt that you are logging lots of stuff, but how are we supposed to know, given that most bug reports remain unacknowledged? I posted five bug reports, only one was visibly logged with a bug number added to the title. I’m hoping the other issues are logged, though without a bug number, because they are a lot more important than fixing the dark mode.
You have better things to do, and so do I, so let’s be practical
You’ve confirmed that the restart not requested when changing the editor/text options was logged, which is great.
You have also confirmed that the black text is an issue that should be solved. I was not expecting more than that confirmation, so I’m glad we got there in the end.
So please could you confirm that you’ve logged that it’s impossible to select all the documents in scrivenings, and I think we’re done here! Phew!
Thanks again for all your help, I’ll do my best in the future to attach a screenshot in order to make sure that the report isn’t misunderstood, it would have saved us both a lot of time. 