View Full Version : Full-page illustration that doesn’t interrupt the text


Erkhyan
12-23-2012, 04:02 PM
How can I insert a full-page illustration in an epub file without interrupting the text? For example, I have something like this:
<p>Here comes the first paragraph of text...</p>
<div>
<svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 600 800" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
<image height="800" width="600" xlink:href="Illustration.jpeg"></image>
</svg>
</div>
<p>... then the second paragraph comes here, and the story continues.</p>
My problem with such a code is that as soon as it meets the image, the reader interrupts the text, inserts a page jump, displays the illustration, then continues the text on the page next to it.

What I’d like to do, in human language, would be to insert a tag that tells the reader "insert this image as soon as you can, but don’t break the text’s flow for it".

dgatwood
12-23-2012, 04:25 PM
Historically, HTML/CSS didn't really have a mechanism for that. Content either appears in the flow at a particular point or is absolutely placed relative to the viewport or page. Neither one would result in what you're asking for.

I think the best you can realistically do is to put it on a separate page that's outside the flow and provide a link to it (<a name="backref001" href="...">show</a>) and make the image be a link back (<a href="origfile.html#backref001">).

In theoretical future readers that support all of CSS3, you might be able to to this:

img { move-to: page-top; }

but I don't expect any reader to support that currently. At last check, even browsers don't support it yet. Maybe in five years.

mrmikel
12-23-2012, 07:39 PM
Because of this problem, I always make sure that paragraphs always are complete before a picture. At least the reader doesn't have to hold a thought as they skip over a picture.

Image maps don't work in epubs, so any link would have to be in the caption. If you have larger tablets as your target, then this sort of linking is worthwhile. For smaller readers, the detail and grayscale just aren't there to make it worthwhile, in my opinion.

dgatwood
12-23-2012, 07:56 PM
Because of this problem, I always make sure that paragraphs always are complete before a picture. At least the reader doesn't have to hold a thought as they skip over a picture.

Image maps don't work in epubs, so any link would have to be in the caption. If you have larger tablets as your target, then this sort of linking is worthwhile. For smaller readers, the detail and grayscale just aren't there to make it worthwhile, in my opinion.

I was suggesting making the entire image a link back, e.g.

<a href="..."><img src="..." /></a>

But yeah, a link back from the caption would work, too.

GrannyGrump
12-23-2012, 10:17 PM
Be aware, images as links don't work in all readers. I don't have multiple readers to test on, but they won't work on my Sony prs-T1, or on the Sony Reader software for pc. They DO work on ADE for the desktop (and apparently in webkit software, as Sigil and Calibre reader).
I found this out during a recent large conversion project, and it broke my heart. :(

Jellby
12-24-2012, 04:08 AM
Image maps don't work in epubs

They should, because it's in the spec. But as grannyGrumpy says not even simple image links works in many readers, so do not count on it.

Erkhyan
12-24-2012, 05:40 AM
Because of this problem, I always make sure that paragraphs always are complete before a picture. At least the reader doesn't have to hold a thought as they skip over a picture.
In the book I have, a full-page illustration is inserted mid-chapter. The paragraphs are complete, but it’s still annoying when for example, the last paragraph before the illustration is way up there on the page, leaving a huge blank space on the page…

Jellby
12-24-2012, 06:31 AM
Yes, it's irritating, but there's nothing you can do, other than moving the illustration elsewhere, maybe including a thumbnail and link in the text.

In its current (2.0.1) implementation, ePub doesn't have anything about floats (vertical floats, that is... there's the possibility of having something float to the left or right of a paragraph). Elements are displayed as they appear in the source, so an image will not be moved up or down its position.

It might change with ePub 3 and CSS 3, but I wouldn't hold my breath.

mrmikel
12-24-2012, 07:08 AM
In a small device with limited grayscale, floats are not very useful for illustrations anyway.

I strive to get the maximum use of illustrations for the reader, but that means that I end up landscaping some, making the user turn their book sideways. At least they can see as much as can be shown in a small device. It will have to do until the portable hologram projectors come out next Christmas!

dgatwood
12-24-2012, 01:00 PM
Be aware, images as links don't work in all readers. I don't have multiple readers to test on, but they won't work on my Sony prs-T1, or on the Sony Reader software for pc.

Wow. That was basic functionality on the web almost twenty years ago. Any reader that doesn't handle that is officially less functional than the Netscape Mosaic 0.9 betas.

