Reference items in guide must be content documents

[Jon]

In an ePub I recently produced and announced in several forums, one
person wrote back and noticed that in one <reference> in the <guide>,
I pointed to an image rather than a content document, which is a
mistake.

The OPF spec, section 2.6, says that all the 'href' in <reference>
must point to content documents (and optionally to a fragment
identifier within the content document) listed in the Manifest.

Since epubcheck 1.0.4 missed this, I recommend that check be added to
epubcheck, along with any other guide-related requirements epubcheck
misses (if any).

Jon

[Peter Sorotokin]

Jon,

Can you file an issue and attach your sample file? Doing that greatly simplifies development work.

Thanks!

Peter

--

You received this message because you are subscribed to the Google Groups "epubcheck" group.
To post to this group, send email to epub...@googlegroups.com.
To unsubscribe from this group, send email to epubcheck+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/epubcheck?hl=.

[Dave Cramer]

Issue #45 is related... it appears that ePubCheck does not check for
the existence of any files referenced in the guide element. There's a
small test file attached to that issue.

Thanks!

Dave Cramer

--
Dave Cramer
Technical Lead
TexTech, Inc.
70 Landmark Hill Drive
Brattleboro, VT 05301
d.cr...@textechinc.us

[Jon]

Peter, the example is simple.

Here is the original markup in my OPF:

<guide>
<reference type="cover" title="Cover Image" href="images/cover.jpg"/
>...
</guide>

I recall now acquiring this "template" a couple years ago when I built
my first OPS Publication, and I did not see this does not conform to
OPF. Here is what it should be:

<guide>
<reference type="cover" title="Cover Image" href="cover.html"/>
</guide>

Anyway, the original markup passed epubcheck, so obviously epubcheck
needs to be fixed to make sure the href points to a manifest content
document.

[Peter Sorotokin]

Everyone,

Because am juggling too many projects at once, I may or may not remember about email conversations like that when I have free time slot to fix epubcheck. If you found what you think is an error in epubcheck, please file an issue at http://code.google.com/p/epubcheck/issues/list and supply an EPUB file. A lot of times I hear that people are hesitant to create an issue because they do not know if it is really a bug. If it turns out to be not a bug, there is no problem, it does not make me unhappy at all. But if I do not have the offending EPUB or if I have to hunt error descriptions around, it just takes me significantly much time to fix them and that does make me unhappy.

Short of writing the code, creating issues is the best help you can provide in epubcheck development.

Thank you!

Peter

-----Original Message-----
From: Jon [mailto:jno...@gmail.com]

[Liza Daly]

As a developer, I totally agree and want to second Peter's request
(for example, when reporting issues with Bookworm on the issue tracker
at http://code.google.com/p/threepress/issues/list).

If you supply an epub, we can much more easily write tests to confirm
that the behavior has been corrected. Since both projects are open
source, it would be best to include a document that you don't mind
being part of the open source code itself, as e.g. Bookworm ships with
its entire test suite under the BSD license.

Liza