PDFKit: возможности, ограничения и практическое применение в Node.js и браузере

PDFKit — не настольный PDF-редактор и не просмотрщик, а библиотека JavaScript, которая формирует PDF программно в Node.js и браузере. На 12 сентября 2026 года актуален пакет PDFKit 0.20.2 из репозитория FolioJS. Он подходит для серверной генерации счетов, актов, отчётов, билетов и других документов, а также для клиентских сценариев, где PDF строится непосредственно в веб-приложении. Важная граница продукта: библиотека создаёт новый PDF из текста, изображений, шрифтов, таблиц и графических команд, но не предназначена для открытия и редактирования произвольного существующего PDF как документа-источника.

Скачать PDFKit

Безопасный основной путь получения — официальный пакет pdfkit из npm либо исходный код и релизы репозитория foliojs/pdfkit. На дату обзора npm публикует версию 0.20.2 под лицензией MIT. Для обычного проекта установка выполняется менеджером пакетов: npm install pdfkit. В документации также сохраняется вариант с Yarn, но отдельного EXE, DMG, MSI или графического установщика у JavaScript-библиотеки нет.

Выбирать следует именно пакет с именем pdfkit, связанный с FolioJS. Название неоднозначно. Apple PDFKit — системный framework для отображения и работы с PDF в приложениях Apple, включая классы PDFView и PDFDocument; это другой продукт. Существует и Ruby-gem PDFKit из репозитория pdfkit/pdfkit, который превращает HTML и CSS в PDF через wkhtmltopdf; он также не относится к рассматриваемой библиотеке. Для JavaScript-продукта контрольными признаками служат описание «A JavaScript PDF generation library», репозиторий foliojs/pdfkit и пакет npm pdfkit.

Загружать случайные сборки с сайтов-агрегаторов не требуется. У PDFKit нет «Pro», «Desktop» или «Online» редакции, которую нужно искать отдельно. Релизные assets на GitHub полезны разработчикам, однако для проекта с зависимостями практичнее закреплять нужную версию в package.json и получать её через используемый реестр пакетов.

Что такое PDFKit

PDFKit создаёт PDF через программные вызовы. Разработчик формирует объект PDFDocument, добавляет страницы и содержимое, а затем завершает документ. В Node.js объект работает как читаемый поток: результат можно направить в файл, HTTP-ответ или другой совместимый поток. В браузере версия 0.20.x использует собственную минимальную реализацию нужных потоковых операций и может выдавать чанки Uint8Array; дополнительно доступны экспериментальные помощники преобразования в Blob и единый Uint8Array.

У проекта нет модели «открыть файл — внести правки — сохранить». Его сильная сторона — детерминированное построение нового документа из данных приложения. Поэтому PDFKit хорошо вписывается в бэкенд, отчётный сервис, биллинговую систему, генератор сертификатов или веб-форму, где контент известен заранее. Для ручной правки чужого PDF логичнее использовать полноценный редактор, например Adobe Acrobat Pro или иной редактор с функциями импорта существующей структуры.

Хронология развития и поддержки

Версия 0.17.0 добавила встроенную генерацию таблиц и ряд улучшений текстовой раскладки. В 0.18.0 исправлялись копирование текста в PDFium-браузерах, доступность ссылок и таблиц, обработка PNG и SVG-путей, а также появились настройки pageLayout и userUnit. В 0.19.0 минимальная версия Node.js была поднята до 20, для браузеров зафиксированы более современные базовые уровни, включая Firefox 115 и Safari/iOS 16; одновременно добавилась прозрачность для изображений и дорабатывалась PDF/UA-структура.

Ветка 0.20.0 стала архитектурным изменением. Метрики стандартных PDF-шрифтов больше не разбираются из AFM во время выполнения: они поставляются как подготовленные модули. В Node.js загрузка метрик остаётся ленивой, а в обычной браузерной ESM-сборке разработчик импортирует нужные стандартные шрифты из pdfkit/standard-fonts и регистрирует их до создания документа. Авторы также убрали внутреннюю зависимость от Buffer, используя Uint8Array как общий бинарный тип, и разделили реализации fs, zlib и потоков по средам.

