MIME types for PDF

[User_Z]

Hello.

Added a pdf document to ePub.
Now, when opening a book, the editor issues a warning about an unknown type.
Sigil doesn't understand basic MIME types?

How to fix it?

If you do not pay attention to this warning and a reminder to save the file, then everything works.

[Doitsu]

Originally Posted by User_Z

Added a pdf document to ePub.
Now, when opening a book, the editor issues a warning about an unknown type.
Sigil doesn't understand basic MIME types?

You'll need to create a fallback item. For more information see this post.
Unfortunately, the current Sigil version doesn't support application/pdf and won't display the fallback .xhtml page.

@KevinH & DiapDealer
(Sigil 0.9.8 shows the fallback text; application/pdf is an IANA mime type.)

Here's a link to an old proof-of-concept test case that'll generate the same warnings that the OP reported.
It passes EPUBCheck, except for an unrelated empty guide item error.

The embedded Calibre sample .pdf file looks like this in ADE 2 and 4:

Spoiler:

Here's another test case by Jellby: ePUB with PDF embedded test

[KevinH]

Unfortunately, that was 2009 and even by 2015 fallbacks were still not accepted by most epub reading systems.

See this epubcheck issue post from 2015 for example:

https://github.com/w3c/epubcheck/issues/511

And as pointed out, fallbacks are a feature of the e-reader and not Sigil. It is up to the e-reading system to decide if and how to handle fallbacks. As a design tool, Sigil should allow the user to create fallbacks that must then be tested on multiple e-readers.

Sigil supports all epub3 core media types. But application/pdf is not a epub3 core media type and so is not guaranteed to be supported by epub e-readers.

I could add support for recognizing the application/pdf mime type in Sigil, but given the horrendous state of e-reader fallback support and all of the issues Jelby mentioned, it would be a real mistake for anyone to use it for a commercial epub.

Not even all browser engines support pdf without additional plugins.

I will at least change Sigil to not replace it but frankly embedding a pdf inside an epub is not a good idea (IMHO). Contrary to public opinion an epub is not a website just rolled into a zip and never should be.

Update:
Even worse, to be epubcheck legal you must create an xhtml or svg version of the pdf and label it as the fallback. Once you have an xhtml or svg version of the pdf, why on earth include the pdf at all? I think Adobe ADE2 / ADE4 supporting pdf is just Adobe pushing its own products and trying to extend the spec just like they tried with their multi-column layout, font obfuscation rules, and pagemap.xml.

Update 2:
FWIW, neither Thorium or Readium e-readers work with that Gulliver's Travels test epub at all.

[KevinH]

In addition, support for QtWebEngine QWebEngineSettings QWebEngineSettings::PdfViewerEnabled was not added until Qt 5.13 and our base Windows and MacOSx builds are based on Qt 5.12.X.

If we move up to Qt 5.15.X we will lose some currently supported platforms as Qt 5.15 only builds on later versions of MacOS and Windows.

[KevinH]

So all in all, I am not sure adding support to Sigil for embedding a pdf inside an epub makes much sense given the epub3 fallback rules.

I will change Sigil to recognize the application/pdf mimetype and not try and change it but that is all.

[User_Z]

Originally Posted by KevinH

I will change Sigil to recognize the application/pdf mimetype and not try and change it but that is all.

Great!

This is exactly what I was talking about in my post raising this topic.

After all, no one denies the very fact of the existence of the PDF format? On the contrary, many people actively use it. You just turned a blind eye to it for a long time.
And now, you give an opportunity! Use it or not - it will be the choice of a particular user.

I agree, the book "Gulliver's Travels" is more than strange. Like Siamese twins from different fathers who need to be operated on immediately.
But sometimes, embedding an example or sample on one or two pages is a perfectly acceptable solution.

The fact that some readers still cannot handle PDF is, as they say, their problem. Such primitive readers will soon be forgotten or not known at all, and people, ordinary users, will take more advanced things.
It's just terrible that all these personalities constantly saying "this is superfluous", "it will do", "we don't need this", "it's expensive", "it will cost", "we know better than you how to", "we don't want and we won't do it", "not expedient", "does not meet modern trends", "I don't understand this", "the time has not come", "not according to the rules", etc. prevent humans from landing on Mars.

