Epub Full Page Cover Image

Jeff:

You can open Pages and choose a poster template and use it as first page cover and it works like a charm both when exporting to PDF or ePub. Try it.

Sorry for the apparent confusion: all I was interested in was including a cover image that would show up in iTunes/iBooks as a "full cover," without a white border around it.

Still a bit confused. When you say "all I was interested in was including a cover image that would show up in iTunes/iBooks as a "full cover," without a white border around it," I assume you are talking about "Cover Art." I.e., the thumbnail image displayed in lower, left-hand corner of iTunes and as the book icon in iBooks in the bookshelf/line oriented book selection menus. On the other hand, I refer to the a cover image embedded in the readable text as a cover page which you appear to call your "frontispiece." I bring this up because each functional use, software application, and/or hardware device may impose specific limitations or restrictions on rendering.

For instance, cover art displayed in iTunes is scaled to fit the available height/width of the "preview" display window and, if the image does not have a 1:1 aspect ratio, is centered within the shorter dimension. Further, the effect of changing the width of the display window varies according to the relationship between the size of the display window and the original image. That is, if the display window is smaller than the original image, the display retains its 1:1 aspect ratio with the centered image. When the height of the display window equals the cover art image height, then the height of the display window remains constant as the width continues to increase. If the width of the display window becomes greater than the width of the cover art image, then the image remains centered across the width as the display window continues to widen.

On the other hand, a cover art image display in iBooks on the bookshelf mode is scaled fit to the maximum book display area and the height is scaled according to the aspect ration of the original cover art image making it possible to have books of varying heights on your book shelf. In a similar manner, book cover art icons displayed in the line mode, are scaled to fit the icon display area and the width is scaled to match the original cover art image aspect ratio making it possible for books in this more to display with varying widths.

Cover art can be generated in two ways for iTunes/iBooks--manually or automatically. Using the "Cover" option in Pages will force the system to take a "snapshot" of the first page in your Pages project. This "cover.png" file uses the entire document page size as it's canvas and can contain an image and/or text/shapes with graphics in either floating or in-line modes. This image is then scaled to a height on the order of 500-520 pixels at the same aspect ratio as the document page. Thus, how this cover art image will display in iTunes/iBooks depends on the aspect ratio of the Pages document dimensions and how you are viewing the final ePUB file. Remember that when you use this mode, this first page of your Pages file is renamed as cover.xml and the cover art "snapshot" is named "cover.png" with the "cover.xhtml" now only used for the display of the "book cover" of the ePUB file as it opens in iBooks and is no longer displayable in iBooks itself. (I.e., you can no longer "backpage" to view this page in iBooks as you can if you use other ePUB file generation work flow options.) For this reason, I tend to prefer to create my cover are manually and simply dropping it into the cover area in iTunes, leaving an imbedded html/xhtml/xml file in the main ePUB package for display in iBooks without duplicating the first page and ensuring all cover art (music, movies, TV shows, books, etc.) have a uniform file height.

As to the display of an embedded cover page, remember that while most software readers allow you to manually scale and change the display aspect ratio, most hardware devices do not. Further, most hardware devices pre-allocate specific areas of the display screen for the display of file information, frames (such as iBooks "book page" simulation) and/or menu controls. Thus, it is usually not possible to display a true "full page cover" within a file and, even if you could, it would probably not be compatible with changes in the display orientation on the same device or across different makes and/or models of devices.

Since any solution to do what you are trying to do is relative only in the context of how you plan to use the content, I find it somewhat difficult to provide definitive answers to your question.

I have the same question and issue. Using the Pages book template that came with the epub guide, My book cover has a white margin around it and it shows up in the ibookstore shelf with the book cover on a white border.
If I change the margins on the first page to create a larger book cover art, I end up changing the margins of the rest of the novel.
What I want is to make the first cover page have a different margin than the rest of the book. That way I can the cover page has a zero margin and the book cover takes up the entire page, and the rest of the book has the standard margins.
I think that's the issue the original writer wanted to know.
We know how to create a cover page, and we know that that cover page will be thumbnail on the ibookstore shelf, we just want to have a cover page that has no margins (no white border) while the rest of the book has the standard margins. Any ideas?
Thanks

If I have understood the problem you want the cover page without margins and the other pages with margins?
It can be done! I think you need to have the image inline, right?

1. Open the e-Pub template from Apple. The supplied pages are each their own section. There are document margins of 1 inch/ 2,54 cm. Layout margin are zero. We will change this.
2. Open the Inspector palette > Document tab > change the margins to zero
3. Click on the second section/page > Inspector palette > Layout tab > Layout > Layout margins > change to 1 inch. Do that for the other consecutive pages/sections too.
4. Save as template

Try it out and see how it works.

It can be done! I think you need to have the image inline, right?

