html file outside spine?

[Ryn]

Hi all,

I'm trying to create an interactive book, with images that are referred to in the text appended to the rear end of the book, containing backlinks to the original reference-link, just like I would do endnotes.

The problem is that this bloats the size of the book (some images are referred to 20+ times throughout the book and thus have to included 20+ times to provide unique backlinks), and allows the reader to access this part of the book, providing a slightly jagged reading experience.

Now, I would prefer it if the file holding all these img tags, captions and backlinks - let's call it "links.html" - were not visible at all. So, I experimented with not listing the file in the spine section of content.opf. This does not validate in Sigil Flightcrew and ePUBcheck.

Is there any way to keep "links.html" outside of the general reading flow (and page count)?

[Ryn]

Just asking the question made it clear to me where to look, and look I did.

I included "linear=no" to the spine entry for "links.html" and it works on the iPad (but not in ADE). I guess I can live with that.

Thanks for listening

[Toxaris]

What is the problem here? You can just reference to the same image time and time again without problem. Since it will be zipped, the size will not increase much. Perhaps 20-50 kb at most.

Avoid "linear=no" since it is not in the specifications. It will work on some readers, but not on most. Try to keep to the standard for compliancy.

[SBT]

If I understand the problem correctly, Toxaris, it is that Ryn wants unique backrefs; you can't get that if you reference to the same file.
A rather daring idea, which I haven't tested: Zip supports symbolic links, so you can have many different names for the same file. That solves both the bloat and the unique backrefs. Don't know about how well this is supported, though.

[Ryn]

Thanks for your answers.

I have no problem linking to the same file multiple times, as far as i can tell it's just the IDs that have to be unique. So I'm not talking about file size bloat so much, but rather page count bloat and the messy-ness of scrolling through the file and finding a host of similar images.

The reason I need to include the same file multiple times is that I would like the reader to link back to same spot where he left off, without him having to remember what chapter or paragraph he was at. Unique backlinks furnish me with that solution, but as I said multiple sets of identical images tacked onto the back of a book feels sort of messy.

I think the linear:no option works best for now, even if it isn't universally supported.

[Jellby]

Originally Posted by Toxaris

Avoid "linear=no" since it is not in the specifications. It will work on some readers, but not on most. Try to keep to the standard for compliancy.

It is in the spec, but it doesn't mandate any specific behaviour, so a reader that ignores linear="no" can still be called spec-compliant.

For the backref problem, I'd just have multiple backrefs. I've done this with footnotes that are referenced in the text and in other footnotes, adding links for "back to text", "back to note 12", "back to note 47", etc.

[Ryn]

Thanks Jellby. I had considered that option, but decided against it in favour of supporting the "flow of reading". Maybe I'm the only one (and 1 is a very small sample size) but having to memorize where I've left off before I follow a link takes away from that selfsame flow of reading.

I realize hopping from footnote to footnote is probably less "flowy", and I think I will adopt your footnote backref strategy for that purpose. As for images that are referred to 20+ times, I think that solution breaks down somewhat, with having 20+ links to pick from when returning, some on a new page.

Sure, the linear=no solution is not perfect either. But then, us ePUB makers live in imperfect universes (and thrive).

Thanks for your insights!

[Jellby]

Any respectable epub reader should have a "back" button, making backref links suprefluous.

[Toxaris]

Originally Posted by Jellby

It is in the spec, but it doesn't mandate any specific behaviour, so a reader that ignores linear="no" can still be called spec-compliant.

Ah, ok. So that apparently translated in my brain as that it is not in the specs. I should have known better than to trust my memory for this things.

[Ryn]

Originally Posted by Jellby

Any respectable epub reader should have a "back" button, making backref links suprefluous.

I guess that rules out iBooks in your estimation

[Jellby]

Yes, and some Sony readers, and ADE for the desktop...

[Toxaris]

Originally Posted by Ryn

I guess that rules out iBooks in your estimation

