Pdf.js: Support Systemjs

Créé le 22 déc. 2015 · 34Commentaires · Source: mozilla/pdf.js

Veuillez ajouter la prise en charge de systemjs.

2-feature

Source

Vanuan

Tous les 34 commentaires

Je demanderais plus d'informations car aucun exemple n'est fourni. Et je pense que Browserify fonctionne actuellement avec pdfjs-dist (avec quelques exceptions de modules).

yurydelendik le 22 déc. 2015

Voici l'exemple le plus courant d'utilisation de 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 le 22 déc. 2015

Merci par exemple

yurydelendik le 22 déc. 2015

Dans les versions précédentes, nous pouvions utiliser jspm shim pour utiliser pdfjs.
https://github.com/jspm/registry/wiki/Configuring-Packages-for-jspm
Mais après l'inclusion de node-ensure, nous ne pouvons pas (node-ensure ne semble pas être compatible avec system.js).

Vanuan le 22 déc. 2015

En fait, il s'agit d'une demande pour le packager jspm, pas spécifiquement pour le chargeur Systemjs.
C'est-à-dire que ce serait bien si cela nécessitait un shim jspm, mais n'ajoutez pas de modifications incompatibles comme node-ensure.

Vanuan le 22 déc. 2015

@Vanuan

Avoir les éléments suivants dans la solution de contournement config.js au problème:

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

(vide est un fichier empty.js sans contenu)

Un hack similaire est nécessaire pour Browserify

yurydelendik le 22 déc. 2015

Maintenant, problème: pdf.worker.js est chargé deux fois, c'est un problème qui a été résolu par request.ensure () dans webpack. Le './pdf.worker.js' doit être interdit de chargement jusqu'à ce qu'il soit vraiment nécessaire.

yurydelendik le 22 déc. 2015

J'ai pensé "PDFJS.disableWorker = true;" résout ça? N'est-ce pas?

Vanuan le 22 déc. 2015

Si vous utilisez System.import('./pdf.worker') , il n'émettra qu'une seule requête http.

Ou même System.import('pdfjs-dist/build/pdf.worker')

Y a-t-il une raison spécifique pour laquelle node-ensure été utilisé? Je pense que le chargeur système fonctionne bien dans Webpack.

Vanuan le 22 déc. 2015

"PDFJS.disableWorker = true;" n'est pas une option, car nous voulons déplacer le traitement PDF sur le fil différent. Nous ne voulons pas suggérer une solution médiocre aux utilisateurs de la bibliothèque, n'est-ce pas?

yurydelendik le 22 déc. 2015

Eh bien, je préférerais une mauvaise solution à aucune solution du tout. Pour mon cas d'utilisation, même un gel de page d'une seconde est très bien.
Je serais heureux si vous trouvez une meilleure solution.

Vanuan le 22 déc. 2015

Y a-t-il une raison spécifique pour laquelle node-ensure a été utilisé?

Si vous regardez attentivement quels exemples / webpack / produit:

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" est le fichier principal qui se charge (cela signifie qu'il apportera et initialisera l'interface utilisateur après 122796 octets - démarrage de la page plus rapide). "9d074593b165291f150e-worker.js" est un worker qui exécutera la logique et ne verrouille pas l'interface utilisateur sur les appareils lents. La partie "1.bundle.js" est chargée uniquement si disableWorker est déclenché et pour les anciens navigateurs tels que IE9.

yurydelendik le 22 déc. 2015

Je serais heureux si vous trouvez une meilleure solution.

Je m'attends à ce que systemjs ait une sorte de garde pour ne pas analyser tous les besoins (remplacer "./pdf.worker.js" par "vide" ne fonctionnait pas pour moi).

@Vanuan Pouvez-vous

yurydelendik le 22 déc. 2015

Sonne comme le tout dernier problème à systemjs https://github.com/systemjs/systemjs/issues/983 ?

yurydelendik le 22 déc. 2015

Eh bien, je préférerais une mauvaise solution à aucune solution du tout. Pour mon cas d'utilisation, même un gel de page d'une seconde est très bien.

