NOOK Color -- using an IMG as a link

[taneal1]

Hello All,

Creating a Link using an image works perfectly in Sigil, however, when I load the working ePub into my Nook, the image link does not work.

Can anyone tell me a way to do this? Or is it something that cannot be done in the Nook???

Thanks in advance for any ideas/thoughts,

Tom

[DiapDealer]

I don't know any Nook specifics myself, but there are many reading systems that won't honor images as links. Mainly because tapping/double-tapping images is how most reading systems initiate their Pan & Zoom features.

[Hitch]

Originally Posted by DiapDealer

I don't know any Nook specifics myself, but there are many reading systems that won't honor images as links. Mainly because tapping/double-tapping images is how most reading systems initiate their Pan & Zoom features.

What Diap said. In some devices, if the user will persist, and do a "long tap," the link will activate...but bear in mind that many--MANY--eReaders do not have web browsers in them, in which case, if you're trying to get someone from A to B, you will have achieved nothing but pissing them off.

use plain old raw naked links. Use a link-shortener that won't be gone, tomorrow, e.g., Bit.ly or Goo.gl. Put the FULL-length link, below it, so that they can find it, if the shortened address gets nuked for some reason.

THINK about your potential reader. Not what you think looks cool. I'm not criticizing, but geeezus, I must have this same convo 4x weekly, with people that give no thought to the reality that the vast majority of standalone Ereaders either have no browser or a sh*tty one.

Hitch

[taneal1]

Originally Posted by DiapDealer

I don't know any Nook specifics myself, but there are many reading systems that won't honor images as links. Mainly because tapping/double-tapping images is how most reading systems initiate their Pan & Zoom features.

I suspect you are right.

Nook also apparently overrides the background color tag to allow text highlighting. I wish Nook would simply list the subset of available html/css code rather than force users to discover these issues on their own.



Tom

[taneal1]

Originally Posted by Hitch

THINK about your potential reader. Not what you think looks cool. I'm not criticizing, but geeezus, I must have this same convo 4x weekly, with people that give no thought to the reality that the vast majority of standalone Ereaders either have no browser or a sh*tty one.

Hitch

Your reply is appreciated, but your are making a LOT of assumptions here.

I didn't elaborate on WHY I want to use an image as a link because the required code is the same whatever your purpose. The Nook is an e-reader, with optional browser capability. The IMG link would not be used to go online.

My desire is to use an IMG as a Chapter to Table of Contents link rather than text. This would allow "stylized" text within a graphic as the link, without also including otherwise unnecessary text.

This may consider this a "frill", but the graphic would be quite helpful to a child who is learning to read, has limited reading skills, is learning a 2nd language, etc.

It probably won't work, but I will try using "Map" along with the graphic...

[Hitch]

Originally Posted by taneal1

Your reply is appreciated, but your are making a LOT of assumptions here.

I didn't elaborate on WHY I want to use an image as a link because the required code is the same whatever your purpose. The Nook is an e-reader, with optional browser capability. The IMG link would not be used to go online.

I know what Nook is.

Spoiler:

(My business has made ~3500 eBooks, for pretty much every eReader in existence.)

You're right, I did make an assumption. Sorry 'bout that. As I said, I get that question, from our clients, 4-5x weekly, so I did, indeed, assume. Mea culpa

My desire is to use an IMG as a Chapter to Table of Contents link rather than text. This would allow "stylized" text within a graphic as the link, without also including otherwise unnecessary text.

Yes, I've seen a lot of folks who've wanted this, over the last near-decade.

This may consider this a "frill", but the graphic would be quite helpful to a child who is learning to read, has limited reading skills, is learning a 2nd language, etc.

I can see why that might be helpful.

It probably won't work, but I will try using "Map" along with the graphic...

Map won't work. You need javascript for that, and 99% of all eReaders don't have that type of publisher-exploitable javascript.

Also, if you're planning on publishing through NookPress, you can't publish a book that uses that type of fixed-layout exploit.

Good luck, but...you're trying to push a chain up a hill.


Hitch

[Tex2002ans]

Originally Posted by Hitch

Map won't work. You need javascript for that, and 99% of all eReaders don't have that type of publisher-exploitable javascript.

