Pdf.js: disponibilizar pdf.js em um cdn

Criado em 17 nov. 2014  ·  29Comentários  ·  Fonte: mozilla/pdf.js

Ter o pdf.js disponível em um cdn público pode simplificar os fluxos de trabalho de instalação e atualização em alguns casos.

O cdnjs provavelmente hospedará o pdf.js gratuitamente se for solicitado.

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

Comentários muito úteis

: +1: para suporte a cdn. Ótimo para compartilhar repros de bug e também prototipagem rápida

Todos 29 comentários

por favor, explique qual problema ele corrigirá. "porque outros projetos fazem isso" é um mau motivo.

Bom ponto. Eu atualizei o título e a descrição.

A biblioteca pdf.js pode ser instalada a partir do npm usando npm install pdfjs-dist , via bower install pdfjs-dist e simplesmente via git pull do repositório pdfjs-dist.

Ter o pdf.js disponível em um cdn público pode simplificar os fluxos de trabalho de instalação e atualização em alguns casos.

Que caso é discutido aqui?

Em meu fluxo de trabalho, não uso npm ou bowar ou qualquer ferramenta para gerenciamento de dependência de front-end e prefiro não vender cópias de nenhuma biblioteca.

Em vez disso, vinculo a uma versão hospedada em cdn do jquery, jqueryui, ckeditor ou qualquer outra biblioteca javascript de que preciso. Sempre que preciso "atualizar", simplesmente altero o número da versão no url.

Em vez disso, faço um link para uma versão hospedada em cdn

Defeitos em navegadores e políticas CORS não permitem que os usuários instanciem o web worker (arquivo pdf.worker.js) que realiza a análise real de PDF e melhora significativamente o desempenho do PDF.js.

Existe uma alternativa: desabilite o trabalhador. Mas isso oferece um desempenho abaixo da média e não queremos anunciar isso.

Essa é uma boa razão. Seria bom hospedá-lo no CDN se o CORS permitir. Obrigado!

Eu tropecei nisso ao tentar usar PDF.js em um jsfiddle.
fiddle

Sim, principalmente ao usar uma ferramenta de prototipagem sem querer instalar um monte de bibliotecas npm localmente

: +1: para suporte a cdn. Ótimo para compartilhar repros de bug e também prototipagem rápida

Por que ainda não havia suporte para CDN em novembro de 2015?

Por que ainda não havia suporte para CDN em novembro de 2015?

AFIAK @cdnjs está publicando PDF.js (por exemplo, https://github.com/cdnjs/cdnjs/pull/5993)

não é esta iniciativa dos contribuidores do repositório, portanto, não estamos cientes se há algum problema presente em relação ao código publicado.

Desculpe, talvez seja o vício adicionar o URL ao arquivo Leiame para evitar mais perguntas.

Desculpe, talvez seja o vício adicionar o URL ao arquivo Leiame para evitar mais perguntas.

Somente quando verificaremos se funciona sem problemas ou riscos de segurança. Veja minha preocupação acima em https://github.com/mozilla/pdf.js/issues/5490#issuecomment -63322602

Desculpa, então :)

Meu caso de uso requer transparência total. O desempenho é totalmente subordinado. É por isso que uso o pdf.js porque não quero nada escondido em um servidor. Tudo é feito no cliente, o código tem a garantia de fazer o que afirma fazer.

Meu próprio código é pequeno, fácil de ler e abrir para análise. Nunca minimizado, mesmo em produção. Eu confio no código de terceiros que é executado no cliente, e a confiança vem dos autores e da comunidade de código aberto. O aplicativo é de código aberto no git hub e o próprio aplicativo está até hospedado no git hub.

Enquanto o aplicativo for mantido assim, minha credibilidade não é importante. No entanto, se eu incluir pdf.js no código-fonte, mesmo que não seja compilado ou minimizado, isso degrada seriamente a transparência. O usuário precisa ter fé em mim que não escondi código malicioso na selva do pdf.js.

