[BUG] coverimage for Apple iBooks compliance duplicated in manifest

[Hasimir]

In order to have a cover image appear in Apple iBooks, an EPUB needs an entry in the manifest like this:

<item id="coverimage"
    href="images/icover.jpg"
    media-type="image/jpeg"
    properties="cover-image"/>

The current plugin does consistently include this at the end of the list of images in the manifest when the epub-cover-graphic element is correctly specified:

<epub-cover-graphic format="jpg" id="coverimage" href="images/icover.jpg"/>

Even with that being the sole reference to the smaller copy of the cover image, the transformation produces two entries in the manifest for the for that image.

Here are all the image references from the DITA/D4P source files for the same project.

From the pubmap file:

<covers>
  <epub-cover-graphic format="jpg" id="coverimage" href="images/icover.jpg"/>
  <front-cover id="front-cover" href="front/cover.dita"/>
</covers>

From a resources.ditamap file which is both included as reference-only and in which each resource is also included with the "resource-only" processing role:

<topicref id="cover-img" href="images/cover.jpg" format="jpg" scope="local" type="image" processing-role="resource-only"/>
<topicref id="baphomet-image" href="images/image1.jpg" format="jpg" scope="local" type="image" processing-role="resource-only"/>
<topicref id="acsig" href="images/image2.jpg" format="jpg" scope="local" type="image" processing-role="resource-only"/>
<topicref id="btc-pic" href="images/mloz-btc.jpg" format="jpg" scope="local" type="image" processing-role="resource-only"/>

Yet the generated manifest in an EPUB 3 file results in this:

<item id="image-list-item-1"
    href="images/mloz-btc.jpg"
    media-type="image/jpeg"/>
<item id="image-list-item-2"
    href="images/image1.jpg"
    media-type="image/jpeg"/>
<item id="image-list-item-3"
    href="images/icover.jpg"
    media-type="image/jpeg"/>
<item id="image-list-item-4"
    href="images/image2.jpg"
    media-type="image/jpeg"/>
<item id="image-list-item-5"
    href="images/mloz-btc.jpg"
    media-type="image/jpeg"/>
<item id="image-list-item-6"
    href="images/cover.jpg"
    media-type="image/jpeg"/>
<item id="coverimage"
    href="images/icover.jpg"
    media-type="image/jpeg"
    properties="cover-image"/>

In this case the duplicate entry is "image-list-item-3" but the actual point at which it will appear will depend on what other files are included in any given project.

The actual full size cover is listed in the manifest as "image-list-item-6" as it is loaded only in cover.dita (called with the front-cover element) and referenced in the resources map. The transformation process does produce a warning regarding that file, but it does not prevent the epub being created. The warning is almost certainly unrelated to this bug, but I am including it for the sake of completeness:

Engine name: DITA-OT
Severity: warning
Description: [DOTX037W]: No title found for this document; using "***" in XHTML title bar.  The location of this problem was at (File = /path/to/EPUB/content/front/cover.dita, Element = d4pCover:1;3:44)
Start location: 3:44
URL: http://www.oxygenxml.com/DITA-messages.html#msgs__DOTX037W

Note that the d4pCover element cannot have a title set, so this error is actually the least bad configuration.

[Hasimir]

My current method of fixing this is to just edit the content.opf file manually while updating other parts of the metadata.

[drmacro]

Need to provide either a failing test case or details of how to reproduce the failure.

[Hasimir]

I'm sure I can whip up something small and nearly pointless to test with a bit later. The "placeholder" images might be a bit silly, though.

[Hasimir]

Okay, I have a test project which reproduces this error here. It also demonstrates the incorrect date error since it includes a completed transformation to EPUB 3 and I added a detached GPG signature in the output folder with the epub so it can demonstrably proven to have been generated before the date and time in UTC it says it was created (and so is this comment, actually).

Also, chapter 2 in the test book includes all the configuration for the transformation scenario used to create the file, including screen captures from oXygen. That said, in its current form it will not pass an epubcheck, but can still be opened in most epub reader apps, including Readium.

[drmacro]

The bug results from the new image-list processing, which produces an OPF entry for every image listed there, as well as an entry for the referenced cover image, however it was referenced (epub-cover-graphic or runtime cover graphic image parameter).

I'll have to figure out how to eliminate the duplicate and ensure that there is a "cover-graphic" property on the one OPF item.

[Hasimir]

From my tests it looks like the only essential part is the addition of properties "cover-image"> to the element, not the id="coverimage" so if there were a check for a cover image when building the image list and appending the properties when found would probably do it.

Oh, I've also confirmed that #70 is indeed fixed.