0.20.1 добавила отдельную ESM-сборку для Node.js, чтобы import из pdfkit выбирал нативную Node-реализацию с файловой системой, zlib и потоками, а не браузерный вариант. 0.20.2 исправила проблемы упаковки стандартных шрифтов некоторыми bundler/file-tracer инструментами, повторное вложение одного in-memory файла под тем же именем и ошибку вычисления ширины при lineBreak: false в сочетании с рядом текстовых опций. Для нового проекта разумно ориентироваться именно на 0.20.2 и текущую документацию, а не переносить конфигурацию более старой ветки без проверки.

Основные функции PDFKit

Текст и многостраничная раскладка

Метод text добавляет строки в текущую позицию документа, а движок отслеживает координаты X и Y. При включённом переносе текст автоматически укладывается в доступную ширину и при необходимости переходит на новые страницы. Доступны выравнивание влево, по центру, вправо и по ширине, несколько колонок, межстрочные и межсимвольные интервалы, отступы абзацев, ограничение высоты, многосегментное форматирование через continued, подчёркивание, зачёркивание, наклон и поворот текста.

Шрифты и Unicode

PDFKit знает 14 стандартных шрифтов PDF и умеет встраивать TrueType, OpenType, WOFF, WOFF2, TrueType Collection и Datafork TrueType. Для собственных шрифтов библиотека использует fontkit и выполняет подмножество шрифта, чтобы не включать в итоговый PDF ненужные глифы. Для русского текста и других алфавитов практичнее подключать подходящий встраиваемый Unicode-шрифт, а не рассчитывать на стандартные Helvetica, Times или Courier.

В браузере 0.20.x есть отдельная особенность: стандартные метрики не входят в основной ESM-модуль автоматически. Если приложение создаёт документ с Helvetica по умолчанию, соответствующий модуль стандартного шрифта нужно импортировать и зарегистрировать заранее либо создать документ без шрифта по умолчанию и явно подключить собственный шрифт. Standalone-сборка включает стандартные шрифты, но основной модуль сделан компактнее и модульнее.

Изображения и векторная графика

Растровый импорт ограничен JPEG и PNG, включая PNG с прозрачностью. Источник можно передать как путь в Node.js, бинарные данные или data URI. Есть масштабирование по ширине и высоте, fit и cover, выравнивание внутри заданного прямоугольника, учёт EXIF-ориентации JPEG и управление общей прозрачностью изображения.

Векторный API напоминает Canvas: линии, кривые, прямоугольники, окружности, контуры, трансформации, заливка и обводка, линейные и радиальные градиенты. PDFKit также разбирает SVG path-синтаксис. Это не означает импорт полноценного SVG-файла с его DOM, CSS и фильтрами: штатно речь идёт именно о строках пути и графических примитивах PDFKit.

Таблицы, формы и интерактивные элементы

Современный PDFKit включает таблицы с настройкой ширины колонок и оформлением ячеек. Для структурированных отчётов это снижает объём собственного кода по сравнению с ручным вычислением каждой строки. Есть AcroForm-поля, включая текстовые поля, списки, combo-box и кнопки. Аннотации охватывают ссылки, заметки, подсветку, подчёркивание, зачёркивание, линии, прямоугольники, эллипсы и файловые аннотации.

Закладки документа строятся через outline, а именованные destinations позволяют создавать внутреннюю навигацию с переходом к странице, позиции и масштабу. В PDF можно вкладывать внешние файлы с именем, MIME-типом и описанием. Для отчётной системы это полезно, если вместе с визуальным документом требуется передать исходные данные или сопроводительный файл.

Метаданные, безопасность, PDF/A и доступность

PDFKit позволяет задавать Title, Author, Subject, Keywords и даты. Шифрование включается через пароли пользователя и владельца, а права могут ограничивать печать, копирование, изменение, аннотирование, заполнение форм и сборку документа. В документации отдельно подчёркнуто, что сами permission-флаги не способны технически заставить любой PDF-просмотрщик соблюдать ограничения после расшифровки.

