Pdf.js: Systemjsをサポート

作成日 2015年12月22日 · 34コメント · ソース: mozilla/pdf.js

systemjsのサポートを追加してください。

2-feature

ソース

Vanuan

全てのコメント34件

例がないので、もっと情報をお願いします。そして、Browserifyは現在pdfjs-distで動作すると思います（いくつかのモジュールの例外を除いて）。

yurydelendik 2015年12月22日

systemjsを使用する最も一般的な例を次に示します。

npm install jspm
jspm init # use defaults
jspm install pdfjs-dist

index.html

<!DOCTYPE html>
<html lang="en-us">

<head>
<meta charset="utf-8">
<title>Title</title>
</head>

<body>
    <script src="jspm_packages/system.js"></script>
    <script src="config.js"></script>
    <script>
      System.import('src/app.js');
    </script>
</body>
</html>

src / app.js

# ES6 syntax
import pdfjs from 'pdfjs-dist';

# expected pdfjs to be a window.PDFJS object

Vanuan 2015年12月22日

例えばありがとう

yurydelendik 2015年12月22日

以前のバージョンでは、jspmshimを使用してpdfjsを使用できました。
https://github.com/jspm/registry/wiki/Configure-Packages-for-jspm
しかし、node-ensureを含めた後は、できません（node-ensureはsystem.jsと互換性がないようです）。

Vanuan 2015年12月22日

実際、これはjspmパッケージャーに対する要求であり、特にSystemjsローダーに対する要求ではありません。
つまり、jspm shimが必要な場合は問題ありませんが、node-ensureのような互換性のない変更を追加しないでください。

Vanuan 2015年12月22日

@Vanuan

config.jsに次の問題を回避します。

    "npm:[email protected]": {
      "process": "github:jspm/[email protected]",
      "node-ensure": "empty",
      "entry?name=[hash]-worker.js": "empty"
    },

（emptyはコンテンツのないempty.jsファイルです）

Browserifyにも同様のハックが必要です

yurydelendik 2015年12月22日

現在の問題：pdf.worker.jsが2回読み込まれます。これは、webpackのrequest.ensure（）によって解決された問題です。 './pdf.worker.js'は、本当に必要になるまでロードを禁止する必要があります。

yurydelendik 2015年12月22日

「PDFJS.disableWorker = true;」と思いました。それを解決しますか？そうですね。

Vanuan 2015年12月22日

System.import('./pdf.worker')を使用すると、1つのhttpリクエストのみが発行されます。

またはSystem.import('pdfjs-dist/build/pdf.worker')

node-ensureが使用された特定の理由はありますか？システムローダーはWebpackで正常に動作すると思います。

Vanuan 2015年12月22日

"PDFJS.disableWorker = true;" PDF処理を別のスレッドに移動したいので、これはオプションではありません。図書館のユーザーにひどい解決策を提案したくないのですよね？

yurydelendik 2015年12月22日

まあ、私はまったく解決策がないよりもお粗末な解決策を好むでしょう。私のユースケースでは、1秒のページフリーズでも問題ありません。
より良い解決策を見つけていただければ幸いです。

Vanuan 2015年12月22日

node-ensureが使用された特定の理由はありますか？

examples / webpack /が生成するものを注意深く見ると、次のようになります。

pdf.js yury$ ls -la build/webpack/
total 2384
drwxr-xr-x   5 yury  staff     170 Dec 22 15:20 .
drwxr-xr-x  34 yury  staff    1156 Dec 22 10:08 ..
-rw-r--r--   1 yury  staff  546125 Dec 21 16:35 1.bundle.js
-rw-r--r--   1 yury  staff  546463 Dec 21 16:35 9d074593b165291f150e-worker.js
-rw-r--r--   1 yury  staff  122796 Dec 21 16:35 bundle.js

「bundle.js」はロードするメインファイルです（つまり、122796バイト後にUIを取得して初期化します-ページの起動が速くなります）。「9d074593b165291f150e-worker.js」は、ロジックを実行し、低速のデバイスでUIをロックしないワーカーです。「1.bundle.js」の部分は、disableWorkerがトリガーされた場合、およびIE9などのレガシーブラウザーの場合にのみ読み込まれます。

yurydelendik 2015年12月22日

より良い解決策を見つけていただければ幸いです。

systemjsには、すべての要件を解析しないための何らかのガードがあると思います（「./pdf.worker.js」を「empty」に置き換えても機能しませんでした）。

@Vanuan systemjsに問題を報告して、もっと良いことを考えているかどうかを確認できますか？ありがとう。

yurydelendik 2015年12月22日

systemjs https://github.com/systemjs/systemjs/issues/983の最後の問題のように聞こえ

yurydelendik 2015年12月22日

