Yes, thank you for that explanation and the detailed steps… I got the restricted content aspect to work in iBooks!
Here’s where my “restricted content” testing stands…
iBooks handles an ePub with restricted content properly.
Adobe Digital Editions 4.5 does not.
Calibre 3.16.0 does not.
Kindle Previewer 3.17.1 does not.
Kindle app on Mac, Kindle app on iPhone, and Kindle Paperwhite do not correctly handle a mobi file generated from Scrivener in the same way as the ePub.
It will work in web browsers when the HTML is broken up properly.
Well, 2 out of 6 ain’t bad. Actually, it is rather bad. Maybe more support will come in time.
In any case, it looks like Scrivener is doing all it can do to support this feature, so I’m happy with it. Also, I love the support and responsiveness of this forum. Thanks everyone!
The way this works, incidentally, is that when you tell Scrivener to hide the section in the eBook, it gets the “Linear” attribute for the section element in the OPF XML of the ebook to “No” - this means that it will not be navigable when you move through the book linearly. Looking at this discussion on the Kindle forums, it seems that the Kindle does not yet support this flag. The OPF file is part of the epub format, and Kindle files are created by converting a bunch of files that epubs also use using Amazon’s kindlegen utility. So, hopefully Amazon will add this feature at some point. I’ll need to do a little more research, because I might need to remove this option from the Kindle format if it has no effect.
Digital Editions has no excuse, though! It’s part of the epub specifications, so if Digital Editions isn’t respecting it then they are not implementing epub support correctly…
There are also the softer means of encouraging reader compliance:
Link to anchors down low on pages (link not to targetpage.xhtml but targetpage.xhtml#nextaction. Fill the upper part of the pages with warnings of spoilers.
Shuffle the order of the xhtml files so that anyone just trying to page through will get nothing but a jumble.
Include in your navigation TOC only a few pages, like a How to experience this interactive story page, plus some common backmatter material. (Amazon’s conversion process may try to force the issue and index everything, but if you have no H elements, maybe they won’t. I haven’t tested that. And you could also just include major inflection points in the story, like “Will Joe catch the bus?” so people can jump to points again in case they get lost.)
Any html TOC can go at the end of the book.
This is all pretty straightforward if you’re getting into the epub code in an app like Sigil.
ADE is a mixed bag from what I can see. It does, at least for me, restrict navigation to the initial section, and none of the keyboard shortcuts or associated menu commands for flipping to the Next or Previous page are functional. The result of the test .epub is a single screen book. Likewise you cannot click the Left and Right buttons in the footer bar.
But you can scroll manually through the book content and get into hidden sections while doing so. Thus that scrubber must not be attached to any of the standard ePub navigation controls.
That’s probably a good sign for those physical reader devices based on the ADE engine. The GUI scrubber isn’t a feature that is present on most book readers.
Just got around to trying this. I was assuming I’d find an HTML file per binder document; instead I find a single body.xhtml (not counting contents.xhtml). Is there an option I missed? (The idea being that the reader can’t simply scroll ahead.)
This works fairly nicely, but the CSS doesn’t capture the font I’d like used. For comparison, compiling straight to HTML does record this (the latter will capture
font: 14.7px Arial
; the first won’t).
Is there a way to use this technique and still have control over the font used?
