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. 