feat: Add EPUB for output option #418
Conversation
This option is a workaround for the problem that reading progression cannot be inferred when a single HTML input is specified. If no publication manifest is given, the only way to infer reading progression is to parse the CSS, but it is difficult to provide a complete CSS parser.
This is necessary for JSDOM canvas support https://github.com/jsdom/jsdom/tree/master#canvas-support
|
EPUB生成を試してみました。 テストの素材として https://github.com/spring-raining/tbf13-draft を使いました。 vivliostyle-cliのこのPRをビルドしてから、その親のディレクトリで まず、PDFを生成してみる： これでPDFファイル tbf13-draft.pdf が生成できた。次にEPUBの生成をテスト： この生成されたEPUBをunzipして中身を確認する: EPUBディレクトリ内に EPUBに含めるのは、EPUBに必要なリソースだけにするべきではないでしょうか？ |
|
Typo in #418 (comment): "pub-manfiest" → "pub-manifest" |
|
このPRのテスト中に気がついたEPUBプレビューでの問題： |
|
configの テストサンプル これをgit cloneして、vivliostyle.config.jsに スクリーンショット 生成された index.xhtml の内容: <?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops"><head>
<title>海外�旅〔上〕</title>
<link href="publication.json" rel="publication" type="application/ld+json" />
<link href="theme/theme.css" rel="stylesheet" />
</head>
<body>
<h1>海外�旅〔上〕</h1>
<nav id="toc" role="doc-toc" epub:type="toc">
<h2>Table of Contents</h2>
<ol>
<li><a href="text/index.xhtml">海外�旅〔上〕</a></li>
<li><a href="text/chap01.xhtml">一ï¼�åˆ�ã‚�ã�¦ã�®ãƒ¨ãƒ¼ãƒãƒƒãƒ‘ã�®æ—…</a></li>
<li><a href="text/chap02.xhtml">二ï¼�2回目ã�®ãƒ¨ãƒ¼ãƒãƒƒãƒ‘ã�®æ—…</a></li>
<li><a href="text/chap03.xhtml">三�カナダ�アメリカ�旅</a></li>
<li>
<a href="text/chap04.xhtml">四�タイ�ミャンマー�インド��旅</a>
</li>
<li><a href="text/chap05.xhtml">五��インド�スリランカ�旅</a></li>
<li><a href="text/backmatter.xhtml">奥付</a></li>
</ol>
</nav>
<nav epub:type="landmarks" id="landmarks" hidden=""><ol><li><a epub:type="toc" href="index.xhtml#toc">Table of Contents</a></li></ol></nav></body></html>toc.ncx の内容のテキストも同様に文字化け。 |
この例をテストしてみました。 EPUBができました。この内容を確認します： publication.json ファイルが含まれているのが気になります。この内容を見ると、readingOrder が次のように指定されてます： "readingOrder": [
{
"url": "vivliostyle_doc/samples/gon/index.html"
}
],しかし、このファイル "vivliostyle_doc/samples/gon/index.html" はEPUB内に含まれていません。EPUB内にあるのはXHTMLに変換されて拡張子が <link rel="publication" type="application/ld+json" href="../../../publication.json" />前のコメント #418 (comment) の繰り返しになりますが、publication.json のようなEPUBに不要なファイルは含まれないようにして、XHTMLファイルにもpublication.jsonへのリンクを入れないようにするべきだと思います。 |
この例をテストすると、次のようにエラーになってEPUBは生成できません： このエラーの理由は次のようです： https://www.w3.org/TR/wpub/ のHTMLには次のように publication manifest が含まれている： <link rel="publication" href="#wp_manifest" />
<script type="application/ld+json" id="wp_manifest">{
"@context": [
"https://schema.org",
"https://www.w3.org/ns/wp-context"
],この publication manifest は、この2019年のW3Cノート Web Publications (W3C Working Group Note 13 August 2019) の時点で定義されていたもので、そのあと2020年に勧告になった Publication Manifest (W3C Recommendation 10 November 2020) ではpublication manifest仕様が少し変わって （なお、Vivliostyle.jsの問題で https://www.w3.org/TR/wpub/ をViewerでロード中にエラーが発生してました。これについては vivliostyle/vivliostyle.js#1209 で修正済み。） このwpubのW3Cノートは特殊なケースなので、「Supports single-doucment publication」の例に使うのは別のものにしたほうがよいかと思います。そこでW3C仕様で別の例を試したところ： EPUBが生成されずに終了します。次も同様： |
|
@MurakamiShinyu 詳細なレビューありがとうございます。
まずはこちらの問題について対応する予定です。現在の
出力されるEPUBのcontent.opfの内容は以下のように拡張子がXHTMLに変換されたものになっています。publication.jsonの内容はEPUBリーダーからは無視されるため、EPUBファイルとしては問題なく読み込める形式になっています。 <manifest>
<item id="vivliostyle_docsamplesgonindexxhtml" href="vivliostyle_doc/samples/gon/index.xhtml" media-type="application/xhtml+xml" properties="nav"></item>
...
</manifest>
<spine toc="tocncx">
<itemref idref="vivliostyle_docsamplesgonindexxhtml"></itemref>
</spine>ただ、確かに不要なpublication.jsonがあることで紛らわしくなっています。上記の対応で、publication.jsonもEPUBに含めないようにします。
こちらはサンプルが良くなかったです。vivliostyle-cliが準拠しているPublication Manifestのドキュメントを指定すると、エラーが表示されずに正しくEPUBが出力されます。
すみません、こちらは私の環境では問題が再現できていません。より詳細な再現状況を教えてもらえますか？ もしくは、dependencyの再インストールと再ビルド ( |
私の環境では、いずれもEPUBが生成されずに終了してしまいます。 この問題が起きる環境で、VS Codeのデバッガで調べて以下のことが分かりました。 HTML内容のロード中に、"jsdomError" が発生して、例外が投げられて終了しています。次のところ： vivliostyle-cli/src/processor/html.ts Lines 36 to 48 in 0faa333 このときの "jsdomError" の error の内容は以下です：
つまり、SVG画像 https://www.w3.org/StyleSheets/TR/2016/logos/W3C が "Error: node-canvas was built without SVG support" のためにロードできずにエラーになっています。W3C文書にはW3Cロゴを表示するため、このSVG画像を埋め込むimg要素 単純化したHTMLファイルでもテストしてみました。
私のMacのarm64環境の場合のテスト結果： 
x86_64環境の場合のテスト結果： 
このように、SVG画像を参照するimg要素がある場合、arm64環境ではEPUBが生成されず、x86_64環境では正常にEPUBが生成されます。 SVG画像の内容が壊れている場合は、いずれの環境でもEPUBが生成されません。何のエラーメッセージも出ないのでこれも問題があると思います。 存在しないファイルを参照するimg要素がある場合、いずれの環境でもEPUBが生成されません。このケースでは "Failed to fetch webbook resources:" とエラーメッセージが出ます。 ためしに、上記 "jsdomError" のエラーの処理のところで、例外を投げないでそのままた return するようにしたところ、どのテストでもEPUBが生成されるようになりました。存在しないファイルを参照するimg要素がある場合でも "Failed to fetch webbook resources:" とエラーメッセージが出るけれども、EPUBは生成されます。 arm64環境でだけ "Error: node-canvas was built without SVG support" となるのは、node-canvas の次の問題のようです: |
|
詳細な調査ありがとうございます。ARM64でnode-canvasが使えないのは問題ですね…解決方法を探してみます |
|
@MurakamiShinyu 以下の修正が完了しました。
なお、
こちらのドキュメントについては、引き続きエラーメッセージが出ずに終了してしまう問題があります。これは、参照しているライブラリ (Skia) で破損したSVGファイルを読み込もうとしたときにsegfaultが発生することが原因で、すぐの対応が難しそうです。発生条件もそれほど高くなさそうなので、一旦既知の問題としてそのままリリースする予定です。 |
|
@spring-raining 修正確認しました。 質問です。 if (error.message === 'Could not parse CSS stylesheet') {
return;
}SVGに限らずimgに対しても例外を投げないように、 if (error.message.startsWith('Could not load img:')) {
return;
}などとするのではだめだったのでしょうか？ そうしないでJSDOMをforkして、node-canvasを別のものにした理由は何でしょう？ |
|
EPUB・WebPubの生成のとき、コマンドラインで
例： titleがないとエラーになる。そこで 生成されたEPUBを見ると、指定したタイトル "SVG Properties Test" がOPFファイルに入っているので、
が出るのは単に間違いのようです。 |
|
webbook→webpub/epubconversionSupported ouptuts
pdfwebpubepubpub-manifestmarkdownwebbook(including remote HTML files)epubepub-opf