Pull to refresh

Comments 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 хотя бы полей впечатываемых где взять? Тоже ручками?
И то и другое — очень грустное занятие, опять же, чтобы автоматизировать и упростить это «ручками» и предлагаю данный инструмент, про который говорится в статье.
О точности исходной фирмы речь идти не может, естественно
Тогда кому это надо?
> а RML хотя бы полей впечатываемых где взять? Тоже ручками?
Не понял предложение.
Если Вам надо заполнять *поля* PDF-форм, то таких либ вагон, и это не про RML и не про генерацию PDF вообще.
А если натянуть свой PDF поверх чужого — то да, ручками RML или (если религия запрещает пользоваться чужими велосипедами) самопал.
>> О точности исходной фирмы речь идти не может, естественно
> Тогда кому это надо?
Тем, кому не нужен договор, напечатанный с точностью 1 мм.
Вы уж определитесь в своих желаниях, тогда можно и инструмент подбирать.
И значит формат pdf хорошо подходит для обмена юридически значимыми документами.

Вы как-то неправильно понимаете редактируемость. И юридическую значимость. PDF прекрасно редактируется скажем в Adobe Acrobat, который для этого и предназначен. Конечный пользователь, обладающий акробатом, вполне может внести в документ любые изменения, дописать лишний нолик в сумму платежа, и т.п.

Для юридической значимости нужно совсем другое — чтобы любое редактирование было заметно другой стороне договора. Чтобы нельзя было дописать нолик так, и чтобы партнер не увидел, что документ редактировался. То есть, что? Правильно, нужна электронная подпись. И редактируйте сколько влезет.

А что до шаблонов — меня несколько удивляет тот факт, что люди знают про любые наколенные поделки для создания PDF, но при этом вообще не вспоминают про технологию, которая создана ровно для этого — XSL-FO. Ну или Apache FOP, если говорить об инструментах. Т.е. процесс создания шаблона выглядит как-то так:
— XML документ произвольного формата (в том числе и Word) — это шаблон, сюда подставляются изменяемые поля. Можно Word-ом.
— трансформация в XSL-FO, где будут колонтитулы, нумерация страниц и вообще все оформление
— получение PDF при помощи FOP

Выглядит это возможно и сложно, но на самом деле процесс вполне рутинный.
Выглядит это возможно и сложно

и довольно тяжелое решение.

Зато работает уже десятки лет. Не, разумеется оно не универсальное, и это лишь решение для генерации своего PDF с нуля, а не редактирования чужого. И для этой же цели у него есть аналоги попроще и полегче, и XSL-FO — это пожалуй самое сложное из возможных. Но оно таки осваивается с нуля за неделю — я проверял пару раз на разных людях.

Но я подозреваю, что для второй задачи вообще инструмент сделать невозможно — потому что структура чужого PDF может быть любой, и достать оттуда текст реально будет нельзя — потому что его там не будет.

Или html+css(да даже js) + chromium-headless. Правда, цифровую подпись надо прикручивать отдельно и нет такого обширного функционала макета страниц (но какой-то все-таки есть). Пять лет крутилась, пока не свернули приложение.


Из старичков помню ещё xslt с шаблонизатором и все это не помню чем в пдф конвертировалось. Но это было давно и не помню уже.

>chromium-headless
А оно позволяет вообще задать структуру PDF, хоть как-то? По-моему возможности CSS для печати таки довольно примитивны.

Но как вариант — почему нет?

Есть pdfjs от mozillla, посмотрите, что умеет.

