Comments 15
Хорошая статья, спасибо! Было интересно почитать!
Но в ходе прочтения возникло несколько вопросов по этой сфере.
Почему именно .docx? Понимаю, что исторически так сложилось, что это максимально простой инструмент для создания любого документа и т.д. и т.п., но почему для этой задачи не использовать условный latex? Ведь насколько я понимаю на выходе нет необходимости обрабатывать дополнительно этот файл? А у latex большие возможности для создания такого рода документов (ИМХО, естественно).
Объясню: представим, что документ у нас с шапкой и подписью внизу. Что будет если значение одного из полей будет больше, чем отведенное под него место (на заполнителе)? Скорее всего строка с подписью съедет на другой лист. Latex же позволит всегда размещать строку с подписью внизу страницу если это возможно, при этом если справка/заявление/иной документ будет более чем на страницу, то и подпись будет на последней странице внизу.
Да, резонно кто-то скажет, а как простой секретарь/менеджер/etc будет пользоваться latex? А по сути, ему и не надо это делать. Нужен один человек в компании кто заблаговременно создаст шаблоны заявлений в нем, а уже пользователь будет просто с помощью программы с GUI выбирать шаблон, заполнитель и т.д.
>Что будет если значение одного из полей будет больше, чем отведенное под него место (на заполнителе)?
Ворд же рендерит, как вы зададите ему это поле так и будет. Можно проверить не отходя от кассы. Боитесь, что съедет — рисуйте фрейм с абсолютным позиционированием и в нем вставляете переменную. Подпись вставлять можно так же с абсолютным позиционированием.
Нужен один человек в компании кто заблаговременно создаст шаблоны заявлений в нем,
Он всегда будет получать ворд от юриста и всегда будет до запятой искать отличия в новом и своем шаблоне, каждый раз, ведь юрист ему не принесет дельту. Это лишнее звено. Сам юристу отдаешь размеченный документ первый раз для примера и просишь его использовать для правок. А так ответственность размывается на двух людей, это куда сложнее контролировать.
Копипаста из ватсапа буху с описанием переменных вот и весь гуй.
Здесь дело не столько в том, что так исторически сложилось, сколько в том, чтобы создать максимально простой (для конечного пользователя) инструмент. Редактирование DOCX-документа после его заполнения вполне естественная операция для пользователя (к примеру, при заполнении комплекта документов при онбординге, какие-то поля документов вполне могут редактироваться вручную, боль доставляет "переписывание" данных из отсканированных документов). Тот инструмент, который получился здесь, можно отдавать сотруднику и начать им пользоваться он сможет уже через несколько минут.
В рамках более серьезного внедрения в информационную систему корпорации эту задачу можно решать совсем по-другому - с более глубоким интегрированием в существующую инфраструктуру, подгрузкой стандартных шаблонов (и уже, возможно, не в DOCX а в том формате или форматах, который принят в организации), и интеграцией распознавания не через вызов простейшего консольного приложения, а вызывая библиотечные функции.
Хотим простое GUI-приложение, которое бы умело загружать шаблонные документы в формате DOCX, в стратегических местах которых проставлены теги вида
${very_important_info}
Чем вызван выбор такого не нативного тега?
Обычно используются свойства документа и "поля". ПО меняет свойство, поля обновляются уже самим движком текстового процессора. В крайнем случае, нативно поле имеет тег { DOCPROPERTY name }
github.com/guigrpa/docx-templates
Благо это можно менять в настройках.
Свойства типа нативных переменных ворда? Так они отвратительные, их же копипастой не задать, надо вставлять через интерфейс ворда разметку.
В смысле нельзя?
Пишете условный DOCPROPERTY name, выделяете, ctrl+F9 и вуаля. Ну лан, справедливости ради надо еще нажать "обновить поле".
Или вы про создание перечня полей?
Так включаете подсветку полей и они начинают подсвечиваться, так что в тексте становится сразу видно, что поле, а что нет. Причем, хочешь отображай имя поля, хочешь значение.
В этом кстати и есть сакральный смысл, потому что оформляя документ по ЕСКД, какая-нибудь длинная фамилия может поломать рамки и вы это увидите сразу, до, так сказать, рендера.
На счет переусложненности DOCPROPERTY, ну х.з. вон в yml один лишний пробел может весь конфиг поломать - сиди вычитывай. Ну и не стоит забывать что ворд это WYSIWYG - а много вы WYSIWYG-движков с переменными знаете? Бухгалтерам это не надо, программисты и на VBA\С#\python напишут ПО которое будет данные сразу из БД брать.
В общем ворд, нормальная, мощная штука, просто его надо изучать и строить процессы исходя из его возможностей, а не "мы привыкли по другому"
P.s. кстати, в ворде можно вообще сделать выпадающий список в поле с предустановленными значениями. Т.е. можно ограничить оператора сразу нормализованными значениями, чтобы не пихал всякую фигню. И править все это можно без заныривания в код.
Вы правы, что есть более каноничные способы заведения полей в DOCX-шаблонах, однако целью здесь было создание максимально простого инструмента, которым можно пользоваться как для заполнения полностью шаблонных документов, так и для "дозаполнения" подготовленных комплектов документов. Для разработки я не завязывался на возможности текстового процессора (кроме того, я не уверен, что python-docx умеет нативно работать с DOCPROPERTY). В крайнем случае, изменить текущий механизм тегов вида ${tag} на более нативный формат не составит труда.
Делал когда-то такое - с таблицами, циклами и условиями вставки. Вот как это выглядело:
Красные - это управляющие коды по разделам, таблицам и др., которые при обработке из документа удалялись, а переменные были просто в квадратных скобках...
Поставил бы плюсик, но их нет у меня. Положу в закладки: возможно когда-нибудь пригодицца :)
Добрый день,
В чем сакральный смысл не показывать стоимость решения на сайте? Ведь оно, наверняка, коммерческое. Или для разных заказчиков цена сильно разная?
Простой шаблонизатор DOCX-документов с помощью Smart Document Engine