まあ、私はまったく解決策がないよりもお粗末な解決策を好むでしょう。私のユースケースでは、1秒のページフリーズでも問題ありません。

@ Vanuan 、pdf.combined.jsファイルの使用法に変更はありません（私は願っています）-そのような場合のためにそれを保持する必要があるようです。＃6729で問題として説明したように使用する必要があります。あなたの説明から、PDFJSをロードするためにsystemjsを使用することを計画していることは明らかではありませんでした。

yurydelendik 2015年12月22日

pdf.combined.jsファイルの使用法に変更はありません

ああ、すごい！

Vanuan 2015年12月22日

とにかく、それを労働者と一緒に使うことに関して何かが間違いなく変わった。
以前は、ワーカーへのフルパスを使用できましたが、その中にUncaught ReferenceError: require is not defined取得します。

PDFJS.workerSrc = 'jspm_packages/npm/[email protected]/build/pdf.worker.js';

今、それはファイルのロードで立ち往生しているようです。モジュールがロードされたコールバックが決して完了しないかのように。
最後に要求されたモジュールはprocessです。

おそらく、Systemjsは次の構造を処理できません。

(function(process) {
  if (typeof PDFJS === 'undefined') {
    (typeof window !== 'undefined' ? window : this).PDFJS = {};
  }
})(require('process'));

Vanuan 2015年12月23日

👍1

とにかく、それを労働者と一緒に使うことに関して何かが間違いなく変わった。
以前は、ワーカーへのフルパスを使用できましたが、

pdf.combined.jsは完全に含まれています/pdf.worker.jsを含み、workerSrcを指定する必要はありません。

yurydelendik 2015年12月23日

pdf.combined.jsへの変更https://github.com/mozilla/pdfjs-dist/commit/a7cd5f77b00bac19c0f6ee4c2cfd5bbf0fe45d8f#diff-eccf5b94e31b0939738de07167e02af6

yurydelendik 2015年12月23日

ええ、私はjspmと一緒にワーカーを使用するオプションを評価しているだけです。

Vanuan 2015年12月23日

現在の問題：pdf.worker.jsが2回読み込まれます。これは、webpackのrequest.ensure（）によって解決された問題です。

それで、今それはメインスレッドにロードされており、importScripts（）を使用していませんか？

Vanuan 2015年12月23日

私のsrc / app.jsは次のとおりです。

import pdfjs from 'pdfjs-dist';

console.log(PDFJS);

したがって、まだgetDocumentを使用していませんが、ネットワークモニターでは、pdf.worker.jsの2つのエントリが表示されます。

yurydelendik 2015年12月23日

おかしいです。エントリが1つだけ表示されます。

Vanuan 2015年12月23日

おかしいです。エントリが1つだけ表示されます。

それは何もAFAIKではありません:)

yurydelendik 2015年12月23日

FirefoxとChromeでも同じです。
screen shot 2015-12-22 at 5 34 42 pm

yurydelendik 2015年12月23日

ああ。したがって、Systemjsはすべてのrequire愚かに解析し、それらをロードしようとしているように見えます...

Vanuan 2015年12月23日

条件付きrequireは、あまり一般的なユースケースではありません。

Vanuan 2015年12月23日

そのため、node-ensureもロードしようとします。

Vanuan 2015年12月23日

@yurydelendik
どのようにヘルプwebpackが必要ですか？ WebpackはまだimportScriptsを使用してワーカーをロードしますよね？

Vanuan 2015年12月23日

条件付きrequireは、あまり一般的なユースケースではありません。

私は同意しません。https：//github.com/systemjs/systemjs/issues/983とhttps://github.com/webpack/docs/wiki/code-splittingが一般的なユースケースです。

WebpackはまだimportScriptsを使用してワーカーをロードしますよね？

~~します。~~ new Worker(..)経由。ただし、ワーカーが無効になっている場合は、pdf.worker.jsをモジュールとしてロードするオプションもあります。

yurydelendik 2015年12月23日

この問題は＃6775によって解決されます-systemjsはモジュールのタイプを自動検出します。これでcommonjsになり、UMDではAMDになるため、require（）を解析しようとはしません。

https://github.com/yurydelendik/pdf.js/tree/pdfjsumdでの

yurydelendik 2015年12月28日

うわー、すごい、マージしてリリースされたらすぐに試してみます。

Vanuan 2015年12月28日

＃6825で修正されたとおりに終了します。問題が残っている場合は、新しい問題を開いてください。

timvandermeij 2016年01月08日

また、jspmを使用する場合は、モジュール形式をオーバーライドすることをお勧めします： jspm install npm:pdfjs-dist -o "{format: 'amd'}"

yurydelendik 2016年04月04日

このページは役に立ちましたか？

0 / 5 - 0 評価

Pdf.js: Systemjsをサポート

全てのコメント34件

関連する問題