Isn’t that a tad unfortunate though? Say a user designed his/her compile format just the way he/she wants his/her book in print. And then has to start over for the ebook version.
Would going about it the other way around solve this? As in, always design your compile format from the “Ebook” compile format? Regardless of the fact that it’ll also be used for print (say, compile to PDF).
Or design your ebook first, then duplicate that compile format and adapt the version of it now intended for print?
Almost all of the built-ins would not be terribly relevant to eBooks, which is why we did not take the time to create CSS for them. For example, there would be little use in a “paperback” for ebook, or a double-spaced submission manuscript.
That said, I did not mean for my comment to suggest one should never try to create a format that works across different targets. If you are so inclined to do so, then have at it. You will probably want to keep a copy of a dummy project beside your main one though, so you can compare the stock Ebook settings when creating one from scratch.
In this case specifically, I recalled this being an issue and did some searching for it. Here is the original thread, with tips on how to correct the problem in formats created from scratch, or adapted from starting points other than “Ebook”.
To be clear the failure state here is unavoidable if you don’t set up styles correctly, but it should fail more gracefully than printing a double-title. That part is a known bug.
One thing I’d really like to know and that wasn’t quite answered is, should one use the “Ebook” compile format as a starting point for his/her own compile format, is there a risk of damaging the specifics of an Epub compile if tweaking it over and over while it is rather in a “compile to PDF” state, for e.g. ?
(Beside deleting section layouts, which is quite obviously not something to do. At least not the “Table of content” one.)
My underlying question being: Is there a way to use the same compile format for both Print and Epub, so that formatting your book is a one time operation?
You don’t have to start from “Ebook” if you don’t want to, just be prepared to do more legwork in getting the basic details wired up in the way we’ve already done for you in the pre-built format.
As for whether there is wisdom in trying to use the same design in print and ebooks, or even whether one should use Scrivener at all for the former, that’s another matter and more subjective to some degree.
Myself I would not want the same design in two so radically different mediums, and perhaps what you are asking is essentially this concept: that in many cases what looks nice in a paperback isn’t going to look nice in an ebook, so if you go into your Chapter Heading layout and change how it looks to fit an eInk screen better, I suppose you could think of that as “damaging” how it looks for PDF (and vice versa).
But I don’t understand why you would really want to have the same format. That sounds like it would be extremely limiting, to me, in what you could do. Just design one to a point of relative completion, then duplicate it and make what changes you need to suit the medium. Broader design decisions would need to be implemented twice from that point forward, but the idea would be to only fork after you’ve made the bulk of those kinds of decisions.
So, I think I have my answer: best to start off the “Ebook” compile format no matter what.
If you are gonna fork (duplicate and dedicate) the compile format at some point (and I agree with that, that’s exactly what I meant, not that the formatting should be exactly the same in both mediums), that would be logical.
My question was: to which degree do one risks damaging the epub functionalities in that said compile format meanwhile (or up to the forking point). Are all those functionalities made invisible/unchangeable while the compile format is set to compile to PDF is what I’d really like to know.
Or is there some settings that one would normally want to tweak for a PDF compile that would make the epub compile later dysfunctional.
Essentially all settings not related to a type, that get hidden when you switch file types, are saved in the background. Any settings you see in both will “conflict” in most cases. So for example the CSS pane will vanish when you switch to PDF, and it won’t get wiped if you do so (we probably wouldn’t allow you to hot switch types at all if it were that volatile). But if you change the font size for your Chapter Heading layout that will change both. In most cases that is considered desirable. You wouldn’t want to have to redo everything if you switched from RTF to ODT for example.
Any settings that could be considered valuable or essential that you can think of that would happen to be common to the two formats? (PDF and Epub – or RTF and Epub, whatever.)
Anything pertaining to Epub functionality that isn’t exclusive.
Say, for example, that thing that made the TOC’s title appear twice…
The goal here is to know to which point what you just said is also applicable to an Epub compile.
I am trying to know up to what point one can benefit from the first for the second without making the second (epub compile) dysfunctional.
Sorry for having that many questions, but I feel it matters.
Sorry I don’t really know how to answer that question. It feels like one that is very subjective to me—what is important to you may be something I consider inconsequential for myself. It also feels like something easy enough to figure out through experimentation, which is safe enough to do since it’s so easy to make a copy and test an idea with it.
As I said above, I think the best way to make your own format, if you aren’t starting from “Ebook”, is to keep a vanilla copy of it open in a side project and go through pane by pane to make sure you have the basics set up in a way that makes sense. Perhaps if one anticipates doing this a lot, they could create for themselves a “Basic Ebook” starter (that isn’t meant to be used directly, but duplicated from for future projects), that has some of the basic assumptions like styles already set up.