Covers in metadata
| Project: | EPUB Maintenance |
| Component: | Open Packaging Format (OPF) |
| Category: | feature request |
| Priority: | normal |
| Assigned: | HGardeur |
| Status: | future consideration |
Jump to:
The lack of support for covers in metadata (defined in OPF) is problematic for reading systems and aggregators. Currently, the following solutions are implemented:
- In Digital Editions, the cover is the first page of the first flow
- Mobipocket/Amazon use a meta@name="cover" when converting from EPUB
In the specs, aside from setting the type to cover on a guide element (works with flows, not with images), we don't have any particular way to indicate that an image is a cover.
Description
Issue Id:
8
Resolution:
Moving to "future consideration". This may not be in the scope of the OPF standard. But, creation of an "informational document" covering industry consensus on this topic should be considered.
- Login to post comments
Comments
#1
It might be possible to use the NCX to identify a cover, whether it is a single image or a range of markup. Perhaps an NCX expert could chime in.
#2
Note that for good UI experience cover really needs to have an aspect ratio; thus use of XHTML for cover is sub-optimal. SVG makes an excellent cover, bitmap image is OK in many cases as well.
#3
The question wasn't what it is best to point at, but how to point at it. Do you foresee forbidding XHTML as a cover? It might make life easier for backend services that might want to just pull an image from the EPUB and display it in a catalog without handling markup fragments. In fact, fragments could be quite difficult, requiring a load of the document and associated CSS to properly style it.
#4
I really don't think that pointing to the cover in the NCX rather than the OPF would be a good idea.
I agree that an XHTML flow is sub-optimal but we should still allow it somehow (with type="cover" in the guide).
For SVG and bitmap images, a new meta should do the trick.
#5
I agree that OPF is the right place for it and I agree that XHTML should be allowed. I just wanted to point out that XHTML-only solution is not interesting. It should work for XHTML, SVG and bitmaps.
#6
Action items ?
#7
#8
Not sure what resolution is proposed here? Last comment is empty.
#9
#10
Here's my proposal Peter: rather than using a meta@name="cover" like Mobipocket, I recommend that we create a new opf:cover element that would be strictly limited to images already included in the OPS Core Media Types (http://idpf.org/2007/ops/OPS_2.0_final_spec.html#Section1.3.7 or image/gif, image/png, image/jpeg and image/svg+xml).
If the OPF doesn't include an opf:cover element, the reading system should look for a guide element with reference@type="cover".
#11
I'm loath of dream up new elements, especially ones with stringent content rules.
I tend to think the cover image should be part of normal flow -- not an "invented" first page. But, that said, it seems as though the cover image should be externally identify-able such that it can be used for metadata and merchandizing purposes. Thus, it seems a "standard" OPF/Guide/NCX reference to the ID of the <img> or <object> element that contains the cover image would be a good idea.
#12
There's nothing suited in DC or DC Terms for a cover as far as I can see.
#13
True. And, I think we'd want an in-content ID-ref for this purpose. Somehow.
#14
opf:cover element or attribute would work for me - but it smells as a new feature.
#15
It could be considered a new feature Peter, but it is one of the most common struggle with EPUB.
Content providers, distributors and reading systems all need an easy way to find a cover in an EPUB file, and without a single line in the specs, we'll see more and more incompatible implementations.
#16
I hear you, but I think that the discipline in doing specs is very important. I'd really rather not slide into inventing new features.
#17
As a reading system implementer I'll go with whatever is decided, with the pragmatic awareness that I'll need to fall back to the Mobipocket recommendation for legacy EPUBs. But I agree that this is an important issue and I'd like to see at least an official recommendation as soon as possible.
#18
@Peter: I'd like to avoid the situation where we simply move this into future directions without proposing any example of how this should be implemented. If it takes several extra months to even start working on these future directions items, in the meantime more and more books will be produced without proper markup for the cover or with various proprietary solutions to this problem.
#19
Hadrien,
I am fine either way and I am not trying to block it. I just don't think it will stand. I wanted to do basic dictionary functionality which would only involve one extra metadata tag saying that html:dt element is indeed used according to the semantic prescribed in HTML spec, but that was shot down on the same grounds.
#20