Наличие pdf.js на общедоступном компакт-диске может упростить в некоторых случаях рабочие процессы установки и обновления.
cdnjs, скорее всего, будет размещать pdf.js бесплатно, если их попросят.
объясните, пожалуйста, какую проблему это исправит. «потому что это делают другие проекты» - плохая причина.
Хорошая точка зрения. Я обновил заголовок и описание.
Библиотека pdf.js устанавливается из npm с использованием npm install pdfjs-dist
, через bower install pdfjs-dist
и просто через git pull из репозитория pdfjs-dist.
Наличие pdf.js на общедоступном компакт-диске может упростить в некоторых случаях рабочие процессы установки и обновления.
Какой случай здесь обсуждается?
В своем рабочем процессе я не использую npm, bowar или какой-либо другой инструмент для управления зависимостями внешнего интерфейса и предпочитаю не продавать копии какой-либо библиотеки.
Вместо этого я ссылаюсь на версию jquery, jqueryui, ckeditor, размещенную на cdn, или любую другую библиотеку javascript, которая мне нужна. Когда мне нужно «обновить», я просто меняю номер версии в URL-адресе.
Вместо этого я ссылаюсь на версию, размещенную на cdn
Дефекты в браузерах и политиках CORS не позволяют пользователям создавать экземпляры веб-воркера (файл pdf.worker.js), который выполняет фактический синтаксический анализ PDF и значительно повышает производительность PDF.js.
Есть альтернатива: отключить воркер. Но это обеспечивает низкую производительность, и мы не хотим афишировать это.
Это хорошая причина. Было бы неплохо разместить его на CDN, если CORS когда-нибудь позволит это. Благодаря!
Я наткнулся на это, когда пытался использовать PDF.js в jsfiddle.
Да, в основном при использовании инструмента для создания прототипов без необходимости устанавливать кучу библиотек npm локально
: +1: за поддержку cdn. Отлично подходит для обмена репортажами об ошибках, а также для быстрого создания прототипов
Почему по состоянию на ноябрь 2015 года все еще нет поддержки CDN?
Почему по состоянию на ноябрь 2015 года все еще нет поддержки CDN?
AFIAK @cdnjs публикует PDF.js (например, https://github.com/cdnjs/cdnjs/pull/5993)
это не инициатива участников репозитория, поэтому мы не знаем, есть ли какие-либо проблемы в связи с опубликованным кодом.
Извините, может быть, неправильно добавлять URL-адрес в ReadMe, чтобы избежать дальнейших вопросов?
Извините, может быть, неправильно добавлять URL-адрес в ReadMe, чтобы избежать дальнейших вопросов?
Только когда мы убедимся, что он работает без проблем или угроз безопасности. См. Мою озабоченность выше на https://github.com/mozilla/pdf.js/issues/5490#issuecomment -63322602
Тогда извини :)
Мой вариант использования требует полной прозрачности. Производительность полностью подчинена. Вот почему я использую pdf.js, потому что мне не нужно ничего скрывать на сервере. Все делается на клиенте, код гарантированно выполняет то, что утверждает.
Мой собственный код небольшой, легко читаемый и открытый для изучения. Никогда не минифицировался даже в производстве. Я полагаюсь на сторонний код, который работает на клиенте, и доверие исходит от авторов и сообщества открытого исходного кода. Приложение имеет открытый исходный код на git hub, а само приложение даже размещено на git hub.
Пока приложение хранится в таком виде, мое доверие не имеет значения. Однако, если я включу pdf.js в исходный код, даже если он не создан или не уменьшен, это серьезно ухудшит прозрачность. Пользователь должен верить в то, что я не спрятал вредоносный код в джунглях pdf.js.
С другой стороны, если pdf.js и весь другой сторонний код были извлечены (желательно без минификации) с компакт-диска, одобренного командой и сообществом, мое собственное доверие становится почти несущественным.
С оберткой для рабочего (см. # 6753), основная библиотека "размещается" на CDN, например, минимальный пример, который отлично работает с jsfiddle и 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>
NPM CDN размещает все пакеты npm по запросу.
https://npmcdn.com/[email protected]/build/pdf.combined.js
Очевидно, что сопровождающий не санкционирован, но он есть, если люди хотят его для целей прототипирования.
@yurydelendik Это определенно сработает для меня, спасибо!
@darylteo Спасибо за подсказку. Но не так прозрачно, и в этом для меня весь смысл.
@darylteo , команда PDF.js всегда думает об отказе от поддержки pdf.combined.js, поскольку он не предназначен для использования библиотеки. Пожалуйста, постарайтесь не использовать его, когда это возможно (а также не применяйте disableWorker = true, что подразумевает pdf.combined.js).
@yurydelendik спасибо за информацию! Я просто создаю прототип для обходного пути iOS WKWebView, который пока не отображает файлы PDF должным образом в iframe, но буду иметь это в виду.
@camitz , мне любопытно. Как и почему код юриделендика от 8 февраля «работал на [вас]»? Я спрашиваю, потому что он ссылается на //mozilla.github.io/pdf.js/build/pdf.js, и я бы обычно не рассматривал это как cdn. И он также не ссылается на версионную копию pdf.js
@yurydelendik (или кто-то веб-сайту , теперь у них есть предпочтительный способ «Запросить библиотеку» через шаблон выпуска GitHub для запроса добавления PDF.js в cdnjs. Не мог бы руководитель проекта PDF.js сделать такой запрос? (Я бы сделал это сам, но я не знаю, хочет ли проект PDF.js, чтобы cdnjs использовал pdf.js или pdfjs-dist. Кроме того, вероятно, было бы лучше, если бы сам проект PDF.js создал миниатюрную версию его код, который идет на cdnjs.)
Я думаю, что вариант использования Камица, которым он поделился 30 декабря, очень хорош и все еще применим для многих людей (включая меня). Как и camitz, я хотел бы свести к минимуму количество доверия, которое мои пользователи должны мне доверять, и использование копий библиотек, находящихся в CDN, определенно помогает в этом.
@ jon-freed Существует https://npmcdn.com/pdfjs-dist с последними обновлениями. Для cdnjs есть запрос на перенос https://github.com/cdnjs/cdnjs/pull/5993. Я не думаю, что мы можем сделать что-то еще; особенно хорош веб-сайт npmcdn, потому что он использует наш пакет NPM и поэтому всегда обновлен.
@ jon-freed - это пример jsfiddle, который использует npmcdn https://jsfiddle.net/y3rsLwwp/5/
@timvandermeij , @yurydelendik : Спасибо за информацию! Это помогает прояснить (мне, во всяком случае), что Дэрилтео заявил 17 февраля.
хмммм ... CDNJS поддерживаю здесь, я сейчас над этим поработаю.
Хорошо, теперь добавлено: https://github.com/cdnjs/cdnjs/commit/df40a0dd137d5ed1e885354ca8ac492df20bcac0
@PeterDaveHello Классно ! Хорошо, что сейчас PDF.js размещен на двух CDN (cdnjs и npmcdn).
Нет проблем. К вашему сведению, по архитектуре npmcdn может обновляться немного быстрее, но CDNJS будет иметь лучшую производительность для производственной среды, а CDNJS также предоставляет уменьшенные файлы и дополнительные файлы карт.
Самый полезный комментарий
: +1: за поддержку cdn. Отлично подходит для обмена репортажами об ошибках, а также для быстрого создания прототипов