Поддерживаются варианты шифрования, зависящие от версии PDF: от RC4 для старых версий до AES, включая 256-битный режим для PDF 1.7 ExtensionLevel 3. Для долгосрочного хранения документация заявляет цель поддержки профилей PDF/A-1, PDF/A-2 и PDF/A-3 уровней A и B. При этом PDF/A запрещает шифрование и требует встроенных шрифтов, поэтому стандартные AFM-шрифты не подходят для соответствующего архивного файла; результат следует проверять независимым валидатором.

Для доступности есть tagged PDF, логическая структура и PDF/UA-настройки. Библиотека предоставляет механизмы, но соответствие не возникает автоматически: разработчик должен задать структуру чтения, язык, заголовок, альтернативный текст и корректно помечать значимое и декоративное содержимое. Это особенно важно для документов, которые должны проходить формальную проверку доступности.

Интерфейс и удобство использования

У PDFKit нет окон, панелей инструментов или локализованного интерфейса. Его «рабочая зона» — код приложения и API PDFDocument. Для разработчика, который уже знаком с Node.js и JavaScript, модель достаточно прямолинейна: создать документ, настроить страницу, последовательно добавить контент, направить поток или собрать бинарный результат, затем вызвать end. Цепочки методов позволяют компактно описывать графику и форматирование.

Официальный сайт содержит документацию по отдельным подсистемам и интерактивную браузерную демонстрацию, где рядом с кодом можно видеть итоговый PDF. Это полезно для освоения, но demo не превращает библиотеку в конечный редактор: пользовательское приложение всё равно должно предоставить собственные поля, шаблоны, предпросмотр, кнопки сохранения и обработку ошибок.

Поддерживаемые форматы и совместимость

В Node.js 0.20.2 CommonJS и ESM направляются в Node-сборки с доступом к реальной файловой системе, нативному zlib и Node streams. Браузерная сборка не читает локальный путь напрямую. Если код хочет сохранить привычное имя пути для font, image или file, двоичные данные сначала регистрируются через registerFile; альтернативно их можно передавать непосредственно как Uint8Array или ArrayBuffer.

Это различие критично для переносимости. Серверный шаблон, который делает doc.image(‘/srv/logo.png’), нельзя механически перенести в браузер: веб-приложению нужно получить ресурс через import, fetch, File API или другой разрешённый механизм и передать байты. Обратная сторона — библиотека не требует собственного облака: где находятся данные и куда отправляется готовый PDF, решает код приложения.

Sumatra PDF находится на другом конце процесса. Он предназначен для открытия и чтения уже готовых PDF и других документов, тогда как PDFKit формирует PDF. Поэтому они не взаимоисключающие конкуренты: файл, сгенерированный PDFKit, можно затем проверять в Sumatra PDF как в лёгком Windows-просмотрщике. Если вместо генерации из кода требуется виртуальная печать из готового приложения, уместнее смотреть на doPDF или подобный драйвер печати.

Производительность и стабильность

Официальные материалы не дают универсального бенчмарка по страницам в секунду, поэтому корректно оценивать архитектурные свойства. В Node.js PDFDocument выдаёт данные потоком по мере генерации. Это позволяет направлять результат в файл или HTTP-ответ без обязательной сборки всего документа в один большой буфер. Если же включён bufferPages для последующего возврата к уже созданным страницам, например ради сквозной нумерации, страницы остаются в памяти до flushPages или end, и расход памяти растёт вместе с документом.

Шрифтовое подмножество уменьшает избыточные данные в итоговом файле. В 0.20.0 была переработана доставка стандартных шрифтов: Node.js загружает их метрики лениво, а обычная браузерная ESM-сборка позволяет импортировать и регистрировать только нужные модули. Это снижает необходимость тащить в модульную браузерную сборку данные неиспользуемых стандартных шрифтов, но само по себе не гарантирует конкретное время построения PDF.

