This bug has been reported multiple times over. Each time, it is generally suggested a snippet would work.
The issue is that a snippet will work very poorly unless it’s based on hard-coded colours or other variables, since Obsidian forcibly discards .theme-dark and adds .theme-light on its own accord to the body whenever an Export to PDF is conducted. This means that if someone were you use variables that have already been defined in light mode, it will take light mode colours, unless a whole new set of variables are created and keyed into each theme. That means, if I were to use var(--background-primary) for something, this would always take light mode colours regardless.
The code causing the problem in question is a three line segment in app.js:
document.body.addClass(“theme-light”),
document.body.removeClass(“theme-dark”),
document.body.removeClass(“theme-dark”),
In fact, these three lines being removed will save a lot of trouble.
Obsidian generally respects user customisations over whether they would like to export to PDF in light mode and dark mode. In that sense it does not make any sense that the app forces one to always use the light mode, especially if the export is meant to be for digital consumption and not for print.
If the worry is that users will end up exporting white on white PDFs, there are some CSS fixes that allows users to export full backgrounds in Obsidian, which I would be happy to share. Here are some examples below which I used Obsidian to export by setting a breakpoint and then manually removing the appended .theme-light and replacing .theme-dark back. These options are currently not possible for the normal user because of the hardcoded options currently present in app.js.
Any alternative keeping .theme-light in the body styling will at least require significant effort to get styling from tables to callouts rewired just to get it to look somewhat like the dark theme.
2 Likes
This is not a bug. What you see is intentional.
The user have expressed a preference about app theme not in the “export to pdf” theme.
Most of the users, when they export to PDF, they do it for printing on paper, hence the forcing of a light-theme.
If you want to customize how the export to PDFs works, you can use the @media print in your theme or a CSS snippets.
You can open also search/open FR asking to add a color-scheme selection in the “export to pdf” modal window.
That’s quite the assumption to make considering 1) this “feature”/bug did not exist before, and 2) at least 106 people disagree that exporting to PDF looks fine, and that 3) the people in the Print thread fundamentally agree that Exporting to PDF should not look the same as for print.
Plus, I’m a theme dev, and the person who actually pushed on re: the CSSClass bug in Export to PDF which you kept rebuffing others that it wasn’t a bug at all when it actually was (second link). In that sense I probably do have more technical knowledge than you in terms of exporting to PDF and of CSS, and I can confidently tell you that like 4 years ago, @media print does absolutely nothing to resolve this since what we see isn’t created via @media print, but via what is set via a separate .print class div and everything below that, which inherits everything from the body (including the `.theme-light class) and which is also the reason why the cssclass bit was a bug in the first place. I believe Liam can concur this is the process where the Export to PDF result is generated from.
I am happy to leave this as it is as I have my own workarounds to exporting to PDF (by setting a breakpoint and manually dropping the theme-light classes) but considering that 1) this intentional feature did not exist for quite a few years, 2) exporting to PDF is for print is an assumption that does not hold (then why would we have the print FR and so many people complaining?), and 3) it pretty much goes against the ethos/manifesto that Obsidian should be malleable by creating a new bug that forces everyone to do the same thing (furthermore, one based on an assumption that does not hold), I do hope that this can be reconsidered.
I think you are pushing your argument by assuming that the people who upvoted that comment, they did it because they want what you want.
Right now, the export to PDF is tailored for printing. We do not a separate export to PDF for digital consumption and export to PDF for Printing. I understand you don’t like that. I understand you would probably prefer to have two separate workflows.
I think you should be able to achieve what you want in the export to PDF, perhaps at the expense of having to redefining you whole dark theme in there.
I looked in the FR section and I haven’t seen one asking for having separate workflows or even a simple one asking for export to PDF to closely match the theme. However, I do recall several bug reports complaining that the export to PDF looked horrible.
I believe that what you are asking is legitimate FR, but not a bug. So feel free to open one.
1 Like