@Vanuan , rien n'a changé dans l'utilisation du fichier pdf.combined.js (j'espère) - on dirait que nous devons le garder pour de tels cas. Vous devez l'utiliser comme vous l'avez décrit comme un problème dans # 6729. D'après votre description, il n'était pas clair que vous prévoyez d'utiliser systemjs pour charger PDFJS.

yurydelendik le 22 déc. 2015

rien n'a changé dans l'utilisation du fichier pdf.combined.js

Ah, super!

Vanuan le 22 déc. 2015

Quoi qu'il en soit, quelque chose a définitivement changé en ce qui concerne son utilisation avec un travailleur.
Auparavant, nous pouvions utiliser le chemin complet vers le worker, mais obtenir Uncaught ReferenceError: require is not defined intérieur:

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

Maintenant, il semble que le chargement de fichiers soit bloqué. Comme si le rappel chargé par module ne se terminait jamais.
Le dernier module demandé est process .

Probablement, Systemjs ne peut pas traiter la construction suivante:

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

Vanuan le 23 déc. 2015

👍1

Quoi qu'il en soit, quelque chose a définitivement changé en ce qui concerne son utilisation avec un travailleur.
Auparavant, nous pouvions utiliser le chemin complet vers le travailleur,

pdf.combined.js est entièrement inclus / inclut pdf.worker.js et n'a pas besoin de spécifier workerSrc.

yurydelendik le 23 déc. 2015

Modifications apportées à pdf.combined.js https://github.com/mozilla/pdfjs-dist/commit/a7cd5f77b00bac19c0f6ee4c2cfd5bbf0fe45d8f#diff -eccf5b94e31b0939738de07167e02af6

yurydelendik le 23 déc. 2015

Oui, je suis juste en train d'évaluer les options d'utilisation des workers avec jspm.

Vanuan le 23 déc. 2015

Maintenant, problème: pdf.worker.js est chargé deux fois, c'est un problème qui a été résolu par request.ensure () dans webpack

Donc, maintenant, il est chargé dans le thread principal et n'utilise pas importScripts ()?

Vanuan le 23 déc. 2015

Mon src / app.js est:

import pdfjs from 'pdfjs-dist';

console.log(PDFJS);

Donc, il n'utilise même pas encore getDocument, mais dans le moniteur réseau, il affiche deux entrées pour pdf.worker.js

yurydelendik le 23 déc. 2015

C'est étrange. Je ne vois qu'une seule entrée.

Vanuan le 23 déc. 2015

C'est étrange. Je ne vois qu'une seule entrée.

Ce ne sera aucun AFAIK :)

yurydelendik le 23 déc. 2015

La même chose sur Firefox et Chrome:
screen shot 2015-12-22 at 5 34 42 pm

yurydelendik le 23 déc. 2015

Ah. On dirait donc que Systemjs analyse tous les require s et essaie de les charger ...

Vanuan le 23 déc. 2015

L'exigence conditionnelle n'est pas un cas d'utilisation très courant.

Vanuan le 23 déc. 2015

C'est pourquoi il essaie également de charger node-ensure.

Vanuan le 23 déc. 2015

@yurydelendik
Comment cela nécessite une aide Webpack? Webpack charge toujours le travailleur en utilisant importScripts, non?

Vanuan le 23 déc. 2015

L'exigence conditionnelle n'est pas un cas d'utilisation très courant.

Je ne suis pas d'accord, https://github.com/systemjs/systemjs/issues/983 et https://github.com/webpack/docs/wiki/code-splitting sont des cas d'utilisation courants.

Webpack charge toujours le travailleur en utilisant importScripts, non?

~~Cela fait.~~ via new Worker(..) . Mais il a également une option pour charger pdf.worker.js en tant que module si les travailleurs sont désactivés.

yurydelendik le 23 déc. 2015

Le problème sera résolu par # 6775 - le systemjs a une détection automatique du type de module. Maintenant c'est commonjs, avec UMD ce sera AMD donc il n'essaiera pas d'analyser require ().

PS wip à https://github.com/yurydelendik/pdf.js/tree/pdfjsumd

yurydelendik le 28 déc. 2015

Wow, super, je vais essayer dès que fusionné et publié.

Vanuan le 28 déc. 2015

Clôture fixée par # 6825. S'il reste des problèmes, veuillez ouvrir un nouveau numéro.