Ручная генерация счетов в малом бизнесе съедает до 4-6 рабочих часов менеджера в неделю, что при ставке 500 руб./час обходится компании в 12 000 руб. ежемесячно. Автоматизация этого процесса на PHP сокращает время выпуска документа с 10 минут до 1.2 секунды, исключая 95% ошибок в реквизитах.
Выбор библиотеки: TCPDF, Dompdf или mPDF
Рынок PHP-решений для PDF делится на три лагеря. TCPDF — это «старая школа»: высокая скорость, но верстка через координаты (x, y), что делает правку дизайна кошмаром. Dompdf идеален для простых HTML-шаблонов, но «валится» на сложных CSS-сетках и больших объемах данных (от 50 страниц документ начинает тормозить). mPDF — золотой стандарт для счетов, так как лучше всего работает с UTF-8 и сложными таблицами с переносом страниц.
Кейс: при переходе с Dompdf на mPDF в проекте с генерацией каталогов на 200+ позиций время рендеринга сократилось с 8 секунд до 3.5, а верстка перестала «ехать» на стыках страниц. Мой выбор для счетов — mPDF из-за корректной поддержки CSS-свойств table-layout: fixed.
Архитектура: разделение данных и шаблона
Главная ошибка новичков — хардкод данных внутри PDF-генератора. Правильная архитектура: БД → Контроллер → Twig/Blade шаблон → HTML-строка → PDF-библиотека. Использование шаблонизатора позволяет менять дизайн счета за 5 минут без правки логики PHP. Это критично, когда клиент просит добавить логотип или изменить шрифт с Arial на Roboto.
Практика показывает, что использование промежуточного HTML-файла увеличивает нагрузку на диск, поэтому передавать данные нужно в виде строки. Оптимальный объем памяти (memory_limit) для генерации счета на 1-2 страницы должен быть не менее 128 МБ, иначе скрипт упадет с Fatal Error при рендеринге тяжелых изображений.
Подводные камни кириллицы и шрифтов
Стандартные шрифты PDF (Helvetica, Times) не поддерживают кириллицу, что приводит к появлению «квадратиков» вместо текста. Решение — внедрение TTF-шрифтов (например, DejaVu Sans или Roboto). Важный нюанс: размер PDF-файла вырастает с 20 КБ до 150-200 КБ из-за встраивания шрифта, что увеличивает расход трафика при массовой рассылке 1000+ счетов по e-mail.
Ошибка: использовать веб-шрифты через @import. Библиотеки PDF не умеют ходить в сеть за CSS. Только локальные пути к .ttf файлам. Мой опыт: использование сжатия изображений через GD или Imagick перед вставкой в PDF сокращает вес итогового документа на 40-60%.
Безопасность и хранение сгенерированных файлов
Хранить счета в открытой папке /uploads/invoices/ — грубая ошибка безопасности. Любой пользователь, перебрав ID в URL (invoice_1.pdf, invoice_2.pdf), получит доступ к чужим финансовым данным. Правильный подход: хранение в защищенном каталоге вне public_html и отдача файла через PHP-скрипт с проверкой сессии пользователя или уникальным токеном в ссылке.
Срок хранения: для малого бизнеса оптимально хранить PDF в облаке (S3) или на диске 3 года согласно налоговому кодексу. Если использовать готовые скрипты на PHP, проверьте, есть ли в них механизм автоматической очистки временных файлов (tmp), иначе через полгода сервер забьется гигабайтами мусора.
Вывод
Для автоматизации счетов выбирайте связку mPDF + Twig. Избегайте TCPDF, если не готовы тратить часы на ручную расстановку элементов по координатам. Начинайте с реализации простого HTML-шаблона, который затем конвертируется в PDF, и обязательно выносите хранение документов за пределы публичного доступа. Это надежнее и масштабируемее, чем любые «коробочные» решения с закрытым кодом.