[KevinH]

The point that you seem to have missed completely was the need to create a fallback from xhtml/svg for a pdf (and that is according to the very latest epub spec) and the fact that the very latest e-readers (outside of Adobe ones) do not support pdf when embedded inside an epub means that support for embedded pdf is NOT growing. And these are not "primitive e-readers", these are the latest browser engine based e-readers.

Reading pdf and supporting it embedded inside an epub are two very different things. Both are ebook formats. It is kind of like asking if you can embed a azw3 inside an epub which no one expects to work.

Again, the epub3 spec clearly states that pdf is not core mimetype and so even the newest epub3 readers need not support it when embedded inside an epub. Sigil's goal is to help make spec compliant epubs so it recognizes and supports the core media types.

[KevinH]

Added support for recognition of "application/pdf" as a valid media type has been pushed to Sigil master. The only way to truly work with an internal pdf in Sigil is to use the OpenWith menu on it in BookBrowser and choose an external pdf editor/viewer.

And as the spec says you need to add a manifest fallback using xhtml/svg so your epub can be used in epub spec compliant e-readers that will most likely not support internal pdfs.

[User_Z]

[KevinH]

Interesting article from daisy.org about fallbacks being disused:

Manifest fallbacks are named for how they are implemented in the EPUB package document. The manifest element is used to list all the resources used in the publication, and each item in it can specify another item as a fallback using the fallback attribute.

There are two places that manifest fallbacks are used. The first is to include unknown media types in the spine (i.e., to make them documents in the publication reading order). This practice has largely fallen into disuse, however, as it was used primarily in EPUB 2 to allow SVG images in the spine with XHTML fallbacks.

SVG in spine (EPUB 2)
<manifest>
   <item id="c01" src="images/plate01.svg" media-type="image/svg" fallack="c01-xhtml"/>
   <item id="c01-xhtml" src="images/plate01.xhtml" media-type="application/xhtml+xml"/>
   …
</manifest>
<spine>
   <itemref idref="c01"/>
   …
</spine>

In this case, if the reading system does not support SVG, it follows the fallback attribute references until it finds a media type it can support. In the above case there is only one fallback, but it is possible to keep falling back through multiple items before reaching a supported media type. The only requirement on fallback chains is that they must include a core media type.

The other place where manifest fallbacks are used is to provide a fallback image for the HTML img element. Until the recent addition of the srcset attribute and creation of the new picture element, it was not possible in HTML to provide a fallback for images embedded using the img element. As a workaround, reading systems are expected to change the source of the img element to the fallback specified in the manifest.

[KevinH]

For the record this epubcheck issue concerns manifest fallbacks (now discouraged according to that discussion) plus mentions pdf and how best to follow the html spec.

https://github.com/w3c/epub-specs/issues/1464

Interesting discussion.

So viewing of pdf may or may not come in a future epub spec if they fully deprecate manifest fallbacks.

I will explore how best to more fully support pdf in Sigil master for a future release just in case the spec moves that way.

[Turtle91]

Sooooo.... does that mean I will finally be able to embed my pdf into an epub so users will see it EXACTLY as I want them to?????

[DiapDealer]

Even if it costs us Mars, I have to say that I can't imagine a worse ebook idea than embedding pdfs in an epub.

[KevinH]

Originally Posted by DiapDealer

Even if it costs us Mars, I have to say that I can't imagine a worse ebook idea than embedding pdfs in an epub.

Fully agreed!

For planning purposes only, I took a look at what might be required. If using Qt 6.2.x or Qt 5.15 or later, it is reasonably easy to add a PdfResource, a PdfTab, and a PdfView widget source code plus some associated changes to make things work in Sigil.

I will push these basic changes to a new branch of Sigil (*not master*) just so they are not lost in case we ever need to add it to be spec compliant in the future.

But only if truly required by the spec as converting any pdf to xhtml, svg, or even a sequence of screen cap images really makes supporting embedded pdf superfluous (and therefore a bad idea as it really adds nothing while complicating things even more).

[KevinH]

FWIW - the branch embed-pdf now exists in our github repo in case ever needed.