Improvements to the "Covers and Artwork Relations" section

[GoogleCodeExporter]

As per the current (r242) draft spec : 
>Catalog Entries MAY include atom:links to images that provide a visual 
>representation of the Publication. For many Publications, these images 
>will be the Publication's cover or other distinguishing artwork. These 
>atom:links MUST use one of the following relations for these images:
>"http://opds-spec.org/cover": a high-quality version of the image
>"http://opds-spec.org/thumbnail": a version of the image suitable for
>presentation at a small size

Generic artwork are discussed yet there are no rel values defined for them. 
I propose to use the same scheme than with acquisitions : 
*http://opds-spec.org/artwork              Generic
*http://opds-spec.org/artwork/cover        Cover
*http://opds-spec.org/artwork/thumbnail    Thumbnail 

The draft also states : 
>The atom:links with these relations MUST include a type attribute of 
>"image/gif", "image/jpeg", or "image/png" and the image Resources MUST be 
>in GIF, JPEG, or PNG format. 

Is there any reason not to include a vector graphics format

At the very least I would propose to add SVG. Maybe adding EPS would be a 
good move since AFAIK it is still very much in use in scientific 
publications.

Original issue reported on code.google.com by zeta....@gmail.com on 20 May 2010 at 7:53

[GoogleCodeExporter]

I agree with Benoît that this might be a good idea and consistent with our 
position on 
acquisition links (having a generic element).

It would also make things slightly complicated for current catalogs and clients 
since 
most of them already use the existing rel values (http://opds-spec.org/cover 
and 
http://opds-spec.org/cover). If we consider to move forward in that direction, 
I'll 
keep the Feedbooks catalog compatible with the old spec for a month after the 
release 
of 1.0 and then switch to the new rel values.

Original comment by hadrien....@gmail.com on 21 May 2010 at 3:56

[GoogleCodeExporter]

Original comment by abdela...@gmail.com on 25 May 2010 at 5:43

• Added labels: Milestone-Release1.1

[GoogleCodeExporter]

Original comment by abdela...@gmail.com on 25 May 2010 at 5:44

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

I am much in favor of allowing vector-graphic types for images.

If an opds-feed reader cannot accept, say, SVG should it be labeled 
non-compliant?

Or is it better to provide a fallback mechanism for vector graphics formats -- 
"if you cannot render this [SVG|EPS|FXG|XAML] file use this bitmapped file 
instead." 

For that matter, if a reader is using a reader based on WebKit or Gecko (or 
based in a browser like Bookworm) there's no reason the vector-graphics might 
not be animated. Nor any reason why video couldn't be supplied or linked to. (I 
don't propose to adopt or support this. I'm just sayin' ... :-) As long as a 
fallback is provided, I think this would extend the usefulness of OPDS beyond 
books and longer into the future.

Original comment by rsperb...@gmail.com on 15 Jul 2010 at 9:53

[GoogleCodeExporter]

"As long as a fallback is provided, ...."

If we're going down that path we need the possibility of a series of fallbacks. 
Ideally using standard content negotiation techniques, so we can have a 
fall-back from visual to audio for the blind, etc.

Original comment by syea...@gmail.com on 15 Jul 2010 at 10:33

[GoogleCodeExporter]

I edited the spec slightly to require at least one bitmap format, but accept 
vector based ones in additional links.

http://code.google.com/p/openpub/wiki/CatalogSpecDraft#Artwork_Relations

Original comment by hadrien....@gmail.com on 16 Jul 2010 at 10:32

[GoogleCodeExporter]

This is now completed in the Spec.

Original comment by abdela...@gmail.com on 4 Aug 2010 at 4:37

• Changed state: Done