Please write to Sony and complain about their brokenness. There's simply no excuse for that. If enough people complain, maybe Sony's readers will eventually be HTML 1.0 compliant.... :eek:

Also, why is the Sony reader application on OS X almost as slow as the one that I wrote in pure JavaScript (including the unzip library)? Just saying.

Jellby
12-24-2012, 01:27 PM
Please write to Sony and complain about their brokenness.

Not only Sony readers, but all readers based on Adobe (including BlueFire on tablets and phones), as far as I know, which means the vast majority of ePub readers.

dgatwood
12-24-2012, 04:08 PM
Bummer. They based it on Adobe's code. I'll file a bug with Adobe, not that I'm expecting them to ever fix it. :(

DaleDe
12-24-2012, 06:48 PM
Bummer. They based it on Adobe's code. I'll file a bug with Adobe, not that I'm expecting them to ever fix it. :(

It is not a bug. It is an unspec'd feature. The ePub specification does not provide a way to float up or down.

dgatwood
12-24-2012, 11:37 PM
It is not a bug. It is an unspec'd feature. The ePub specification does not provide a way to float up or down.

You apparently missed part of the thread. The bug I was referring to is that image links—<a href="..."><img src="..."/></a>—don't work in any of the readers derived from Adobe Digital Editions.

That's not an unspec'd feature. Image links have been part of the HTML spec since at least mid-1993 (http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt). :)

But yes, the EPUB specification won't cover floating images up or down until whatever version of the EPUB spec incorporates support for all of CSS3—I'm guessing EPUB 4 or 5....

Jellby
12-25-2012, 03:59 AM
In theoretical future readers that support all of CSS3, you might be able to to this:

img { move-to: page-top; }

That looks nice, but a closer look at the CSS3 working draft (http://www.w3.org/TR/css3-content/#introduction) reveals that it wouldn't work as expected, even if it were supported.

The example says:

img { move-to: page-top; } /* move images to page-top */
@page { padding-top: 10em; } /* leave a gap at the top of the page */
body:after { /* place a box at the top of each page */
position: fixed; top: 0; left: 0; right: 0; height: 10em;
content: pending(page-top); /* insert the images moved to page-top */
}

"page-top" is not some special keyword, it's just an identifier, it could say "foobar" instead, so the img is simply moved to wherever we specify "pending(page-top)", and I don't see how we could say we want it at the next (or current) page top. Reading the rest of the example (@page and body:after), what is actually achieved, if I'm not mistaken, is that all images in the document are collected and placed at the top of every page, and with absolute positioning, which required adding manual padding.

Jellby
12-25-2012, 04:16 AM
This part of CSS3 (http://dev.w3.org/csswg/css3-gcpm/#page-and-column-floats) looks more promising, though.

dgatwood
12-25-2012, 01:27 PM
The example says:

img { move-to: page-top; } /* move images to page-top */
@page { padding-top: 10em; } /* leave a gap at the top of the page */
body:after { /* place a box at the top of each page */
position: fixed; top: 0; left: 0; right: 0; height: 10em;
content: pending(page-top); /* insert the images moved to page-top */
}

"page-top" is not some special keyword, it's just an identifier, it could say "foobar" instead, so the img is simply moved to wherever we specify "pending(page-top)", and I don't see how we could say we want it at the next (or current) page top. Reading the rest of the example (@page and body:after), what is actually achieved, if I'm not mistaken, is that all images in the document are collected and placed at the top of every page, and with absolute positioning, which required adding manual padding.

It's just an example, and is not the only way you can use the properties. A more realistic example would target the images more precisely, e.g. with img.floattotop (or even .floattotop) instead of img.

Likewise, a more realistic example would specify the width of the box, but would not specify the height. The pseudo-element would then either be zero height (if there are no images to float) or nonzero (the height of the floated images for that particular page).

Finally, it would not place every image on every page; it would place only the images since the last time you called pending with the specified identifier. Section 5 has this to say about the move-to property:

The element is not displayed at the current location, but at the next occurrence of 'pending(<identifier>)' (where the identifiers match), with all other elements moved to that point, in document order. If at the end af the document (after the '::after' pseudo-elements of the root element) there are outstanding elements, then they are all inserted in document order at that point.


(Presumably it means "with all other matching elements". Oops.) The main purpose of move-to is to allow you to easily place footnotes at the bottom of each page.

That said, it would always be displayed at the pending call after the image, so if you wanted the image to float upwards instead of floating to the next page, you'd have to do something else.