"Inline" or "floating" is immaterial here. What does matter is that a "full page cover" image must fill the entire Pages document page. If it doesn't, any uncovered areas of this "canvas" will be rendered as a "white" area, be it a border or irregular shaped area representing any unused portion of of the document page background. What the Pages routine does is to take a PNG "snapshot" of the entire "first page" of project document and scale its height to something on the order of 500 to 520 pixels with a width having the same aspect ratio as the original document page. This image file is then named "cover-image.png" and is placed in the "OPS > images" folder within the finished ePUB file package and is what is employed for the icon, thumbnail, and/or the graphic interface of the particular reader app/device being used (i.e., to include the opening cover simulation used in iBooks). And, since the original "first page" is then deleted by the pages export operation, it is no longer available for normal viewing as part of the ePUB book within the reader.

The book jumps to the next page when opened, and you can't go back and view the cover. That may be good enough for many things. Personally, I've taken another look at Sigil for creation right now;

Sigil is obviously a good choice for those wanting a free alternative for writing, converting, and/or editing ePUB files. However, there are other alternatives.

Legend Maker, for instance, works in the opposite direction as compared with Pages. It allows you to include a default "cover.png" image as part of your project and then automatically generates a "cover.html" file which is placed at the front of your ePUB book. Since the "cover" page uses this image "by reference" on the HTML page and the various apps/devices use a scaled version of the same image file for icon, thumbnail, graphic interface purposes, there is no need to duplicate the page and/or image as when using Pages for a direct export. Thus, Legend Maker's ePUB file is suitable for both "cover page" and "cover art" use. On the other hand, some users may not be comfortable with the "tag 'n flag" strategy used by this application to avoid the creating of an RTFD package when images are directly embedded in a Pages project rather than the RTF file required for use by Legend Maker.

Pages functionality is still a little too quirky to meet my needs. We'll hope it gets baked in better in later releases!

I have to agree with this statement. While I really think Apple is moving in the right direction here, their initial offering is definitely a bit unstable with justification handling inconsistent and section breaks on occasion being ignored and causing individual XHTML files to merge into a single file without warning or apparent reason. Still, Pages' ability to include shapes, frames, and other built-in features give it an interesting potential for future upgrading. On the other hand, other applications like Legend Maker seem much more stable at this time and, since the price is now less that half of what I originally paid (i.e., $99), at $49 it may be a good option for users not willing to "go all the way" with Adobe InDesign and those unwilling to wait for Apple to "fix" the current problems. In addition, it is the only application I've used which will simultaneously generate an ePUB and Kindle compressed HTML file, I find all three work flows to have their own individual advantages and disadvantages and use them all on a fairly regular basis while I attempt to figure out why my older version of InDesign does not like my projects.

Jon Walker wrote:

It can be done! I think you need to have the image inline, right?

"Inline" or "floating" is immaterial here. What does matter is that a "full page cover" image must fill the entire Pages document page.

It isn't immaterial as the inline image can't be outside the text layer borders (document margins/layout margins). If floating images can be used then it is fine as it is.

It isn't immaterial as the inline image can't be outside the text layer borders (document margins/layout margins). If floating images can be used then it is fine as it is.

Since both floating and inline images can be made to fit the entire document page background at either its correct original or a modified aspect ratio or as a "cropped to fit" image and since Pages will take a "snapshot" of either and turn it into the required "cover-image.png" file before deleting/failing to export the "first page" content from/to the ePUB XHTML file set, it is really immaterial which is used assuming you know how to adjust your work flow to ensure full page coverage of the "canvas" and I, therefore, stand by my original statement. As Jeff and others have mentioned, a floating image will return an alert message but ignoring it does not affect the results because the final output is a PNG image file and not an XHTML file within the final ePUB package. (I.e., floating objects are only ignored when generating ePUB XHTML segmentation files during export and if ignored in these instances will not show up on the pages of your book.) You can verify this for yourself by simply testing any or all of the work flows suggested above by the various responders.

As you are not addressing what I am addressing I rest my case.

It isn't immaterial as the inline image can't be outside the text layer borders (document margins/layout margins). If floating images can be used then it is fine as it is... As you are not addressing what I am addressing I rest my case.

Since my comments did cover the relationship between the cover image and the document page size (with or without margins), their respective aspects, the fact that either a floating image or an inline one could be used but that different work flows had to be applied accordingly (i.e., to deal with margin/marginless issues), it seems to me I've addressed everything you addressed. The fact that you continue to belabor the point and made use of the conditional mood when referring to the use of a floating image coupled with your obvious knowledge regarding Pages as demonstrated by your point accumulation in this forum, tends to imply an unwillingness on your part to either concede to the possibility or confirm that an alternative solution might exist. I, for one, am willing to let readers decide for themselves. As they say, "there is more than one way to skin a cat," and all that really matters here is that each user employ the work flow best suited to his or her individual needs for any given project.