<map> is actually built into HTML itself:

https://www.w3schools.com/tags/tag_map.asp

but yeah... that won't work in most actual ereaders. While <map> is "officially a part of the EPUB spec":

1. ADE doesn't support it (at least in EPUB2. No idea about their EPUB3 renderer). That throws out the vast majority of dedicated ereaders.
2. Many devices are not touch screen... so there would be no way to click a certain area.

... and I know this wasn't brought up, but I don't even believe Kindles support <map>. I don't see mention of it anywhere in the Kindle Publishing Guidelines.

Originally Posted by taneal1

My desire is to use an IMG as a Chapter to Table of Contents link rather than text. This would allow "stylized" text within a graphic as the link, without also including otherwise unnecessary text.

This may consider this a "frill", but the graphic would be quite helpful to a child who is learning to read, has limited reading skills, is learning a 2nd language, etc.

Even if you just wrapped an image in a normal link, such as:

<a href="../Text/TOC.xhtml"><img src="../TableofContents.png" /></a>

there are also quite a few bugs/quirks in readers themselves:

1. Links around images on some devices will not work at all. It will just act as if it was a normal <img>.
2. This will interfere with pan/zoom functionality.
3. There may be absolutely zero indication the image is even clickable. (Unlike a normal hyperlink that is blue+underlined.)

[exaltedwombat]

This is the same fallacy that spawned the 'Ribbon' interface in Microsoft (and other copy-cat) products a few years ago. Mostly, the best sign to a function is the name of that function. And anyone who uses a device soon learns what a link looks like. Not a picture, not a subtle roll-over behaviour, but a piece of blue, underlined text.

[Hitch]

Originally Posted by Tex2002ans

<map> is actually built into HTML itself:

https://www.w3schools.com/tags/tag_map.asp

but yeah... that won't work in most actual ereaders. While <map> is "officially a part of the EPUB spec":

1. ADE doesn't support it (at least in EPUB2. No idea about their EPUB3 renderer). That throws out the vast majority of dedicated ereaders.
2. Many devices are not touch screen... so there would be no way to click a certain area.

... and I know this wasn't brought up, but I don't even believe Kindles support <map>. I don't see mention of it anywhere in the Kindle Publishing Guidelines.

Are you sure you don't need JS, or at least JSON, etc., for parsing (I know that's not the right term..) the various areas on the map? ??? Are you sure? I know you're a programmer, sweetie. But I could swear that I read something, somewhere in time (far enough back that my ancient brain can't pull it out...) about that. No?

Even if you just wrapped an image in a normal link, such as:

<a href="../Text/TOC.xhtml"><img src="../TableofContents.png" /></a>

there are also quite a few bugs/quirks in readers themselves:

1. Links around images on some devices will not work at all. It will just act as if it was a normal <img>.
2. This will interfere with pan/zoom functionality.
3. There may be absolutely zero indication the image is even clickable. (Unlike a normal hyperlink that is blue+underlined.)

I know for a fact that map's not supported in MOBI. Again, we're not on the Kindle forum, and Diap reminds us about that often enough (cough, cough), but you're right, it's utterly unsupported. You can't really use images as links in MOBI, either, for the same reason--click/tap/pinch activates the image zoom/pan&Scan, not a link. (n.b.: you can still make the image a link, if you think and hope that your audience will click-hold long enough to activate a link, but, then, we're back at square one--half of the Kindleverse doesn't have a viable web-browser, or one at ALL, so...)

Originally Posted by exaltedwombat

This is the same fallacy that spawned the 'Ribbon' interface in Microsoft (and other copy-cat) products a few years ago. Mostly, the best sign to a function is the name of that function. And anyone who uses a device soon learns what a link looks like. Not a picture, not a subtle roll-over behaviour, but a piece of blue, underlined text.

Troo dat, Wombat, although I have to confess that I don't object (now) to the Ribbon. Thought it was a pain in the ass at first, but there's some truth, if you're a Word (or other Windows office app) user, there's some convenience to having your most-used at your fingertips. Nonetheless, you're right about the conceptualization behind it.

