Pdf.js: rendre pdf.js disponible sur un cdn

Créé le 17 nov. 2014  ·  29Commentaires  ·  Source: mozilla/pdf.js

La disponibilité de pdf.js sur un cdn public peut simplifier les flux de travail d'installation et de mise à jour dans certains cas.

cdnjs hébergera probablement pdf.js gratuitement si cela leur était demandé.

https://github.com/cdnjs/cdnjs/issues/3824

picture collinanderson

Commentaire le plus utile

: +1: pour le support cdn. Idéal pour partager des repros de bogues et aussi pour le prototypage rapide

picture luisrudge le 12 août 2015
👍7

Tous les 29 commentaires

Veuillez expliquer quel problème il résoudra. "parce que d'autres projets le font" est une mauvaise raison.

yurydelendik picture yurydelendik le 17 nov. 2014

Bon point. J'ai mis à jour le titre et la description.

collinanderson picture collinanderson le 17 nov. 2014

La bibliothèque pdf.js est installable à partir de npm en utilisant npm install pdfjs-dist , via bower install pdfjs-dist et simplement via git pull du repo pdfjs-dist.

La disponibilité de pdf.js sur un cdn public peut simplifier les flux de travail d'installation et de mise à jour dans certains cas.

Quel cas est discuté ici?

yurydelendik picture yurydelendik le 17 nov. 2014

Dans mon flux de travail, je n'utilise ni npm, ni bowar, ni aucun outil pour la gestion des dépendances frontales et je préfère ne pas fournir de copies d'une bibliothèque.

Je crée plutôt un lien vers une version hébergée sur cdn de jquery, jqueryui, ckeditor ou toute autre bibliothèque javascript dont j'ai besoin. Chaque fois que j'ai besoin de "mettre à jour", je change simplement le numéro de version dans l'url.

collinanderson picture collinanderson le 17 nov. 2014

Je crée plutôt un lien vers une version hébergée sur cdn

Les défauts dans les navigateurs et les stratégies CORS ne permettent pas aux utilisateurs d'instancier le travailleur Web (fichier pdf.worker.js) qui effectue une analyse PDF réelle et améliore considérablement les performances de PDF.js.

Il existe une alternative: désactiver le worker. Mais cela offre des performances inférieures à la normale et nous ne voulons pas en faire la publicité.

yurydelendik picture yurydelendik le 17 nov. 2014

C'est une bonne raison. Ce serait bien de le faire héberger sur CDN si CORS le permet. Merci!

collinanderson picture collinanderson le 17 nov. 2014

Je suis tombé sur cela en essayant d'utiliser PDF.js dans un jsfiddle.
fiddle

nschloe picture nschloe le 23 mars 2015

Oui, surtout lors de l'utilisation d'un outil de prototypage sans vouloir installer un tas de bibliothèques npm localement

joallard picture joallard le 6 avr. 2015

: +1: pour le support cdn. Idéal pour partager des repros de bogues et aussi pour le prototypage rapide

luisrudge picture luisrudge le 12 août 2015
👍7

Pourquoi il n'y a toujours pas de support CDN en novembre 2015?

lony picture lony le 2 nov. 2015
👍5

Pourquoi il n'y a toujours pas de support CDN en novembre 2015?

AFIAK @cdnjs publie PDF.js (par exemple https://github.com/cdnjs/cdnjs/pull/5993)

il ne s'agit pas de l'initiative des contributeurs au référentiel, nous ne sommes donc pas conscients de l'existence de problèmes liés au code publié.

yurydelendik picture yurydelendik le 2 nov. 2015

Pardon alors, c'est peut-être un vice d'ajouter l'URL au Lisez-moi pour éviter d'autres questions?

lony picture lony le 2 nov. 2015

Pardon alors, c'est peut-être un vice d'ajouter l'URL au Lisez-moi pour éviter d'autres questions?

Seulement lorsque nous vérifierons que cela fonctionne sans problèmes ni risques de sécurité. Voir mon inquiétude ci-dessus à https://github.com/mozilla/pdf.js/issues/5490#issuecomment -63322602

yurydelendik picture yurydelendik le 2 nov. 2015

Désolé alors :)

lony picture lony le 2 nov. 2015

Mon cas d'utilisation nécessite une transparence totale. La performance est entièrement subordonnée. C'est pourquoi j'utilise pdf.js car je ne veux rien caché sur un serveur. Tout est fait sur le client, le code est garanti de faire ce qu'il prétend faire.

Mon propre code est petit, facile à lire et ouvert à l'examen. Jamais minifié même en production. Je compte sur du code tiers qui s'exécute sur le client, et la confiance provient des auteurs et de la communauté open source. L'application est open source sur git hub et l'application elle-même est même hébergée sur git hub.

Tant que l'application est conservée de cette façon, ma crédibilité n'est pas importante. Cependant, si j'inclus pdf.js dans la source, même s'il n'est pas construit ou minifié, cela dégrade sérieusement la transparence. L'utilisateur doit avoir confiance en moi que je n'ai pas caché de code malveillant dans la jungle pdf.js.

D'un autre côté, si pdf.js et tous les autres codes tiers ont été récupérés (de préférence non minifiés) à partir d'un cdn approuvé par l'équipe et la communauté, ma propre crédibilité devient presque sans importance.

camitz picture camitz le 30 déc. 2015
👍2