Насколько я помню, это парсер, и рендеринг. То есть совсем не для того, чтобы генерировать PDF под шаблоны. Хотя я много лет на него не смотрел.
Спасибо за комментарий и извините за задержку ответа, нужно было действительно поизучать вопрос, а времени в обрез.
Юридическая значимость не суть данной статьи, поэтому, я пожалуй уберу из текста статьи словосочетание «юридически значимыми».
Но хочу пояснить, что я имел ввиду.
Статья про электронные подписи:
В соответствии с ФЗ-63 от 06.04.2011 электронные документы, заверенные ПЭП (простая электронная подпись), не имеют юридической силы. Признаются они равнозначными документам с собственноручной подписью, только если имеется дополнительное соглашение между сторонами.
Сейчас кредит можно взять по коду из смс (ПЭП) и потом доказывай в суде, что код из смс не имеет юридической силы (шучу, утрирую).
Ну т.е. юридическая значимость возможна и без проверки редактировался документ или нет, при наличии соглашения между сторонами и ввода кода из смс.
При этом банки предпочитают документы слать в формате pdf, почему-то. Почему? Наверное потому, что Акробат умеющий редактировать pdf файлы платный и есть далеко не у всех рядовых пользователей, во всяком случае редактирование pdf сложнее чем редактирование docx.
А если pdf-ка из картинки сделана, то даже акробат не увидит там текста, который можно было бы отредактировать.
Ну, давайте я упрощу — я имел в виду простую вещь, что юридическая значимость и возможность редактирования — не одно и тоже. Что для юридической значимости может быть нужно что-то разное и другое. Проверка на редактирование — ну наверное да, почему бы контрагенту и не поредактировать документ, но с другой стороны — если вы его уже подписали, а он потом вносит правки — то это действие с неочевидными последствиями.

С точки зрения пользователя проще заюзать какой-нибудь pdffiller и т.п.


С позиции разработчика, которому нужно решение для задач проекта — сыро.


Это pet-проект для своих задач или Вы хотите развивать это в продукт?

Дайте ссылку на pdffiller, не знаю что это такое.
Дополнил статью абзацем об области применения.
В данном случае нужно заполнять pdf данными внутри веб приложения, а не пользователь это ручками делает. Предлагаемое приложение — инструмент веб разработчика.
Это pet проект для нужд работы :) На работе это используем, коллеги довольны. Уверен, что это может пригодиться и другим разработчикам, вот и решил поделиться.
Я думаю развить это в продукт, если в этом есть потребность у общества, и при наличии времени, но судя по рейтингу статьи — потребности в таком продукте нет.
Аналогичную задачу решал намного проще.
1. Формировавание PDF было сделано средствами SSRS. Первый лист каждого документа помечался специальным тэгом белым шрифтом на белом поле. Если вдруг печатать надумают.
2. При помощи iText (тогда она еще была iTextSharp) и элементарного кода на C#, на основании тегов один PDF в сотню тысяч листов разбивался уже на отдельные документы. Эти документы сразу рассылались по e-mail, который мог содержаться в тэге. Сам тэг, естественно, удалялся. Производительность была вполне приличной. Во-всяком случае, нить парсинга PDF постоянно ожидала нить отсылки по smtp, а не наоборот.
Делал в Delphi (можно и FPC или вообще что угодно где можно зацепиться к OLE) через OLE (установленный офис конечно нужен). Делаем шаблон документа с нужными полями в Word/Excel, заполняем эти поля из кода как надо, далее через OLE же и экспортируем как pdf куда надо. Конвертировал таким образом около 5000 документов одного предприятия и приводил к единообразию, правда не в pdf, а просто другой docx, но никаких проблем не вижу. Можно найти и бесплатные компоненты для создания PDF даже без сторонних библиотек в том числе скорее всего всё это будет работать и в Linux, но это не точно.
С OLE не сталкивался, но если притянуть зависимость Word/Excel, то это не Linux и в любом случае зависимость тяжёлая, т.е. приложение на 10 000 строк кода будет требовать установки целого приложения. Я написал об этом в статье.
Какие ещё можно найти бесплатные компоненты? Я не нашёл.
Конкретно для Delphi вроде как есть Synopse PDF Engine и PowerPDF из бесплатных. К сожалению дел с ними не имел, ничего сказать более не могу. Опять же только Win.
А что делать с полями которые могут стать многострочными, скажем юридический адрес или еще что то такое?
«ул. Тверская д. 7 к 3. Москва» влезет а вот «ул. Героев Освободителей д. 3 к.3 стр. 4 кв. 7 посёлок городского типа Краснозатонский, городской округ Сыктывкар, Республика Коми» как быть?
Посмотрите видяшку, там же показано, что реализован перенос строк, если текст не помещается в заданную ширину, то он переносится на другую строку. На примере прля 3_work это показано.
Не обратил внимание сразу, но выглядит как то не очень, ячейка по логике должна растягиваться.
Выглядит как поиграться, не для боевых задач.
Посмотрите связку каких ни будь шаблонизаторов для doc или docx и конвертируйте через openoffice в headless, рабочая схема.
Вот боевой пдф с текущего проекта, как тут без переноса строки быть? никак
image

