I’m splitting this to a new thread, not so much because the one you responded to wasn’t relevant or recent enough, but because what you are currently struggling against is very specific to the Windows version.
It’s worth noting that the feature requests in that thread all ended up eventually being addressed in v3’s design. We did end up adding all of the stuff you’re asking for still.
Which means reiterating the disclaimers I stated in the previous thread: the Windows version of the native ebook generator is missing some key aspects of the intended design, and does not execute other needed aspects correctly, meaning much of that discussion, and the linked solution in one of my posts, would be more difficult to achieve at the moment. I.e. some of what you are observing and reacting to are indeed gaps and bugs.
Bugs aside, at a broader and more philosophical level, there is something to be said for approaching ebook design in a more direct manner, at certain point, rather than expecting us to build an exponential quantity of checkboxes that describe all of the possible permutations of design choices people might wish to make. The GUI should be thought of as a 95% tool, where it’s going to be doing things in a way most people want most of the time. And that’s fine, so long as we give you good tools for getting as close to 100% of achieving your design vision, as possible.
Where I would differ from the “just use Sigil” line is that where it comes to structure (HTML) and design (CSS), there is nothing you can do in Sigil that you cannot enshrine into your compile settings and project design. For something like this, there is no need to save your final layout to something done by hand every single time you compile. You certainly could, but I would want to find a way to state from Scrivener’s side what I want, leaving Sigil for minor things Scrivener cannot do at all that can be achieved quickly, like importing font assets into the .epub container (which I’ve already 100% set up and designated the use of, in Scrivener).
Again there is a Windows caveat of needing a workaround since again the design that is meant to make this easy has gaps and bugs in all of the places you need.
By workaround I mean establishing the <divs> you need directly as HTML in the editor, using a paragraph style called “Raw HTML Block” (which our default “Ebook” compile format is configured to handle correctly out of the box). Once you have those, you can implement the CSS for controlling page flow as I describe in this post.
If you need a more detailed walk-through of the concept behind this, refer to this thread, where I provide an example of how one could create call-out boxes or sidebar elements in an ebook. The practical example there is for a different application of design, of course, you want a simulated page break instead of a box drawing around the POV switch—but at this level of what we’re talking about the structure is identical. In both cases we have a chunk of text in a larger formal section (chapter) that needs to do something special. What that ‘special’ is, be it bright green text or floating boxes or page breaks, is up to you and what CSS can do.
On the plus side this is the kind of workaround that won’t break one day in the future, when these problems are fixed. Basically there are layers of control in Scrivener, that we provide. There are some higher level easier to use layers that should be there that aren’t working. This workaround uses one of the ground level “I need total control!” layers to achieve what the easier tools should be doing, in other words. This lower level approach won’t stop doing what it does by fixing those.
I’m not sure why a new page marker is related to the creation of a TOC entry in any logical sense. Surely they are separate decisions on the part of the author? One is about visual formatting, and the other is about navigation.
That isn’t a Scrivener thing though, that is just how some ebook readers, those that simulate a paper page reading experience, will present a navigational section break to the reader. There is nothing in Scrivener’s default output that would force the matter. Or in other words, yes this approach of trying to use section breaks to do everything but a section break, specifically to trick some ebook readers into employing a page break, may be frustrating but that’s because you aren’t only going against Scrivener’s grain, but the design principles of the ePub specification itself.
To be fair to your argument though, it could be framed as saying that Scrivener should have tools for chunking up text within a proper navigation section and doing stuff with it (like page breaks or call-out box adornments).
Yup! It should. That is how it was designed to work and rather simply so at that, so that while writing all you have to do is create a new chunk of text and swap its Section Type to “POV Switch” (or whatever).
