Image with a Hyperlink questions

8 posts / 0 new
Last post

Hi There,

I was trying to hyperlink or anchor an image in my book to a certain chapter xhtml page as the destination. It works in Adobe digital additions and on some eReaders, but not all of them. I'm wondering if anyone else has this problem and knows a work around?

<div class="_idGenObjectLayout-1">
<div class="_idGenPageitem-2">
<a href="Chapter-I-The_Parsonage.xhtml"><img alt="" class="_idGenPageitem-1" src="../Images/thumbimage1.png" /></a>
</div>
</div>

I've tried anchoring but I get the same results. I even pushed to remaking my entire book into one xhtml page and creating the toc myself, but it still wont work across all devices.

Which also makes me wonder is there a list of things you can not do in EPUB3 format? Since it's a stripped down format with limited capabilities and strict rules. For example you can't hide a hyperlink underline or change its color (works on some devices but not all).

The quality of EPUB 2 reading systems varies widely. It all depends on how well they've been developed, but lack of support for obvious functionality isn't a failing of the EPUB format itself. It comes with the territory of being an open format that anyone can create a reader for.

Crappy linking abilities isn't common, but I've seen it before, as loading the correct location in a dynamically-paginated document isn't trivial.

If the file works in all the major reading systems like ADE, iBooks, Kobo, Nook, etc., then whatever reading system you're finding buggy is just buggy. Other than reporting problems to the developers you're probably not going to find a solution to something as basic as linking from one location to another. Consider how likely your readers are to be using a broken reading system, too, before investing too much effort in trying to be perfect everywhere.

It probably goes without saying that you should ensure the publication is valid by checking it with epubcheck.

And CSS support is optional. eInk devices are only going to have a limited range of capabilities, and support is only recommended. Some reading systems have no viewport at all, after all, and only render the content by TTS.

You're typically going to find better support in EPUB 3 reading systems for CSS, as being more directly based on the open web platform, reading systems are typically built on webkit and its capabilities.

Thank you for replying. I'll look into the webkit features but it does bother me to a degree that books are so much more, and in a digital world they should be more, we should have more control over interaction between the reader and the book, and also it's aesthetics. It just seems so backwards to not include something as basic as image anchor linking for purposes of universal reader platform compatibility. Or that alpha channels are supported on a device but not in the epub reader. Will Epub finally get to 4.0 and fix these issues? Who can I actually write to for improvements-augh wait, that's a dumb question, I'm in their forum aren't I? Okay. will gripe it out in a long email to them.Thanks for the responding back to me. Appreciate it.

Thank you for replying. I'll look into the webkit features but it does bother me to a degree that books are so much more, and in a digital world they should be more, we should have more control over interaction between the reader and the book, and also it's aesthetics. It just seems so backwards to not include something as basic as image anchor linking for purposes of universal reader platform compatibility. Or that alpha channels are supported on a device but not in the epub reader. Will Epub finally get to 4.0 and fix these issues? Who can I actually write to for improvements-augh wait, that's a dumb question, I'm in their forum aren't I? Okay. will gripe it out in a long email to them.Thanks for the responding back to me. Appreciate it.

You can rail against the IDPF if you just want to vent some anger, but it's not going to change much. :)

It's not a lot different than railing against the W3C when vendors don't support features or decide to do things their own way. Both are consortiums that promote open standards, but neither has the power to make the user agent developers support what they don't -- or won't -- support.

The epubtest.org site is one measure of where EPUB 3 reading systems are, and a motivator to keep people developing (unless you like poor scores). It's not a comprehensive test of all functionality a reading systems could support by any stretch, but gives an idea where they are in relation to supporting key features.

EPUB 2 is obsolete as a format, but we are still in a transition period as reading systems roll out support for EPUB 3. The good news is that since all EPUB 3 reading systems are being built on modern Web browser foundations, we should from here on out see a much higher level of support of building-block Web Standards. It is possible to create EPUB 3 content that "falls back" gracefully on older reading systems and for now that's probably a good idea for basic text eBooks since thare still lots of EPUB 2 reading systems out there. For more advanced eBooks, particularly those that don't make too much sense on E Ink devices in the first place because they need color, interactivity, or just a tablet-sized screen... then you can choose to go all-in on EPUB 3 features and target just these apps and devices.

It's not too dissimilar to the web browser situation, where only in the last year or so has it become really feasible to target only modern HTML5 browsers and give up on workarounds and polyfills to make things work all the way back to IE6 (which even today still has nearly 10% global market share, sigh). We are a bit further behind with EPUB because EPUB 2 was aimed mainly at very simple content like novels that made sense on E Ink devices, was based on a profile of very old version of HTML (XHTML 1.1), and in most cases was implemented by specialized renderers not real browser engines. But the leap forward to EPUB 3 gets us synched with full HTML5 and the modern Open Web Platform.

Did you try it with simple file and fragment identifier names? Maybe there is only a problem with specific characters?
Does the hyperlink work with text instead of img as content?

For example try a reference like file.xhtml#sample or example.svg#myview

Concerning your example, because the alt-attribute is empty, your PNG turns out to be purely decorative, therefore your hyperlink target as well. This means, there cannot be any important content referenced - maybe a reason to ignore the hyperlink entirely for accessibility reasons ;o)

Did you try it with simpler file and fragment identifier names? Maybe there is only a problem with specific characters?
Does the hyperlink work with text instead of img as content?

For example try a reference like file.xhtml#sample or example.svg#myview

Concerning your example, because the alt-attribute is empty, your PNG turns out to be purely decorative, therefore your hyperlink target as well. This means, there cannot be any important content referenced - maybe a reason to ignore the hyperlink entirely for accessibility reasons ;o)

Secondary menu