Well, I rule out iBooks for everything... Especially as ePUB reading application.

[DaleDe]

Originally Posted by Jellby

Yes, and some Sony readers, and ADE for the desktop...

And many other implementations of ADE on various devices. I suspect there are more devices without a back button than there are with one.

Dale

[JSWolf]

Originally Posted by Jellby

Yes, and some Sony readers, and ADE for the desktop...

All Sony Readers have a way to go back be it a hardware button or done via touch.

[Hitch]

Originally Posted by Ryn

Thanks Jellby. I had considered that option, but decided against it in favour of supporting the "flow of reading". Maybe I'm the only one (and 1 is a very small sample size) but having to memorize where I've left off before I follow a link takes away from that selfsame flow of reading.

I realize hopping from footnote to footnote is probably less "flowy", and I think I will adopt your footnote backref strategy for that purpose. As for images that are referred to 20+ times, I think that solution breaks down somewhat, with having 20+ links to pick from when returning, some on a new page.

Sure, the linear=no solution is not perfect either. But then, us ePUB makers live in imperfect universes (and thrive).

Thanks for your insights!

As an add-on to this discussion--being related, although probably not helpful--I slogged through a chunk of the "app" version of Amanda Havard's "The Survivors" and regardless of any technical considerations, my own personal view of hell is that I'll be stuck in Hades with THAT bloody book, forced to page through its precious, self-conscious, twee prose, infused with "useful" "Immersedition" interactive detritus and orts, including the author's notes about why we should "get" an "inside joke," and other bits used to actually try to TELL the story (god forbid she actually put it on the page), not to mention the oh-so-precious fashion-item pop-ups (Prada shoes! Gucci bags! Vivenne Westwood sheaths!), which are surely paving the way for intrusive product placement in BOOKS, for the love of heaven...not to mention the "soundtrack" songs, (from Coldplay! You can listen to it and then, BUY IT NOW, right on your iPad! No, I didn't make that up).

I loathe it. I found it so horridly distracting that I do not believe I could ever again be forced, as a consumer, to buy another. I'm like everyone else; when the original Harry Potter films came out, I thought a "Daily Prophet"-like book/newspaper would be "cool," but of course--that's because THAT is magic. It's not this mind-blowingly dreadful attempt to bring paid product placement "commercials" disquised as "bonus content" into BOOKS. I mean, isn't the gerbil-like attention span of Americans and everyone else already short ENOUGH? Now we have to explain the book to them, that wasn't written well enough? Put character bios every few pages, so our brain-dead readers can pop it up to remind themselves as to who "John" is? Is the writing so execrable, the characters so lifeless and unimaginative, that we don't think the readers can remember who the impossibly-beautiful-supernatural-heroine-with-lavendar-eyes is, nor the name of her impossibly-beautiful-Armani-wearing, soon-to-be-romantic-interest?

ARRRGGHHHHHHHHHHHHHHHHHHHHHHHHHH!

Yes. This is possibly an OT rant, but...fellow ePUB makers, let's stop feeding the crows, just because they like "pretty shiny things," can we? Apple, I entreat all you Jobblesheads still populating and worshipping at the Temple of Steve: stop contributing to the demolition of the human brain, please. A book is supposed to make people use their brains for something other than a paperweight to hold their ears on their heads while you pump vapidness into them.

Nothing against the OP; we who make the books have to earn our bread, feed our families, pay the bills...but I couldn't get past page 36 of this thing. It was poorly written to begin with (simply my own opinion, but I freely admit I'm not their target audience), but the "Immersedition" was so distracting that I don't think a heretofore undiscovered Dorothy L Sayers done in this fashion could have kept me reading (I shudder to think what THAT might have looked like)--and that's saying something.

My $.02, FWIW--and it's probably worth less than that. Just had to get it off my chest. Had a client who called, raving about this being "the future of ebooks," insisting I DL this thing...and that thought alone is enough to make me scream.

Hitch