Стабильность ветки 0.20.x стоит оценивать с учётом её новизны. Релизы 0.20.1 и 0.20.2 последовали вскоре после 0.20.0 и устраняли реальные проблемы с выбором Node ESM-сборки, упаковкой стандартных шрифтов, повторными вложениями и отдельными текстовыми комбинациями. Для продакшена разумно фиксировать точную версию, прогонять собственный набор документов после обновления и отдельно проверять сложные шрифты, формы, вложения и PDF/A/PDF/UA-выход.

Карта критических зависимостей

Аккаунт PDFKit, лицензирующий сервер и обязательный SaaS в эту карту не входят. MIT-библиотека может работать внутри полностью локального Node-приложения. Если веб-система отправляет исходные данные на удалённый backend, это уже свойство архитектуры конкретного сервиса, а не требование PDFKit. Такое разделение важно для приватности: утверждать, что «PDFKit загружает документы в облако», некорректно; равно как нельзя обещать локальность чужого приложения только потому, что оно использует PDFKit.

Лицензирование и версии

PDFKit распространяется по лицензии MIT. Исходный код можно использовать, изменять, распространять и включать в коммерческие продукты при сохранении требуемого уведомления об авторских правах и текста лицензии. У проекта нет отдельной платной редакции, ограниченного бесплатного тарифа, пробного периода, водяных знаков или лимита числа создаваемых документов.

Версии npm следуют обычной схеме нумерации пакета, однако проект всё ещё находится в диапазоне 0.x. Фиксация версии особенно разумна после крупного перехода 0.20.0, где появились breaking changes в браузерных стандартных шрифтах, виртуальной файловой системе, ряде AcroForm и annotation-настроек. Автоматическое обновление без регрессионных PDF-тестов в таком проекте неоправданно.

Системные требования

Node.js

В package.json PDFKit 0.20.2 указано требование Node.js 20.0.0 или новее. Библиотека не привязана к Windows, macOS или Linux как настольная программа: практическая совместимость определяется тем, доступен ли поддерживаемый Node.js и работают ли зависимости проекта в целевой среде. Для Node предусмотрены CommonJS и ESM-входы; начиная с 0.20.1 импорт через ESM направляется в отдельную Node-сборку.

Браузер

Начиная с 0.19.0 авторы подняли минимальные браузерные уровни, отдельно указав Firefox 115 и Safari/iOS 16. Для других браузеров в публичных release notes нет столь же удобной единой цифры, поэтому правильнее ориентироваться на современные поддерживаемые движки и проверять конкретную целевую матрицу приложения. Браузерная сборка не имеет прямого доступа к файловой системе Node и использует собственную ограниченную потоковую реализацию.

Среда разработки

Для установки из npm нужен сам пакетный менеджер и рабочий JavaScript-проект. TypeScript-определения существуют как отдельный пакет сообщества @types/pdfkit, но он не является частью основного пакета PDFKit. Для базового JavaScript-сценария отдельная IDE, Java, .NET, Python или база данных не требуются.

Преимущества и недостатки PDFKit

Плюсы и минусы

• Открытая MIT-лицензия. Нет подписки, активации, серверной лицензии или искусственного лимита на количество документов.

• Один API для Node.js и браузера. Основные операции генерации совпадают, а 0.20.x уменьшает зависимость браузерной сборки от Node-специфичных сущностей.

• Сильная программная графика. Есть Canvas-подобные векторные команды, SVG path, градиенты, трансформации и точное позиционирование.

• Практичная текстовая модель. Автоперенос, многостраничность, колонки, списки, измерение текста, OpenType и встраивание широкого набора шрифтов.

• Документные функции выше базового рисования. Таблицы, аннотации, закладки, AcroForms, вложения, шифрование, права, tagged PDF и средства PDF/UA.

• Потоковый вывод в Node.js. Можно передавать PDF в файл или HTTP-ответ без обязательной сборки всего результата в единый буфер.

Минусы

• Не редактирует существующий PDF. Нет штатного парсера страниц и объектов для сценария «загрузить — изменить — сохранить».

