Комментарии 36
Область применения (постановка задачи)
Сразу хочу обозначить область применения, рамки поставленной задачи, чтобы исключить недоразумения в комментариях:
1. У вас есть веб API приложение на python с множеством функционала.
2. Есть бланк документа в формате pdf, в лучшем случае исходный docx файл из которого сделан этот pdf.
3. Есть требование от бизнес-заказчиков заполнить указанный pdf бланк данными клиента и в формате pdf выдать в браузер (или отправить на почту) клиенту.
Я посмотрел
Пример файла trml из предложенного вами проекта.
Похоже, чтобы применить в моём случае эту библиотеку придётся где-то взять сначала обратный преобразователь pdf2trml.
Мне бизнес даёт pdf-ку, я преобразую её в rtml и потом нет проблем с шаблонизацией.
Так вот такого преобразователя pdf2trml не существует, может существует docx2trml? Но docx файла в общем случае может не быть.
Предлагаете преобразовывать pdf в rtml ручками? Это занятие ещё более безнадёжное, чем просто впечатать в pdf данные вручную подобрав координаты впечатывания.
В общем ваше решение не годится в моём конкретном случае.
Обратного преобразователя не существует, насколько я знаю. Фарш невозможно провернуть назад.
docx2trml тоже не видел, но это уже можно руками (XSLT). О точности исходной фирмы речь идти не может, естественно, но содержимое сохранится.
Касательно именно pdf, то проще подложить исходный PDF как фон trml и сверху уже свои данные. RML такое поддерживает.
Обратного преобразователя не существует, насколько я знаю. Фарш невозможно провернуть назад.О том и речь, что обратного преобразования не существует, поэтому и приходится придумывать подобного рода приложения, как у меня в статье.
но это уже можно руками (XSLT).и
RML такое поддерживает.а RML хотя бы полей впечатываемых где взять? Тоже ручками?
И то и другое — очень грустное занятие, опять же, чтобы автоматизировать и упростить это «ручками» и предлагаю данный инструмент, про который говорится в статье.
О точности исходной фирмы речь идти не может, естественноТогда кому это надо?
Не понял предложение.
Если Вам надо заполнять *поля* PDF-форм, то таких либ вагон, и это не про RML и не про генерацию PDF вообще.
А если натянуть свой PDF поверх чужого — то да, ручками RML или (если религия запрещает пользоваться чужими велосипедами) самопал.
>> О точности исходной фирмы речь идти не может, естественно
> Тогда кому это надо?
Тем, кому не нужен договор, напечатанный с точностью 1 мм.
Вы уж определитесь в своих желаниях, тогда можно и инструмент подбирать.
И значит формат pdf хорошо подходит для обмена юридически значимыми документами.
Вы как-то неправильно понимаете редактируемость. И юридическую значимость. PDF прекрасно редактируется скажем в Adobe Acrobat, который для этого и предназначен. Конечный пользователь, обладающий акробатом, вполне может внести в документ любые изменения, дописать лишний нолик в сумму платежа, и т.п.
Для юридической значимости нужно совсем другое — чтобы любое редактирование было заметно другой стороне договора. Чтобы нельзя было дописать нолик так, и чтобы партнер не увидел, что документ редактировался. То есть, что? Правильно, нужна электронная подпись. И редактируйте сколько влезет.
А что до шаблонов — меня несколько удивляет тот факт, что люди знают про любые наколенные поделки для создания PDF, но при этом вообще не вспоминают про технологию, которая создана ровно для этого — XSL-FO. Ну или Apache FOP, если говорить об инструментах. Т.е. процесс создания шаблона выглядит как-то так:
— XML документ произвольного формата (в том числе и Word) — это шаблон, сюда подставляются изменяемые поля. Можно Word-ом.
— трансформация в XSL-FO, где будут колонтитулы, нумерация страниц и вообще все оформление
— получение PDF при помощи FOP
Выглядит это возможно и сложно, но на самом деле процесс вполне рутинный.
Выглядит это возможно и сложно
и довольно тяжелое решение.
Но я подозреваю, что для второй задачи вообще инструмент сделать невозможно — потому что структура чужого PDF может быть любой, и достать оттуда текст реально будет нельзя — потому что его там не будет.
Или html+css(да даже js) + chromium-headless. Правда, цифровую подпись надо прикручивать отдельно и нет такого обширного функционала макета страниц (но какой-то все-таки есть). Пять лет крутилась, пока не свернули приложение.
Из старичков помню ещё xslt с шаблонизатором и все это не помню чем в пдф конвертировалось. Но это было давно и не помню уже.
А оно позволяет вообще задать структуру PDF, хоть как-то? По-моему возможности CSS для печати таки довольно примитивны.
Но как вариант — почему нет?
Есть pdfjs от mozillla, посмотрите, что умеет.
Точно были хидеры/футеры, принудительный перенос на следующую страницу. Оглавление тогда мы не делали, но… Нашёл такую ссылку https://blog.chromium.org/2020/07/using-chrome-to-generate-more.html?m=1 про accessibility и tagged pdf
Юридическая значимость не суть данной статьи, поэтому, я пожалуй уберу из текста статьи словосочетание «юридически значимыми».
Но хочу пояснить, что я имел ввиду.
Статья про электронные подписи:
В соответствии с ФЗ-63 от 06.04.2011 электронные документы, заверенные ПЭП (простая электронная подпись), не имеют юридической силы. Признаются они равнозначными документам с собственноручной подписью, только если имеется дополнительное соглашение между сторонами.Сейчас кредит можно взять по коду из смс (ПЭП) и потом доказывай в суде, что код из смс не имеет юридической силы (шучу, утрирую).
Ну т.е. юридическая значимость возможна и без проверки редактировался документ или нет, при наличии соглашения между сторонами и ввода кода из смс.
При этом банки предпочитают документы слать в формате pdf, почему-то. Почему? Наверное потому, что Акробат умеющий редактировать pdf файлы платный и есть далеко не у всех рядовых пользователей, во всяком случае редактирование pdf сложнее чем редактирование docx.
А если pdf-ка из картинки сделана, то даже акробат не увидит там текста, который можно было бы отредактировать.
С точки зрения пользователя проще заюзать какой-нибудь pdffiller и т.п.
С позиции разработчика, которому нужно решение для задач проекта — сыро.
Это pet-проект для своих задач или Вы хотите развивать это в продукт?
Дополнил статью абзацем об области применения.
В данном случае нужно заполнять pdf данными внутри веб приложения, а не пользователь это ручками делает. Предлагаемое приложение — инструмент веб разработчика.
Это pet проект для нужд работы :) На работе это используем, коллеги довольны. Уверен, что это может пригодиться и другим разработчикам, вот и решил поделиться.
Я думаю развить это в продукт, если в этом есть потребность у общества, и при наличии времени, но судя по рейтингу статьи — потребности в таком продукте нет.
1. Формировавание PDF было сделано средствами SSRS. Первый лист каждого документа помечался специальным тэгом белым шрифтом на белом поле. Если вдруг печатать надумают.
2. При помощи iText (тогда она еще была iTextSharp) и элементарного кода на C#, на основании тегов один PDF в сотню тысяч листов разбивался уже на отдельные документы. Эти документы сразу рассылались по e-mail, который мог содержаться в тэге. Сам тэг, естественно, удалялся. Производительность была вполне приличной. Во-всяком случае, нить парсинга PDF постоянно ожидала нить отсылки по smtp, а не наоборот.
Какие ещё можно найти бесплатные компоненты? Я не нашёл.
«ул. Тверская д. 7 к 3. Москва» влезет а вот «ул. Героев Освободителей д. 3 к.3 стр. 4 кв. 7 посёлок городского типа Краснозатонский, городской округ Сыктывкар, Республика Коми» как быть?
Выглядит как поиграться, не для боевых задач.
Посмотрите связку каких ни будь шаблонизаторов для doc или docx и конвертируйте через openoffice в headless, рабочая схема.
![image](https://habrastorage.org/webt/rd/-n/qi/rd-nqifyadnb_ccaiz3rmkovo5e.jpeg)
Как альтернатива генерируйте документ в html и сделайте pdf папетиром
openoffice — рабочее решение, но тяжёлая зависимость, я писал об этом.
И второй раз вам говорю, перенос строк реализован уже.
На входе бизнес даёт готовый документ, генерировать html из него не имеет смысла, нет времени.
Сложнее, когда нужна таблица, причем не одна. Например, как у меня, при формировании ЕПД на коммунальные услуги (таблица услуг, таблица ОДПУ, таблица расчета ОДН и таблица расчета суммы к оплате). Причем нужно корректно переходить на второй лист, если он потребовался с повторением заголовка разорванной таблицы. И еще персональный QR код в довесок.
Перход со страницы на страницу с сохранением заголовка — похоже вы генерируете pdf с нуля.
Если есть готовая pdf-ка, как у меня, то там уже все страницы статические, все заголовки на всех страницах указаны, остаётся только сделать перенос строк на следующую страницу — это вопрос доработки предложенного мной решения.
А так, поделитесь своим решением, как вы решаете эти задачи?
QR код можно в методе API генерировать и сохранять в подпапку images с заданным именем файла, а по имени картинка подтянется уже в pdf. Это как сейчас можно сделать.
Правда это может вызвать коллизии, поэтому нужна доработка (но она не большая), чтобы картинки можно было генерировать динамически и передавать их на вставку в pdf не через диск, а через оперативную память.
Вставить QR код в моём решении нет проблем.Я имел ввиду, что доработку можно сделать, это не сложно.
Добавьте, пожалуйста, аватарку, чтобы визуально было легче ваши сообщения отличать и ассоциировать между собой.
Как «это делается в браузере»?
Каким «файлом php»? Дайте исходник.
inkscape — странная и тяжёлая зависимость для простого веб-приложения, как в моём случае.
И как SVG формирует pdf? Опять inkscape?
Вместо внешнего json на pdf можно сделать интерактивные элементы. Например Label, который можно уже извлекать из pdf по имени и перезаполнять програмно.
3/4 не совсем верно. Юнит pdf это 1/72 дюйма, а пиксель это примерно 1/96 на 23" мониторе(что соответствует 3/4), но 1/102 на 21", а на ноутах 141
Ещё вариант быстрого редактирования пдф. Переводишь его в svg. Inkscape мышкой рисуешь где какие поля и пишешь там текст $var1. При генерации заменяешь текст и скармливаешь cairosvg.
Шаблонизация PDF