The OP, though, is talking about giving little kids using images to nav, instead of a typed nav. I can see that usage.

Hitch

[exaltedwombat]

Originally Posted by Hitch

The OP, though, is talking about giving little kids using images to nav, instead of a typed nav. I can see that usage.

But in a BOOK? You know, one of those things that uses WORDS for communication? It's like saying 'This is too hard a job for a WORD to do' :-)

[Hitch]

Originally Posted by exaltedwombat

But in a BOOK? You know, one of those things that uses WORDS for communication? It's like saying 'This is too hard a job for a WORD to do' :-)

Wooooooombat...

C'mon, man...book for liddle kids. :-) I take your point, I do. But, hell, we already made books like this, for small kids. we're making one now, where the kid "pushes" an image, and the word sounds out. Right?

I'm just saying...as geeks and bookmakers, sometimes, we can ALL--and I include myself in that--be a bit black/white. (Yup, I'm talking to you, Wolfie!!!). Sometimes, what the poster wants to do is suitable for that particular book. For that particular reason. While most of us agree that using images for links is probably counter-indicated in many, if not most, instances, using them to allow a liddle kid to navigate might not actually be worth a burning at the stake. :-)

Spoiler:

(I tried to find a burning-at-the-stake meme/gif. apparently, I'm gif-tarded, 'cuz, without using banned/prohibited shortlinks, I'm damned if I know how to share them here.)

Hitch

[JSWolf]

I know this isn't a nook, but I did a test on my H2O and found that yes, an image link works with RMDSK.

Could it be for this to work, you need a recent enough version of RMDSK?

[Tex2002ans]

Originally Posted by Hitch

Are you sure you don't need JS, or at least JSON, etc., for parsing (I know that's not the right term..) the various areas on the map? ??? Are you sure? I know you're a programmer, sweetie. But I could swear that I read something, somewhere in time (far enough back that my ancient brain can't pull it out...) about that. No?

Imagemaps are just HTML. No JS or anything about it.

Mozilla's page explains <area>:

https://developer.mozilla.org/en-US/...L/Element/area

It is pretty much just like an <a>, but you define a shape of clickable areas, and then you say "if this location is pressed, do this" (visit the link, jump to this section, etc.).

Although maybe you are thinking about more of the Server-Side methods:

https://en.wikipedia.org/wiki/Image_map#Server-side

... I suspect you could also use Javascript to do X, Y, or Z with imagemaps. I wouldn't know, I barely have even messed with the things. And I suspect there are tools out there to try to generate the clickable areas more easily (like a map of the US states, etc. etc.). :P

Side Note: I also stumbled across the <map> page in the EPUB3 Accessibility Guidelines:

Server-side maps are inherently less accessible, both because they require that the reader be able to see the image to discern the regions and also because they require that the reader be able to click on the image in an exact spot.

Client-side maps make use of an associated map element to define the clickable regions. Each region is specified in an area element, and each area should include an alt attribute that indicates its purpose so that non-visual readers can easily discover the functionality. Assistive technologies allow readers to iterate over these areas, making them a much friendlier option than server-side maps, and without requiring intrusive fallbacks.

In fact, server-side maps provide no additional functionality, so their use is never recommended. If one must be used, a set of links corresponding to each clickable region should be provided so that readers who cannot interact with the map have equal access to the functionality.

Note that maps of either kind should never be used when a better alternative is available (e.g., to make an image of text linkable).

Even IF they were supported on devices (which they aren't), it still doesn't seem like it would work well at all on a non-PC devices. It seems like quite a bit of the functionality relies on hovering a mouse over certain areas.

[taneal1]

Originally Posted by exaltedwombat

But in a BOOK? You know, one of those things that uses WORDS for communication? It's like saying 'This is too hard a job for a WORD to do' :-)

Ahem...

As the OP, I repeat: I want to use an IMG of a "stylized text" because I can't find a font that would do the job, AND I don't want to pay the cost of a NOT free font. One more time: I am NOT substituting an IMG for a WORD.

Appearance is important - especially in a kids book when you need to hold their attention to TEACH them to read. Reading requires more thinking than staring at the TV and being force fed.

My goal IS to teach them to read "WORDS" for communication.