• Нет визуального редактора. Верстка, валидация данных, шаблоны, предпросмотр и пользовательский интерфейс реализуются самим приложением.

• Растровый импорт узкий. Нативно заявлены JPEG и PNG; TIFF, WebP и другие типы нужно преобразовывать до передачи.

• HTML/CSS не является входным форматом верстки. Перенос существующего веб-шаблона потребует другой библиотеки или отдельной прослойки.

• Браузер 0.20.x требует внимательности со шрифтами. Стандартные шрифты в модульной сборке импортируются и регистрируются явно.

• Формальное соответствие нужно проверять отдельно. Наличие API для PDF/A и PDF/UA не освобождает от валидации итогового файла и корректного построения структуры.

Паспорт обратимости операций

Генерация в PDFKit по сути односторонняя относительно исходной модели. Если приложение построило PDF из базы данных или JSON и затем отбросило исходные данные, библиотека не предоставляет симметричный способ восстановить эту структуру из получившегося файла. Поэтому главным «форматом для возврата» должен считаться не PDF, а исходная бизнес-модель, шаблон и используемые ресурсы.

Сравнение с аналогами

pdfmake строит документ декларативно: разработчик описывает абзацы, колонки, списки, таблицы и стили, а движок рассчитывает раскладку. Проект прямо основан на PDFKit, но предлагает более высокий уровень абстракции. Если основная боль — ручная геометрия отчёта, pdfmake часто удобнее; если нужен непосредственный доступ к PDFKit-графике и низкоуровневому контролю, исходная библиотека гибче.

pdf-lib принципиально отличается возможностью загружать и изменять существующие PDF: добавлять, удалять и копировать страницы, рисовать поверх, работать с формами и вложениями. Это важнее любой косметической разницы API. Для шаблона, который уже существует как PDF и должен заполняться или модифицироваться, pdf-lib естественнее PDFKit.

Sumatra PDF сравним только по месту в рабочем процессе. Он не заменяет PDFKit в коде, а PDFKit не заменяет Sumatra как пользовательский просмотрщик. Для контроля готового результата удобно держать оба класса инструментов: генератор создаёт файл, просмотрщик показывает то, что получит конечный пользователь. Если нужен Windows-инструмент с более широкими функциями правки и аннотирования, можно сравнить с PDF-XChange Editor; это уже совсем другой продуктовый класс.

Инструкция по установке

Node.js: установка и первый документ

1. Установите поддерживаемую среду Node.js 20 или новее и создайте обычный JavaScript-проект.

2. В каталоге проекта выполните npm install pdfkit. Пакет и его зависимости будут записаны в проект согласно настройкам npm.

3. В новом коде предпочтительнее использовать именованный экспорт PDFDocument. CommonJS require и ESM import поддерживаются, а старый default-стиль сохранён ради совместимости.

4. Создайте PDFDocument, направьте его в файловый или HTTP-поток, добавьте содержимое и завершите документ методом end.

5. Откройте полученный файл минимум в одном независимом просмотрщике. Для пользовательского контроля подойдёт Sumatra PDF; для формальной задачи PDF/A или PDF/UA нужен соответствующий валидатор, а не только визуальный просмотр.

«Первого запуска» как у настольной программы нет: успешным запуском считается выполнение вашего JavaScript-кода и корректное завершение PDF-потока. Если пакет больше не нужен, его удаляют из зависимостей проекта через менеджер пакетов; важно также убрать собственный код, шаблоны и ресурсы, которые от него зависят.

Браузерная сборка 0.20.x

1. Добавьте pdfkit в проект через npm и настройте современную сборку фронтенда.

2. Импортируйте PDFDocument из pdfkit. Если используются стандартные PDF-шрифты, импортируйте нужные модули из pdfkit/standard-fonts и зарегистрируйте их до создания документа.

3. Для собственных шрифтов, изображений и вложений передавайте Uint8Array, ArrayBuffer или подходящий data URL. Если код ожидает путь, сначала зарегистрируйте байты под этим путём через registerFile.

