Як ми створили безкоштовний редактор PDF з відкритим кодом на Next.js

Бачення: редагування PDF з пріоритетом приватності

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

Ми хотіли створити щось інше:

• 100% обробка на стороні клієнта — файли ніколи не залишають ваш браузер
• Не потрібно встановлювати — працює безпосередньо у вебпереглядачах
• Без реєстрації та відстеження — повністю анонімне використання
• Відкритий код — прозорий код, який кожен може перевірити
• Безкоштовно назавжди — жодних платних бар'єрів чи підписок

Маючи на увазі ці принципи, ми почали оцінювати технології, які могли б втілити це бачення в реальність.

Вибір технологічного стеку

Frontend-фреймворк: Next.js 14

Ми обрали Next.js 14 з новим App Router з кількох причин:

• Чудові можливості для SEO — серверний рендеринг і керування метаданими з коробки
• Підтримка статичного експорту — розгортання будь-де (Vercel, Netlify, GitHub Pages)
• Інтеграція TypeScript — типобезпека та кращий досвід розробки
• Оптимізація продуктивності — автоматичне розбиття коду, оптимізація зображень
• Досвід розробки — гаряче перезавантаження, чудова документація, величезна екосистема

Рендеринг PDF: PDF.js

PDF.js від Mozilla — золотий стандарт для рендерингу PDF у браузері. Саме він живить вбудований переглядач PDF у Firefox.

Маніпуляція PDF: pdf-lib

Для створення та зміни PDF ми використовуємо pdf-lib — бібліотеку на чистому JavaScript, яка працює повністю в браузері.

Керування станом: Zustand

Замість Redux ми обрали Zustand — мінімалістичну та швидку бібліотеку для керування станом.

• Простий API — без шаблонного коду
• Дизайн із пріоритетом TypeScript
• Малий розмір бандлу (~1KB)
• Не потрібні провайдери контексту

Стилізація: Tailwind CSS

Tailwind CSS дає нам стилізацію за принципом utility-first з чудовим досвідом розробки та малими продакшен-бандлами завдяки автоматичному очищенню.

Архітектура та проєктні рішення

1. Лише обробка на стороні клієнта

Усе відбувається в браузері:

User uploads PDF
  ↓
PDF.js parses and renders to canvas
  ↓
User makes edits (text, images, shapes)
  ↓
pdf-lib creates new PDF with changes
  ↓
Download to user's device

Файл у жодний момент не залишає пристрій користувача. Це справжня приватність за дизайном.

2. Нормалізована система координат

Один важливий виклик: PDF мають різні розміри сторінок, а користувачі можуть збільшувати/зменшувати масштаб. Як відстежувати позиції накладень?

Рішення: Нормалізувати всі координати до діапазону [0, 1].

// Instead of absolute pixels:
{ x: 150, y: 200 }

// We store normalized coordinates:
{ x: 0.25, y: 0.33 }

// Then scale to current viewport:
actualX = normalizedX * pageWidth * zoom
actualY = normalizedY * pageHeight * zoom

Це робить накладення незалежними від масштабу та переносними між різними розмірами сторінок.

3. Архітектура компонентів

Ми структурували застосунок у сфокусовані компоненти:

• PdfViewer — рендеринг основного canvas
• Thumbnails — бічна панель навігації сторінками
• Toolbar — елементи керування масштабом, обертанням, видаленням
• EditToolbar — вибір інструмента (текст, зображення, фігура)
• AdvancedOverlayLayer — рендеринг тексту, зображень, фігур
• ExportButton — логіка експорту PDF

4. Шаблон керування станом

Наше сховище Zustand підтримує:

{
  originalFile: File,
  pages: [
    {
      id: string,
      originalIndex: number,
      rotation: 0 | 90 | 180 | 270,
      deleted: boolean,
      textOverlays: [],
      imageOverlays: [],
      shapeOverlays: []
    }
  ],
  selectedPageId: string,
  zoom: number,
  editMode: 'select' | 'text' | 'image' | 'shape'
}

Технічні виклики, з якими ми зіткнулися

Виклик 1: точність вилучення тексту

PDF.js може вилучати текст, але позиціонування не завжди ідеально точне через те, як PDF кодують текст (іноді як окремі символи, іноді як слова).

Рішення: Ми вилучаємо текстові елементи з їхніми матрицями перетворення та конвертуємо їх у нормалізовані координати з широкими обмежувальними рамками.

Виклик 2: продуктивність із великими PDF

Рендеринг PDF із понад 100 сторінками може заморозити браузер.

Рішення:

• Лінива загрузка сторінок (рендеринг лише видимих сторінок)
• Використання requestAnimationFrame для плавного рендерингу
• Рекомендоване обмеження 25MB / 50 сторінок
• Offscreen canvas для мініатюр

Виклик 3: якість експорту

Вбудовування тексту та зображень у pdf-lib вимагає ретельного перетворення координат із простору браузера в простір PDF.

Рішення: Побудувати комплексний конвеєр перетворень, який обробляє:

• Обертання сторінок
• Відмінності систем координат (вісь Y перевернута в PDF)
• Вбудовування та масштабування шрифтів
• Конвертацію форматів зображень

Виклик 4: сумісність із браузерами

Різні браузери мають дещо відмінні реалізації canvas та особливості рендерингу PDF.

Рішення: Ретельне тестування в Chrome, Firefox, Safari та Edge. Використання виявлення можливостей замість виявлення браузера.

Чому ми зробили його з відкритим кодом

З першого дня ми знали, що це має бути з відкритим кодом:

Результати

Після місяців розробки ми запустили EditoraPDF з:

Кодова база доступна за адресою github.com/affsquadDevs/editorapdf за ліцензією MIT.

Ключові висновки для розробників

Долучайтеся

EditoraPDF — це проєкт з відкритим кодом, і ми вітаємо внески від розробників будь-якого рівня.

Поширені запитання

Підсумкові думки

Створення EditoraPDF було складним, але корисним шляхом. Ми навчилися безмежно багато про обробку PDF, можливості браузерів і розробку з відкритим кодом.

Найкраще? Тепер будь-хто може взяти цей код, навчитися на ньому, змінити його чи створити щось ще краще. У цьому й сила відкритого коду.

Якщо ви працюєте над подібним проєктом чи просто цікавитеся кодом, перегляньте репозиторій на GitHub. Ми будемо раді почути ваші відгуки, відповісти на запитання чи розглянути ваші pull request.