Как альтернатива генерируйте документ в html и сделайте pdf папетиром
Ячейки можно растягивать и сжимать, посмотрите видяшку.
openoffice — рабочее решение, но тяжёлая зависимость, я писал об этом.
И второй раз вам говорю, перенос строк реализован уже.

На входе бизнес даёт готовый документ, генерировать html из него не имеет смысла, нет времени.
Не увидел как таблица в документе растягивается
image

Но и логично что в данном случае это не возможно, в примере я кидал документ где таблица растягивается из за переноса строк и двигает остальной контент
Перенос — мелочи.
Сложнее, когда нужна таблица, причем не одна. Например, как у меня, при формировании ЕПД на коммунальные услуги (таблица услуг, таблица ОДПУ, таблица расчета ОДН и таблица расчета суммы к оплате). Причем нужно корректно переходить на второй лист, если он потребовался с повторением заголовка разорванной таблицы. И еще персональный QR код в довесок.
Вставить QR код в моём решении нет проблем.
Перход со страницы на страницу с сохранением заголовка — похоже вы генерируете pdf с нуля.
Если есть готовая pdf-ка, как у меня, то там уже все страницы статические, все заголовки на всех страницах указаны, остаётся только сделать перенос строк на следующую страницу — это вопрос доработки предложенного мной решения.

А так, поделитесь своим решением, как вы решаете эти задачи?
Писал же выше.

Я генерирую PDF средствами SSRS. Поэтому для форматирования пользуюсь его возможностями, которые весьма широки.

А вот как в Вашем решении вставить QR код я не понял. Это же не статическая картинка, а закодированные данные.
А… Читал ваше сообщение с вариантом решения, буду иметь его ввиду, если что, правда это не мой стэк на данный момент.

QR код можно в методе API генерировать и сохранять в подпапку images с заданным именем файла, а по имени картинка подтянется уже в pdf. Это как сейчас можно сделать.
Правда это может вызвать коллизии, поэтому нужна доработка (но она не большая), чтобы картинки можно было генерировать динамически и передавать их на вставку в pdf не через диск, а через оперативную память.
Вставить QR код в моём решении нет проблем.
Я имел ввиду, что доработку можно сделать, это не сложно.

Добавьте, пожалуйста, аватарку, чтобы визуально было легче ваши сообщения отличать и ассоциировать между собой.
UFO just landed and posted this here
Есть исходный pdf, сколько у вас займёт времени сверстать его в html?
Неделя? Это очень много сил и времени требует. И в итоге pdf-ка не похожая на исходную получится. И за эту неделю бизнес передумает и скажет, что бланк изменился и нужно ещё несколько бланков сделать.
Вёрстка в html не подходит.
Встала проблема — накладная в PDF, надо было в него добавить различные данные как ФИО, даты, различные цифры. Все это делается в браузере, файлом php — inkscape превращает pdf в формат SVG (который по сути текст) далее правленный SVG формирует результирующий файл pdf.
Как-то слишком сжато и поэтому не понятно.
Как «это делается в браузере»?
Каким «файлом 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.

Sign up to leave a comment.

Articles