For discussion: epubcheck should be doing fallback checking on entire <manifest> not just the <spine>-referenced <manifest> item
| Project: | EPUB Maintenance |
| Component: | Open Packaging Format (OPF) |
| Category: | support request |
| Priority: | normal |
| Assigned: | GConboy |
| Status: | completed @ 2.0.1 |
Jump to:
Somewhat related to another issue stating that we should exempt font file specified in @font-face "src" url()s from requirements to have fallbacks, as they are non-core types, but do need to be in the manifest...
Note (from OPS):
External style sheets linked via the XHTML link element or by the processing instruction xml-stylesheet may use CSS or any other style language, such as XSL (see http://www.w3.org/TR/xsl). Reading Systems are not required to support any style sheet language beyond the CSS specified herein.
Reading Systems that implement only the OPS CSS 2.0 required subset may ignore any style sheets using other style languages. Reading Systems that support extended style sheet functionality may choose among any of the other external style sheets. It is strongly recommended that unique MIME media types be defined for any style sheet languages supported beyond the OPS CSS 2.0 required subset, and that style sheets in those languages be detected by examining the MIME media type.
I was on the precipice of fixing epubcheck to correctly validate all <manifest> items for either being "blessed" types or for having a fallback thereto. However, with that change, all embedded font files would be tagged as errors (as they clearly don't want fallbacks) [we knew that and there is already a related issue]. But, also all "whacky" stylesheet files (e.g. XSL beasts) would be tagged as needing fallbacks. It seems the spec is pretty clean such stylesheets must be in the manifest and thus they must have fallbacks. Was that our intent?
To be "accepted." Section "2.3.1: Fallback Items" which comes immediately before explains that there are 4 types of fallbacks and my take that 2.3.1.1 is only applicable to the fourth case on that list when fallback attribute is needed. Will be clarified.
Language should be added to conformance section.
- Login to post comments
Comments
#1
I'm pretty sure it is and has been our intent. Pretty much everything in the publication has fallbacks to known types (img fallbacks using the package, object elements use embedded objects, fonts use the CSS mechanisms, xml files/islands have a number of fallbacks, etc). I can't think of any non-blessed type for which no fallback is required. I don't see why non-CSS style sheets would be any different, especially since fallbacks have been an integral part of the specs for a good decade.
#2
My understanding is different: fallback entries are required only for entries referenced in the spine. By virture of OPS definition all other resources have to have a fallback too, but these fallbacks are defined inline and are not always possible to define as separate resources. For instance if we have some sort of dancing text SWF referenced by object tag, the fallback may be simply inline text inside the object. There is no reasonable fallback for SWF resource even though its fallback is well-defined in OPS content. In addition, manifest may contain supporting resources for non-blessed content. For instance, SWF may have some sound associated with it and it may be represented by a separate mp3 file in the manifest and referenced inside SWF. There is no need to define per-resource fallback in this case - it was already taken care by a fallback to the SWF itself.
Fonts represent a special case. They are optional by design, since no particular format is mandated. Effectively, this means that fallback for a publication-specific font is a system font. Also, CSS syntax already supports font fallbacks in @font-face syntax if multiple alternative font formats are desired.
#3
That's why I raised this issue -- our spec (OPF) specifically states otherwise. From the Manifest section:
2.3.1.1: Items That Are Not OPS Core Media Types
An item that specifies a resource that is not an OPS Core Media Type (e.g. a non-core image type, a text file, a PDF file) must have a fallback specified. In this case, its fallback must be identified with a fallback attribute pointing to another item. See Section 2.3.1.2 for fallback requirements for Out-of-Line XML Islands.
An item identifies a fallback item using its fallback attribute, which must specify the ID of the item element that identifies the fallback. Items referenced from fallback attributes may each specify a fallback attribute in turn, forming a multi-level fallback chain. For example:
All non-core media type items must have a fallback. This seems perhaps not what we want for items that have their own fallbacks (e.g. in an <object>), funky style languages that may well be ignored, items that are referenced only from out-of-line XML islands that have their own fallbacks, etc.
#4
I think section "2.3.1: Fallback Items" which comes immediately before explains that there are 4 types of fallbacks and my take that 2.3.1.1 is only applicable to the fourth case on that list when fallback attribute is needed. You right that it needs to be clarified.
Another thing: language should be added to conformance section.
#5
#6
#7
Moved to "Accepted" after the requisite week stay in "proposed resolution."
#8
Moved to "Accepted" after the requisite week stay in "proposed resolution."
#9