4. Соберите результат через события потока либо используйте экспериментальный toBlob/toBytes, понимая, что их API ещё может измениться.

5. Создайте Object URL для Blob только на время предпросмотра или скачивания и освобождайте его после использования. Это уже браузерная гигиена приложения, а не автоматическая функция PDFKit.

Параметры, которые важно настроить сразу

До серьёзной генерации определите размер страницы и поля, набор шрифтов, PDF version, требования к шифрованию, правила метаданных и необходимость bufferPages. Если нужен PDF/A, заранее исключите несовместимые функции вроде шифрования и подключите встраиваемый шрифт. Если нужен PDF/UA, структуру доступности следует проектировать вместе с шаблоном, а не добавлять в самом конце.

Практические кейсы

Серверный счёт или акт из бизнес-данных

Цель. Выдать клиенту PDF из данных заказа. Подготовка. Стабилизировать модель данных, подключить шрифт с кириллицей, подготовить логотип в JPEG/PNG и решить, нужны ли подписи или вложения. Шаги. Создать PDFDocument, вывести реквизиты, сформировать таблицу позиций, посчитать итог, завершить документ и направить поток в HTTP-ответ. Проверка. Сверить суммы с источником данных, открыть файл в независимом просмотрщике, проверить копирование русского текста и печать. Ограничение. Если бухгалтер вручную должен править уже выпущенный PDF, PDFKit сам эту задачу не закрывает.

Браузерный сертификат без обязательной отправки данных на сервер

Цель. Сформировать персональный сертификат непосредственно в браузере. Подготовка. Включить в приложение нужный шрифт и фоновое PNG/JPEG-изображение, зарегистрировать стандартный шрифт при его использовании. Шаги. Создать документ, отрисовать фон и текст, получить Blob, показать его во встроенном просмотрщике или предложить сохранить. Проверка. Сравнить данные сертификата с формой до генерации и открыть Blob как PDF. Ограничение. «Локальность» сохраняется только пока само приложение не отправляет введённые данные или готовый Blob на удалённый сервер.

Многостраничный отчёт с итоговой нумерацией

Цель. Вывести отчёт, где в колонтитуле нужен формат «страница N из M». Подготовка. Оценить максимальный размер отчёта и доступную память. Шаги. Включить bufferPages, сформировать все разделы, получить диапазон буферизованных страниц, пройти по ним через switchToPage и добавить номера, затем завершить документ. Проверка. Убедиться, что нумерация совпадает с реальным числом страниц и не перекрывает содержимое. Ограничение. Буферизация удерживает страницы и потому хуже подходит для очень больших документов, чем чистый поток.

Архивный PDF/A

Цель. Подготовить документ для долгосрочного хранения. Подготовка. Выбрать конкретный профиль PDF/A, встраиваемый шрифт, корректные метаданные и допустимые цветовые пространства. Шаги. Создать PDFDocument с нужным subset и версией PDF, не включать шифрование, использовать встроенные шрифты и сформировать документ. Проверка. Прогнать итог независимым PDF/A-валидатором и сохранять отчёт проверки вместе с процедурой выпуска. Ограничение. Наличие настройки subset не является заменой валидации.

Интерактивная анкета

Цель. Создать PDF с полями для дальнейшего заполнения. Подготовка. Определить имена и типы полей, шрифт, ограничения на ввод и целевые просмотрщики. Шаги. Разместить подписи и AcroForm-поля, добавить варианты выбора и кнопки, завершить документ. Проверка. Открыть файл как минимум в тех PDF-приложениях, где его будут заполнять, и проверить ввод, сохранение и печать. Ограничение. Поддержка поведения интерактивных форм может различаться между просмотрщиками, поэтому тестировать только в браузере недостаточно.

Контроль перед сохранением и передачей

• Проверить имя, дату, суммы, номера документов и другие данные, которые нельзя восстановить из PDFKit автоматически.

• Убедиться, что все символы отображаются выбранным встроенным шрифтом и текст корректно копируется.