Por outro lado, se o pdf.js e todos os outros códigos de terceiros forem obtidos (de preferência não minimizados) de um cdn endossado pela equipe e pela comunidade, minha própria credibilidade se torna quase irrelevante.

Com empacotado para o trabalhador (consulte # 6753), a biblioteca central é "hospedável" no CDN, por exemplo, exemplo mínimo que funciona bem no jsfiddle e 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>

O NPM CDN hospeda todos os pacotes npm mediante solicitação.

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

Obviamente, não foi sancionado pelo mantenedor, mas está lá se as pessoas quiserem para fins de prototipagem.

@yurydelendik Isso definitivamente funcionará para mim, obrigado!

@darylteo Obrigado pela dica. Não tão transparente, que é o que seria o ponto principal para mim.

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

@darylteo , a equipe do PDF.js está sempre pensando em descontinuar o pdf.combined.js, uma vez que não é o uso pretendido da biblioteca. Tente não usá-lo quando possível (e também não aplique disableWorker = true, o que o pdf.combined.js implica).

@yurydelendik obrigado pela informação! Estou apenas construindo um protótipo para contornar o iOS WKWebView, não renderizando PDFs corretamente em iframes por enquanto, mas vou manter isso em mente.

@camitz , estou curioso. Como ou por que o código de 8 de fevereiro de yurydelendik "funcionou para [você]"? Estou perguntando porque faz referência a //mozilla.github.io/pdf.js/build/pdf.js, e eu geralmente não veria isso como um cdn. E também não está fazendo referência a uma cópia versionada do pdf.js

@yurydelendik (ou quem quer que seja apropriado) - este problema pode ser reaberto até que cópias versionadas e reduzidas do pdf.js estejam definitivamente disponíveis em pelo menos um cdn confiável? Esse problema começou com uma referência a cdnjs e, de acordo com seu site , agora eles têm uma maneira preferencial de "Solicitar uma lib" por meio de um modelo de problema do GitHub para solicitar que PDF.js seja adicionado ao cdnjs. Um líder de projeto PDF.js poderia fazer esse pedido? (Eu faria isso sozinho, mas não sei se o projeto PDF.js gostaria que o cdnjs usasse pdf.js ou pdfjs-dist. Além disso, provavelmente seria melhor se o próprio projeto PDF.js criasse uma versão reduzida de seu código vai para cdnjs.)

Eu acho que o caso de uso de camitz que ele compartilhou em 30 de dezembro é muito bom e ainda aplicável para muitas pessoas (incluindo eu). Como camitz, eu gostaria de minimizar a quantidade de confiança que meus usuários têm em mim, e usar cópias de bibliotecas que estão em um CDN definitivamente ajuda com isso.

@ jon-freed Existe https://npmcdn.com/pdfjs-dist que está atualizado. Para cdnjs, há a solicitação de pull https://github.com/cdnjs/cdnjs/pull/5993. Não acho que haja mais que possamos fazer neste momento; especialmente o site npmcdn é bom porque usa nosso pacote NPM e, portanto, está sempre atualizado.

@ jon-freed aqui é um exemplo de jsfiddle que usa npmcdn https://jsfiddle.net/y3rsLwwp/5/

@timvandermeij , @yurydelendik : Obrigado por essa informação! Isso ajuda a esclarecer (para mim, de qualquer maneira) o que darylteo declarou em 17 de fevereiro

hmmmm ... CDNJS mantenha aqui, vou trabalhar nisso agora.

@PeterDaveHello Awesome! É bom ter PDF.js hospedado em dois CDNs (cdnjs e npmcdn) agora.

Sem probs. Apenas para sua informação, pela arquitetura, o npmcdn pode atualizar um pouco mais rápido, mas o CDNJS terá melhor desempenho para o ambiente de produção, e o CDNJS também fornece arquivos minimizados e arquivos de mapa adicionais.

Esta página foi útil?
0 / 5 - 0 avaliações