Why I’m Publishing My First Novel in a Format You’ve Never Heard Of
medium.com
medium.com
With no way to make a backup I'm reliant on them being always on and still around 10+ years later if and when I want to read it again.
But, the format also leaves much to be desired. The superbooks' "features" seem more like limitations. I cannot adjust text font or size, which is a feature! Something I've been able to do with every other ereader. I've also run into instances where the preview has text cut off even at 100% zoom. https://i.imgur.com/z8OldNU.png
> I've also run into instances where the preview has text cut off even at 100% zoom.
Which [device, os and browser] are you on?
> I'm reliant on them being always on and still around 10+ years later…
These books are hosted using a service-worker, and will work even if our service goes offline for sometime or your device disconnects from the Internet.
https://i.imgur.com/veYtCUV.png Iphone xs safari. Unable to scroll/pinch/etc. Closing tab fixes.
Can we look into the errors on your browser's console?
> zoom
Quick note: As a real reader will you prefer to pinchzoom on every page of the book or scale the book just once from the settings panel and be good to go?
> scroll
Scrolling is a no-go for books. My cofounder has written about this at length here: https://bubblin.io/concerns
---
We are aware about an issue that prevents us from using pinch features to scale content correctly on iOS Safari. The bug is raised with Apple for this and I'm hoping they'll catch up on it soon. :-)
Access to fetch at 'https://ft-polyfill-service.herokuapp.com/v2/polyfill.min.js... from origin 'https://bubblin.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled. serviceworker.js:1 Uncaught (in promise) TypeError: Failed to fetch Promise.then (async) (anonymous) @ serviceworker.js:1 serviceworker.js:1 Uncaught (in promise) TypeError: Failed to fetch (anonymous) @ serviceworker.js:1 serviceworker.js:1 Uncaught (in promise) TypeError: Failed to fetch
> It’s easy to forget that it’s been nearly 12 years since the last major innovation in the ebooks space.
Well, except EPUB 3.0 in 2011 and 3.1 in 2017.
* Any language which generates WebAssembly could then be used (there are many already. Go, C/C++, Rust, (etc)... with very large growth happening)
* Likely to be a safer execution environment
Reflow is bad for books. It kills referential accessibility [1] which is a critical feature of codex-style format that follows from the most common definition of a book [2].
[1] https://bubblin.io/blog/referential-accessibility
[2] https://en.m.wikipedia.org/wiki/Book
> It sounds like a nightmare to handle when editing.
This book was programmatically generated using standard markdown manuscript and a paginator library called m2s [1]. I'd say it was pure bliss for me to edit David's book page-by-page!
Not at all. Use paragraph numbers instead of page numbers. You can create an 'id' attribute for each paragraph: <p id="para45">...</p>. As you scroll the viewer can update the location bar with a suitable fragment id: chapter3.html#para45
That! …but one with strong layout and referential accessibility of page numbers would be even better! I think we need page-wise referencing on novels and prose fiction too. It opens us up to the possibility of having real conversations and annotations deep inside the content of a book.
Reflow otherwise has always been a bane of _all_ digital books because it wasn't possible to scale content without leaving room for it. That's also the raison d'etre for other "non-web" formats, digital stores and even hardware to exist.
Page numbers are a small additional value; pagination comes for free with print so it's an easy fallback, but there's a reason why content that is most intensely dependent on referential accessibility, like codified laws, doesn't rely on it.
> I think we need page-wise referencing on novels and prose fiction too.
It's of some use for criticism, but criticism isn't the purpose of most prose fiction. It's certainly not needed for reading, and resizability does more for the primary use than page numbering. (Of course, if you really need it, “referencde page numbering” of the type used in presentations of paginated content where page number references are commonly used like the Federal Register or court decisions when reproduced in contexts with different than source (or no) pagination can be used.)
> Reflow otherwise has always been a bane of _all_ digital books because it wasn't possible to scale content without leaving room for it.
I've seen plenty of books that aren't prose fiction that work well with reflow; PragProg epubs are particularly good that way.
> That's also the raison d'etre for other "non-web" formats, digital stores and even hardware to exist.
No, it's not; even to the extent reflow is a problem for some content, PDF had total-layout-control solved before any of the alternatives, and ePubs had strict pagination and layout control as an option since 3.0; the reason for the alternatives seem to be the same reasons for any other content toolchain, distribution, and consumption ecosystem walled-garden—it's not about serving a market need, it's about capturing a market segment and creating a cost to switch out so that you can charge monopoly rents.
Why not a PDF?
Beats me. At least existing ebook readers can display PDFs.
If it is more like PDF, then a comparison with PDF is in order.
Forget about EPUB, tell me why your format is better than PDF!
PDFs are a skeuomorphic parallel of formatting that's natural to physical paper where as Superbooks adopt narrow column formatting of pure web with styling that scales responsively. Then there are granular differences in accessibility, new possibilities in layouts and content (webgl, AR/VR, CSS3, canvas art etc.), responsiveness, offline-first nature, iPad-first approach and usage of git for collaboration under the hood and a modern browser for final consumption.
To sum it up: Superbooks follow the most common convention and definition of a book. It is more 'consumer ready' than anything else on market.
You need to download any content to your browser to view it; otoh, online and in-browser renderers for both epub (which is mostly web tech in a package format) and PDF are ludicrously common.
> Superbook format on the other hand is a website. Huge difference!
Superbooks, on a quick glance through some, seem to have a visual look much like epub, the wasted space from aspect ratio mismatch of PDF, and the speed/responsiveness of cold molasses.
> PDFs are a skeuomorphic parallel of formatting that's natural to physical paper where as Superbooks adopt narrow column formatting of pure web with styling that scales responsively.
I don't see how PDF is any more skeumorphic than Superbooks (certainly, most PDF readers don't use skeumorphic—and dog slow—page turn animations.) You can, of course, design PDF with any fixed layout you want.
And AFAICT the main responsiveness Superbooks have is automatically choosing between single-page and two-page view based on screen aspect ratio/orientation.
I don't know what the “narrow column formatting” referred to is; the only webbish formatting I see is that pages seem to have symmetric bordering white space on left and right pages (but still have left and right pages distinguished, as in the version of 1984, by page number location.)
2. On value of page_number referencing vs. seeking people to use ids, classes and semantics: No, I think we are not on the same page here… ;-)
3. Speed/responsiveness: Page turns are @60FPS +/-5 give or take, and can easily be tuned/turned off from Settings. From analytics, you went in with an intent to surf the web capriciously and confused that with the intent to actually read a book, isn't it?
Thanks, but "hell no".