• Проверить переносы строк, таблицы, колонтитулы, разрывы страниц и отсутствие обрезанного содержимого.

• Открыть PDF в независимом просмотрщике, а при важных интеграциях — в нескольких движках.

• Если заданы пароли и permissions, проверить и открытие, и ограничения в целевых приложениях.

• Для PDF/A или PDF/UA выполнить профильную автоматическую валидацию и исправить не только визуальные, но и структурные ошибки.

• Сохранить исходные данные и версию шаблона: готовый PDF не должен быть единственной копией бизнес-содержимого.

Часто задаваемые вопросы

PDFKit умеет редактировать уже существующий PDF?

Нет, это не основной и не заявленный сценарий FolioJS PDFKit. Библиотека создаёт новый документ и не предоставляет публичную модель загрузки произвольного PDF с последующим редактированием его страниц. Для такой задачи ближе pdf-lib или настольный редактор.

Можно ли использовать PDFKit бесплатно в коммерческом продукте?

Да. Пакет распространяется по MIT License. Нужно соблюдать её условия, в частности сохранять требуемое уведомление об авторских правах и текст лицензии в распространяемых копиях или существенных частях программного обеспечения.

Поддерживается ли русский текст?

Да, при использовании подходящего встраиваемого шрифта с нужными глифами. Для кириллицы не следует полагаться на стандартную Helvetica как на универсальный Unicode-шрифт. Подключение TTF или OTF с разрешённым встраиванием — более надёжный путь.

Можно ли передать HTML и CSS и получить такой же PDF?

Штатная модель PDFKit не является HTML/CSS-рендерером. Текст, таблицы, изображения и графика описываются через API. Для прямого преобразования веб-страницы лучше выбирать движок, который действительно рендерит HTML/CSS, или строить отдельный слой преобразования.

Почему в браузере 0.20.x не работает Helvetica «сама по себе»?

В основной браузерной ESM-сборке стандартные шрифтовые метрики больше не включаются автоматически. Нужный модуль из pdfkit/standard-fonts следует импортировать и зарегистрировать через registerStdFonts до создания PDFDocument, если используется соответствующий стандартный шрифт.

Подходит ли PDFKit для PDF/A?

Документация описывает параметры для PDF/A-1, PDF/A-2 и PDF/A-3 уровней A и B и связанные требования. Но корректность конкретного файла зависит от шрифтов, метаданных, структуры и использованных функций. Для архивного процесса нужен независимый валидатор.

Можно ли считать permissions полноценной DRM-защитой?

Нет. Документация прямо предупреждает, что после расшифровки PDF именно просмотрщик решает, соблюдать ли установленные ограничения на копирование, печать и изменения. Для конфиденциальных данных основой защиты должны быть контроль доступа и шифрование, а не только permission-флаги.

Чем PDFKit отличается от PDF24 Creator?

PDFKit предназначен для разработчиков и встраивается в код. PDF24 Creator — пользовательский Windows-инструмент с графическими операциями над PDF. Если человек хочет вручную объединить или преобразовать файлы без программирования, библиотека PDFKit будет лишним уровнем сложности.

Вывод

PDFKit 0.20.2 — зрелая по набору возможностей, но именно разработческая библиотека генерации PDF. Она особенно уместна там, где документ создаётся из структурированных данных и приложению нужны программный контроль страницы, шрифтов, векторной графики, таблиц, форм, аннотаций, вложений, шифрования и потокового вывода. MIT-лицензия и отсутствие облачной привязки делают её удобной как для внутреннего сервиса, так и для коммерческого продукта.

Она не подходит пользователю, который ожидает открыть существующий PDF, щёлкнуть по тексту и исправить его, а также команде, которой нужен готовый HTML/CSS-to-PDF без проектирования собственного PDF-макета. В первом случае стоит выбирать библиотеку модификации или полноценный редактор, во втором — декларативный генератор или браузерный HTML-рендерер. Для чтения готового документа Sumatra PDF дополняет, а не заменяет PDFKit: один инструмент создаёт файл, другой позволяет быстро его открыть и проверить.