Avec wrapped for the worker (voir # 6753), la bibliothèque principale est "hébergable" sur CDN, par exemple un exemple minimal qui fonctionne bien sur jsfiddle et jsbin:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>Minimal PDF.js example</title>
  <script src="//mozilla.github.io/pdf.js/build/pdf.js"></script>
</head>
<body>
  <script>
    var loadingTask = PDFJS.getDocument('//cdn.mozilla.net/pdfjs/tracemonkey.pdf');
    loadingTask.promise.then(function (pdfDocument)  { 
      console.log('Num pages: ' + pdfDocument.numPages);
    }, function (reason) {
      console.error('Loading Error: ' + reason);
    })
  </script>
</body>
</html>
yurydelendik picture yurydelendik le 8 févr. 2016
🎉1

NPM CDN héberge tous les packages npm sur demande.

https://npmcdn.com/[email protected]/build/pdf.combined.js

Évidemment pas sanctionné par le mainteneur, mais il est là si les gens le veulent à des fins de prototypage.

darylteo picture darylteo le 18 févr. 2016

@yurydelendik Cela fonctionnera certainement pour moi, merci!

@darylteo Merci pour le tuyau. Pas aussi transparent cependant, ce qui serait le point essentiel pour moi.

camitz picture camitz le 18 févr. 2016

https://npmcdn.com/[email protected]/build/pdf.combined.js

@darylteo , l'équipe de PDF.js pense toujours à déprécier pdf.combined.js car il n'est pas prévu d'utiliser la bibliothèque. Essayez de ne pas l'utiliser quand c'est possible (et n'appliquez pas disableWorker = true, ce que pdf.combined.js implique).

yurydelendik picture yurydelendik le 18 févr. 2016

@yurydelendik merci pour l'info! Je construis juste un prototype pour contourner iOS WKWebView qui ne rend pas correctement les PDF dans les iframes pour le moment, mais je garderai cela à l'esprit.

darylteo picture darylteo le 19 févr. 2016

@camitz , je suis curieux. Comment ou pourquoi le code du 8 février de yurydelendik "a-t-il fonctionné pour [vous]"? Je demande parce qu'il fait référence à //mozilla.github.io/pdf.js/build/pdf.js, et je ne considère généralement pas cela comme un cdn. Et, il ne fait pas non plus référence à une copie versionnée de pdf.js

@yurydelendik (ou la personne appropriée) - ce numéro peut-il être rouvert jusqu'à ce que des copies versionnées et minifiées de pdf.js soient définitivement disponibles sur au moins un cdn réputé? Ce problème a commencé avec une référence à cdnjs, et selon leur site Web , ils ont maintenant un moyen préféré de «demander une bibliothèque» via un modèle de problème GitHub pour demander que PDF.js soit ajouté à cdnjs. Un chef de projet PDF.js pourrait-il faire une telle demande? (Je le ferais moi-même mais je ne sais pas si le projet PDF.js voudrait que cdnjs utilise pdf.js ou pdfjs-dist. De plus, il serait probablement préférable que le projet PDF.js lui-même crée une version minifiée de son code qui va à cdnjs.)

Je pense que le cas d'utilisation de camitz qu'il a partagé le 30 décembre est très bon et reste applicable pour beaucoup de gens (y compris moi-même). Comme camitz, je voudrais minimiser la confiance que mes utilisateurs doivent m'accorder, et l'utilisation de copies de bibliothèques qui se trouvent sur un CDN aide certainement à cela.

jon-freed picture jon-freed le 16 avr. 2016

@ jon-libéré Il y a https://npmcdn.com/pdfjs-dist qui est à jour. Pour les cdnjs, il existe la demande d'extraction https://github.com/cdnjs/cdnjs/pull/5993. Je ne pense pas que nous puissions faire plus à ce stade; en particulier, le site Web npmcdn est agréable car il utilise notre package NPM et est donc toujours à jour.

timvandermeij picture timvandermeij le 16 avr. 2016
👍1

@ jon-liberté voici un exemple de jsfiddle qui utilise npmcdn https://jsfiddle.net/y3rsLwwp/5/

yurydelendik picture yurydelendik le 16 avr. 2016
👍1

@timvandermeij , @yurydelendik : Merci pour cette information! Cela aide à clarifier (pour moi, en tout cas) ce que Darylteo a déclaré le 17 février

jon-freed picture jon-freed le 16 avr. 2016

hmmmm ... CDNJS maintenez ici, je vais y travailler maintenant.

PeterDaveHello picture PeterDaveHello le 18 juin 2016

Ok, maintenant ajouté dans: https://github.com/cdnjs/cdnjs/commit/df40a0dd137d5ed1e885354ca8ac492df20bcac0

PeterDaveHello picture PeterDaveHello le 18 juin 2016

Voir: https://cdnjs.com/libraries/pdf.js

PeterDaveHello picture PeterDaveHello le 18 juin 2016

@PeterDaveHello Génial! C'est bien d'avoir PDF.js hébergé sur deux CDN (cdnjs et npmcdn) maintenant.

timvandermeij picture timvandermeij le 18 juin 2016

Pas de problème. Juste pour info, par l'architecture, npmcdn peut se mettre à jour un peu plus rapidement, mais CDNJS aura de meilleures performances pour l'environnement de production, et CDNJS fournit également des fichiers minifiés et des fichiers cartographiques supplémentaires.

PeterDaveHello picture PeterDaveHello le 18 juin 2016
Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

azetutu picture azetutu  ·  4Commentaires
BrennanDuffey picture BrennanDuffey  ·  3Commentaires
timvandermeij picture timvandermeij  ·  4Commentaires
PeterNerlich picture PeterNerlich  ·  3Commentaires
aaronshaf picture aaronshaf  ·  3Commentaires