feat: any file extension is now allowed #1373
Conversation
EPUB 3.3 has no longer any requirement for file extensions. EPUBCheck only checked the extension of XHTML files, this check is now suppressed. This commit: - removes the check for `.xhtml` (supresses `HTM_014a`) - keeps the old check for EPUB 2.0.1 - add tests for various file extensions Fox #1223
|
Any particular reason why this change away from the epub 3 spec was made? Sigil follows the original epub3 spec here and given there is no way to distinguish between epub 3.0 and epub 3.3 via the opf package tag (it still recommends "3.0" be used in the package tag even for "3.3") there is no way to detect if a epub should be held to the epub 3.0, 3.1, or 3.2 spec instead of the epub 3.3 spec. Do all current epub 3 readers work properly when you allow any extension? Or does this break some epub3 readers that serve pages based on the file extension? If not, this change away from the base spec should have waited for an epub 4.0 spec change. |
You'll find some discussion in the related spec issue: w3c/epub-specs#1294
Yes, this is on purpose. "EPUB 3" is intended to be largely backward compatible, and the latest stable version of the spec is the only one recommended for use (in other words, EPUB 3.3 replaces previous EPUB 3.x versions).
As far as I'm aware most EPUB 3 readers work properly. The way reading systems serve pages is not specified by EPUB; notably, EPUB does not defined how RS must detect the file MIME type. |
|
If you have any further comments or questions, I would suggest you file them to w3c/epub-specs, as your comment seems to be related to the specification rather than to EPUBCheck itself. It will reach more people there 😊 |
EPUB 3.3 has no longer any requirement for file extensions. EPUBCheck only checked the extension of XHTML files, this check is now suppressed.
This commit:
.xhtml(supressesHTM_014a)Fix #1223