Pdf.js: Support Systemjs

Erstellt am 22. Dez. 2015  ·  34Kommentare  ·  Quelle: mozilla/pdf.js

Bitte fügen Sie Unterstützung für systemjs hinzu.

2-feature

Alle 34 Kommentare

Ich würde weitere Informationen anfordern, da keine Beispiele angegeben sind. Und ich denke, Browserify funktioniert derzeit mit pdfjs-dist (mit einigen Modulausnahmen).

Hier ist das häufigste Beispiel für die Verwendung von 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

Danke zum Beispiel

In früheren Versionen konnten wir jspm shim verwenden, um pdfjs zu verwenden.
https://github.com/jspm/registry/wiki/Configuring-Packages-for-jspm
Nach der Aufnahme von Node-Sure können wir dies jedoch nicht (Node-Sure scheint nicht mit system.js kompatibel zu sein).

Tatsächlich ist dies eine Anfrage für jspm packager, nicht speziell für Systemjs Loader.
Dh es wäre in Ordnung, wenn es jspm shim erfordern würde, aber füge keine inkompatiblen Änderungen wie Node-Sureise hinzu.

@ Vanuan

Folgendes in der Datei config.js umgeht das Problem:

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

(leer ist eine empty.js-Datei ohne Inhalt)

Ein ähnlicher Hack ist für Browserify erforderlich

Jetzt Problem: pdf.worker.js wird zweimal geladen, das ist ein Problem, das durch request.ensure () im Webpack behoben wurde. Das Laden der Datei './pdf.worker.js' muss verboten werden, bis sie wirklich benötigt wird.

Ich dachte "PDFJS.disableWorker = true;" löst das? Ist es nicht?

Wenn Sie System.import('./pdf.worker') , wird nur eine http-Anfrage ausgegeben.

Oder sogar System.import('pdfjs-dist/build/pdf.worker')

Gibt es einen bestimmten Grund, warum node-ensure verwendet wurde? Ich glaube, dass System Loader in Webpack gut funktioniert.

"PDFJS.disableWorker = true;" ist keine Option, da wir die PDF-Verarbeitung auf den anderen Thread verschieben möchten. Wir wollen keine miese Lösung für Bibliotheksbenutzer vorschlagen, oder?

Nun, ich würde eine miese Lösung vorziehen als gar keine Lösung. Für meinen Anwendungsfall ist sogar das Einfrieren einer Seite von 1 Sekunde in Ordnung.
Ich würde mich freuen, wenn Sie eine bessere Lösung finden.

Gibt es einen bestimmten Grund, warum Node-Sure verwendet wurde?

Wenn Sie sich genau ansehen, welche Beispiele / webpack / produziert:

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" ist die Hauptdatei, die geladen wird (das heißt, sie bringt die Benutzeroberfläche nach 122796 Bytes und initialisiert sie - schnellerer Seitenstart). "9d074593b165291f150e-worker.js" ist ein Worker, der die Logik ausführt und die Benutzeroberfläche auf langsamen Geräten nicht sperrt. Der Teil "1.bundle.js" wird nur geladen, wenn disableWorker ausgelöst wird und für ältere Browser wie IE9.

Ich würde mich freuen, wenn Sie eine bessere Lösung finden.

Ich gehe davon aus, dass das System möglicherweise eine Art Schutz hat, der nicht alle Anforderungen analysiert (das Ersetzen von "./pdf.worker.js" durch "leer" hat bei mir nicht funktioniert).

@ Vanuan Können Sie ein Problem mit systemjs einreichen, um zu sehen, ob sie etwas Besseres im Sinn haben? Vielen Dank.

Klingt nach der allerletzten Ausgabe unter systemjs https://github.com/systemjs/systemjs/issues/983 ?

Nun, ich würde eine miese Lösung vorziehen als gar keine Lösung. Für meinen Anwendungsfall ist sogar das Einfrieren einer Seite von 1 Sekunde in Ordnung.

@ Vanuan , an der Verwendung der Datei

An der Verwendung der Datei pdf.combined.js hat sich nichts geändert

Ah gut!

Wie auch immer, etwas hat sich definitiv geändert, was die Verwendung mit Arbeitern betrifft.
Zuvor konnten wir den vollständigen Pfad zum Worker verwenden, aber Uncaught ReferenceError: require is not defined darin enthalten:

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

Jetzt scheint es, als ob es beim Laden von Dateien hängen bleibt. Als ob der vom Modul geladene Rückruf niemals abgeschlossen wird.
Das zuletzt angeforderte Modul ist process .

Wahrscheinlich kann Systemjs die folgende Konstruktion nicht verarbeiten:

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

Wie auch immer, etwas hat sich definitiv geändert, was die Verwendung mit Arbeitern betrifft.
Zuvor konnten wir den vollständigen Pfad zum Arbeiter verwenden.

pdf.combined.js ist vollständig enthalten / enthält pdf.worker.js und erfordert nicht, dass workerSrc angegeben wird.

Änderungen an pdf.combined.js https://github.com/mozilla/pdfjs-dist/commit/a7cd5f77b00bac19c0f6ee4c2cfd5bbf0fe45d8f#diff -eccf5b94e31b0939738de07167e02

Ja, ich prüfe nur die Möglichkeiten, Worker zusammen mit JSPM einzusetzen.

Jetzt Problem: pdf.worker.js wird zweimal geladen, das Problem wurde durch request.ensure () im Webpack behoben

Also, jetzt wird es in den Hauptthread geladen und verwendet keine importScripts ()?

Meine src / app.js ist:

import pdfjs from 'pdfjs-dist';

console.log(PDFJS);

Es wird also noch nicht einmal getDocument verwendet, aber im Netzwerkmonitor werden zwei Einträge für pdf.worker.js angezeigt

Es ist komisch. Ich sehe nur einen Eintrag.

Es ist komisch. Ich sehe nur einen Eintrag.

Es soll keine AFAIK sein :)

Das gleiche gilt für Firefox und Chrome:
screen shot 2015-12-22 at 5 34 42 pm

Ah. Es sieht also so aus, als würde Systemjs alle require s dumm analysieren und versuchen, sie zu laden ...

Bedingte Anforderungen sind kein sehr häufiger Anwendungsfall.

Aus diesem Grund wird auch versucht, Node-Aure zu laden.

@yurydelendik
Wie benötigt solche Hilfe Webpack? Webpack lädt immer noch Worker mit importScripts, oder?

Bedingte Anforderungen sind kein sehr häufiger Anwendungsfall.

Ich würde nicht zustimmen, https://github.com/systemjs/systemjs/issues/983 und https://github.com/webpack/docs/wiki/code-splitting sind häufige Anwendungsfälle.

Webpack lädt immer noch Worker mit importScripts, oder?

Es tut. über new Worker(..) . Es besteht jedoch auch die Möglichkeit, pdf.worker.js als Modul zu laden, wenn Worker deaktiviert sind.

Das Problem wird durch # 6775 behoben - das System hat eine automatische Erkennung für den Modultyp. Jetzt ist es üblich, mit UMD wird es AMD sein, so dass es nicht versucht, require () zu analysieren.

PS-Wip unter https://github.com/yurydelendik/pdf.js/tree/pdfjsumd

Wow, großartig, ich werde es versuchen, sobald es zusammengeführt und veröffentlicht ist.

Schließen wie durch # 6825 festgelegt. Wenn es noch Probleme gibt, öffnen Sie bitte eine neue Ausgabe.

Ich empfehle außerdem, das Modulformat bei Verwendung von jspm zu überschreiben: jspm install npm:pdfjs-dist -o "{format: 'amd'}"

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen