Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fragment identifiers in manifest #1085

Closed
dauwhe opened this issue Oct 29, 2019 · 2 comments
Closed

fragment identifiers in manifest #1085

dauwhe opened this issue Oct 29, 2019 · 2 comments
Labels
status: completed Work completed, can be closed type: improvement The issue suggests an improvement of an existing feature

Comments

@dauwhe
Copy link
Contributor

dauwhe commented Oct 29, 2019

As an experiment I tried to put a fragment identifier on an item:

  <item id="content_001"  href="content_001.xhtml#p2" media-type="application/xhtml+xml"/>

EPUBCheck seems to interpret the fragment as part of the file extension:

WARNING(HTM-014a): ..epub/OPS/package.opf(11,91): XHTML Content Document file name 'OPS/content_001.xhtml#p2' should have the extension '.xhtml'.
ERROR(RSC-001): ..epub/fragment.epub(-1,-1): File 'OPS/content_001.xhtml#p2' could not be found.
ERROR(RSC-008): ..epub/OPS/nav.xhtml(8,33): Referenced resource 'OPS/content_001.xhtml' is not declared in the OPF manifest.
WARNING(OPF-003): ..epub/fragment.epub(-1,-1): Item 'OPS/content_001.xhtml' exists in the EPUB, but is not declared in the OPF manifest.

Perhaps EPUBCheck could provide a more informative message.


While researching this haven't yet found anything in EPUB 3.2 that forbids fragment identifiers in href attributes! Stay tuned.

@rdeltour
Copy link
Member

Good, catch! The message could definitely be improved.

While researching this haven't yet found anything in EPUB 3.2 that forbids fragment identifiers in href attributes!

I think it's kinda implied by the spec saying:

Each item element in the manifest identifies a Publication Resource by the IRI [RFC3987] provided in its href attribute

but yeah it would be worth being explicit.

@rdeltour rdeltour added status: accepted Ready to be further processed type: improvement The issue suggests an improvement of an existing feature labels Oct 29, 2019
@rdeltour rdeltour added status: completed Work completed, can be closed and removed status: accepted Ready to be further processed labels Dec 8, 2022
@rdeltour
Copy link
Member

rdeltour commented Dec 8, 2022

That should be fixed since #1359. Closing as completed.

@rdeltour rdeltour closed this as completed Dec 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: completed Work completed, can be closed type: improvement The issue suggests an improvement of an existing feature
Projects
None yet
Development

No branches or pull requests

2 participants