1. Pavel’s avatar

    Hi,

    What’s the fate of CFI?

    Reply

    1. matt.garrish’s avatar

      Mostly unchanged. The required support as a linking mechanism in content documents is being dropped, but we’ve found no real evidence that authors were using it for linking between documents. The typical practice is to link to IDs, which is what the web supports.

      It’ll remain for internal reading system use and where interoperable referencing is required (e.g., the open annotation spec).

      Reply

    2. Pavel’s avatar

      Hi,

      RFC 4329 made text/javascript obsolete in favor of application/javascript. I’d suggest ePub spec moves that forward too.

      Reply

      1. matt.garrish’s avatar

        Thanks, I’ve opened an issue in the tracker to consider.

        Reply

      2. Pavel’s avatar

        Hi,

        It would be quite helpful if ePub spec finally defines Core Media Type for video resources and outlines what codecs should work. Thank you!

        Reply

        1. Pavel’s avatar

          Hi Matt,

          I’d suggest to include Web Video Text Tracks (.vtt files) to EPUB Core Media Types sooner than later.

          Cheers,
          Pavel.

          Reply

          1. matt.garrish’s avatar

            We don’t need to do anything to allow. As stated in the Content Documents spec:

            The [HTML5] track element is exempt from the Core Media Type usage rule [EPUB31]: Foreign Resources may be referenced from track without the provision of a Core Media Type fallback.

            If you’re getting an error from epubcheck, it needs to be reported there.

            Reply

            1. Pavel’s avatar

              Hi Matt,

              I’ve read the latest EPUB 3.1 draft and I don’t see any references to the track files exemption. Thanks! Pavel.

              Reply

              1. matt.garrish’s avatar

                It’s in section 2.5.5 of the content docs spec. The wording has been changed slightly from what I quoted above, as video and meta/pronunciation have been added to the list:

                http://www.idpf.org/epub/31/spec/epub-contentdocs.html#sec-xhtml-fallbacks

              2. twobyte’s avatar

                Hi Matt – Can you please clarify what ePub 3.1 spec has to say about the following: if (or ) element in some content document has a subelement and both media and track are located somewhere remotely, should track data item be included in the manifest at all? Thank you!

                Reply

                1. twobyte’s avatar

                  Just editing what has been eaten by your blog posting script:

                  Hi Matt, Can you please clarify what ePub 3.1 spec has to say about the following: if < video > or < audio > element in some content document has a subelement < track > and both media and track are located somewhere remotely, should track data item be included in the manifest at all? Thank you very much!

                2. matt.garrish’s avatar

                  Technically the track element can’t be hosted remotely, only the audio or video. The only exemption for track is that it doesn’t have to reference a core media type.

                  But even if it were allowed remotely, it would still have to be listed. Audio and video files (and as of 3.1 fonts and remote resources fetched by scripts) are included in the manifest with the full URL to them in the item’s href attribute.

                3. matt.garrish’s avatar

                  It’s looking like MP4/H.264 is widely supported enough now that it could be considered a core media type, but it’s a thorny issue to have a patent-encumbered CMT. I’ve noted the lack of a CMT again in an issue about clarifying what we mean by fallbacks, but I can’t say if there will be a resolution in this revision or not.

                  Reply

                4. twobyte’s avatar

                  Congrats with ePub 3.1 release! Good job!

                  Reply

Reply

Your email address will not be published. Required fields are marked *