Какими языками программирования удобно править и создавать файлы расширений docx/xlsx/odt/ods под Linux?

Question

[Денис _______________]

В связи с тем что в строительной отрасли начато импортозамещение, через какое-то время использовать напрямую MS Office станет невозможно (не лично, а массово). Учитывая, что альтернативы VBA в самих офисных пакетах под Linux'ом уступают ему, принято стратегическое решение переучиться на альтернативный язык программирования, который бы внешним модулем позволял осуществлять как правки исходного файла, там и переносить данные из него во вновь создаваемые офисные файлы, в т. ч. из таблиц в текстовый процессор (xlsx -> docx, ods -> odt).

Соответственно, вопрос: какие языки позволяют это сделать и с каким набором дополнений/модулей?

Доп.вопрос: возможно ли при этом создание форм с красивыми кнопочками или только запуск исключительно через командную строку?

Answer 1

[Adamos]

Осваивайте веб-стек, и вам не понадобится гоноебиться с офисными файлами вовсе (разве что экспортировать данные в них для самых отсталых).
Особенно - в строительной отрасли, где тот офис на хрен не нужен. PDF - естественный формат для документации.

Comments

[Игорь]

экспортировать данные в них для самых отсталых

где тот офис на хрен не нужен.

то что вы не сталкиваетесь с офисными файлами, совершенно не значит что ими никто не пользуется и они устарели

[Adamos]

Игорь, какая глубокая мысль...
Я сталкиваюсь с офисными файлами. И с тем колхозом, который вследствие их чрезмерного использования разводится в бизнесе. Однажды тем, кто думает о будущем, приходится приводить эти конюшни в порядок. Иногда - с моей помощью.

[Игорь]

приведение подобных конюшен в порядок, это огромные деньги которые зачастую не окупаются для бизнеса

[Adamos]

Игорь, моя практика показывает обратное по обоим пунктам. Но для этого должны встретиться и договориться два грамотных человека - один со стороны бизнеса, другой со стороны IT.
Теоретики сильно любят порассуждать об окупаемости бизнеса, при этом обычно размахивают примерами размером со Сбер. А там таких конюшен и нет, потому что крупные организации в них просто завязнут и не смогут работать.
Разгребать приходится мелкий-средний бизнес, и это действительно могут сделать буквально два человека. В процессе основной работы или даже в свободное время. Главное - понимать, что делаешь и что действительно нужно сделать.

[Игорь]

Adamos,

А там таких конюшен и нет

хахахх...
вот уж там конюшни так конюшни.
вы ниразу не сталкивались с тем что внутри крупных компаний документы пересылают не через внутреннюю какуюнить систему, а через гуглдокс сотрудника?
я видел ситуацию когда презентацию сегодня делали в miro, завтра в coda, послезавтра показывают инфу в confluenct а потом ссылаются на переписку в почте? это уже крупный бизнес.
я видел даже настройки внутри дремучей корпоративной системе которая генерила правильные docx файлы которые обрабатывают какието странные софтины написанные в староглинянные времена автоматизации.

Главное - понимать, что делаешь и что действительно нужно сделать.

это руководству бизнеса надо понимать, а не конечным сотрудникам

[Adamos]

Игорь, сталкивался. Но это не ситуация "все через жопу, системы нет", это ситуация "система есть, но делается через жопу". В этой ситуации одинокому айтишнику разгребать нечего.
Про конечных сотрудников и речи не было. Понимание обоих сторон автоматизации требуется тем двоим, кто ее осуществляет. Сотрудники ставятся перед фактом, и дальше идет административное лечение, айтишник может умыть руки.

Answer 2

[Александр Нестеров]

Если говорить о xlsx/docx (которые спокойно открывается libre office, насчёт OpenOffice не уверен), то подойдёт буквально любой актуальный язык, для них сейчас полно библиотек.
С точки зрения простоты входа*, наверное, самым простым вариантом будет python и библиотека openpyxl (для Ворда есть своя, но навскидку не вспомню).
Для интерфейса можно использовать, например, pyqt. Также, можно сделать небольшой сайт на flask, а формы нарисовать с помощью html/js/css.
Правда, в случае если файлы большие или есть сложные расчеты, то саму обработку лучше запускать отдельно, чтобы приложение не подвисало. В случае с pyqt в отдельном потоке, в случае с flask'ом - фоновая задача с помощью celery. Но это уже больше вопрос оптимизации и в целом, не обязательно.

Comments

[Владимир Коротенко]

Да бог мой, ну зачем этот питон если там автоматизация на яве? Зачем вот это все?

[Adamos]

Владимир Коротенко, ТС клепает скриптики на Вижуал Барсике. До Явы ему, мягко говоря, далековато.

[Владимир Коротенко]

Adamos, по моему не сложно, с учетом того что бывает в вба
https://www.openoffice.org/udk/common/man/tutorial...

[Денис _______________]

Юрий,
с GTK та же история или нет?

[Денис _______________]

Юрий,
сам интересуюсь

[Александр Нестеров]

Денис _______________, ну, библиотека для GTK под python есть, но она не обновлялась уже больше десяти лет. Возможно есть и более новые варианты, но судя по тому, что в топе выдачи появляется она, то вряд-ли.
Как альтернативу могу посоветовать Kivy. Вроде тоже относительно популярная и обновляемая вещь, хотя лично с ней работал оценить не могу. Но в отличии от QT, разрабы не уходили из РФ.

[shurshur]

Юрий, qt - опенсурсный проект.

[Rinkashikikato]

Если говорить о xlsx/docx (которые спокойно открывается libre office, насчёт OpenOffice не уверен), то подойдёт буквально любой актуальный язык, для них сейчас полно библиотек

А если "не говорить", то буквально любой актуальный язык - не подойдёт?

И что такое "актуальный язык"?

[shurshur]

Юрий, это не значит, что использовать qt в приложениях стало вдруг нельзя.

[Александр Нестеров]

Rinkashikikato,

А если "не говорить", то буквально любой актуальный язык - не подойдёт?

Суть в том, что для данных форматов библиотеки точно есть, они обновляются и для них есть хорошие документации и примеры за их приделами. С odt, о котором так-же шла речь, я не работал и о ситуации с библиотеками для них не в курсе.

И что такое "актуальный язык"?

Тот, который используется на рынке для решения задач и все-еще активно развивается за счет авторов языка и сторонних разработчиков.

Answer 3

[Владимир Коротенко]

Я бы рекомендовал следующие связки:

* NET6 + vue |react + postgres + microsoft visual studio 2022 | rider jetbrains
* Java + Intellyjava + spring + vue |react + postgres
* Java + openoffice (аналог VBA) https://www.openoffice.org/udk/common/man/tutorial...

Первые две связки вообще не требуют пользовательского опыта, все просто в браузере. Третья это чисто скриптовщина, но чем то похожая на ms

Comments

[Денис _______________]

* NET6 + vue |react + postgres + microsoft visual studio 2022 | rider jetbrains
* Java + Intellyjava + spring + vue |react + postgres
* Java + openoffice (аналог VBA)

А оно в Linux'е работать будет?

[Владимир Коротенко]

Денис _______________, за исключением microsoft visual studio 2022 все работает на

MacOS, Windows, Linux

visual studio 2022 только MacOS, Windows но это среда разработки

[Adamos]

Денис _______________, запустите LibreOffice (не OpenOffice, давно стагнирующий) и посмотрите в нем работу с макросами. Примерно такой же VisualBasic там тоже есть. Но это колхоз и грабли, если говорить о перспективах.
Те расчеты давно и массово выносят из Excel на веб-страницы, и они, переписанные на JS, становятся не только удобнее для пользователя, но и позволяют более вменяемо развивать и поддерживать этот код самому владельцу.

[Денис _______________]

Adamos, я не хочу выносить это все в веб по одной простой причине, что пользоваться будут люди, зачастую с урезанными правами. Задача дать им ПО что бы была максимальная портативность и минимум установок. Чем были хороши макросы VBA? Даешь юзеру файл где все кошерно, и ему не нужно заморачиваться с установками. Сайт требует веб-сервера, условного Apache/Nginx/и т.п. Юзеру его ставить и настраивать лишний геморрой, хотя в принципе у DokuWiki/XWiki это в меру портативно. Но я же хочу дать им файлы, как привычный для них формат хранения данных, и внешний макрос, который обработав эти файлы создаст новые.
Еще одна причина, по которой я не хочу уходить от таблиц Calc/Excel это то что для больших объемов вводимого текста/данных это на порядки удобнее и быстрее чем делать то же самое с переключением через поля ввода что в графической форме Windows окна, что в веб-интерфейсе. Я могу протянуть данные, ввести формулу и протащить, я могу использовать ВПР или ПОИСКПОЗ. Я концентрируюсь именно на скорости ввода обычным юзером, а не скоростью обработки данных, потому что банальное заполнение шаблонов это порядка 5-10сек на один файл в том же VBA c учетом открытия и закрытия файла. Даже если код будет не оптимален, его можно отполировать. Но время юзера, кроме таблиц, не сэкономит никто. Это мое мнение и пока что его еще никто не опроверг.
Однако я согласен что обрабатывать БД удобнее, там все параллелится, отчетность организовать проще. Но мне это не надо, я решаю простую задачу: максимально упростить ввод однотипных данных, с последующим заполнение шаблонных документов на их основании. Все.

[Adamos]

Денис _______________, современный JS позволяет сделать это одной страничкой HTML с включенными скриптами.
А браузер, в отличие от MS Office, у пользователя будет в любом случае, особенно если следом за MS Office начнутся проблемы с MS Windows.

[Денис _______________]

Adamos, У юзера так или иначе будет один из следующих офисов на ПК:
- LibreOffice
- МойОфис
- Р7-Офис
- WPS Office/OnlyOffice (в особо упоротом случае)

Соответственно простой дизайн без излишеств. Дизайн - выпадающие списки + игра с цветом ячеек + стоковые шрифты Linux/ + рисование границ ячеек. Все. Этого будет достаточно.

А браузер, в отличие от MS Office, у пользователя будет в любом случае, особенно если следом за MS Office начнутся проблемы с MS Windows.

Под Linux'ом есть не только браузеры, но и офисные пакеты, поэтому я планирую отвязаться от VBA макросов, но оставить для совместимости поддержку файловых форматов, т.к. альтернативы все же позволяют такой файл открыть, другое дело что вопрос с форматированием никуда не денется, но тут я планирую это решать через конвертацию в pdf формат.

[Adamos]

Денис _______________, насколько мне известно, макросы от одного офиса на другом не запустятся.
Так что привязка к Либре неизбежна.
Собственно, веб - это не альтернатива, это перспектива. Понемногу уходить от решений прошлого века к системам нынешнего, работая не с файлами, а с данными.

[Денис _______________]

Adamos,
Если файл будет обрабатываться условным Питоном, Си, бейсиком извне, то макросы не потребуются. Вопрос в том в чем это проще реализовать.

Собственно, веб - это не альтернатива, это перспектива.

Ну поймите Вы, к примеру есть шаблон документа, скажем в него нужно засунуть 40 переменных, из которых 10-15 априори повторяющиеся с соседними актами (например: наименование объекта, Застройщика/Заказчика, Подрядчика, их реквизиты и т.п.), есть штук 5-10 которые будут совпадать только у части таких актов (например подписанты, которые в течении строительства меняются), а есть уникальные (например номер акта, ссылка на ГОСТ/ТУ, наименование работы/материала, кол-во и т.п.) Если делать через Веб, то все 3 типа переменных будут всегда уникальными. ОК, я еще смогу вытащить те кто будут совпадать всегда, а вот что делать с теми которые будут совпадать, но не для всех? В таблице я выделил ячейки и протянул - это займет секунд 10, в итоге я сосредоточусь только на вводе уникальных данных, в то время как реализация по Вашему принципу отделит блок данных одного акта от другого (как самостоятельный документ), и для того что бы посмотреть соседние мне необходимо будет совершать новые телодвижения мышью/клавиатурой, скопировать/вставить за раз более одного текстового блока не получится, в то время как в офисной таблице я вижу данные для нескольких соседних актах. И, Если ориентироваться на Пользователя, то ему плевать на современные технологии, ему Важно удобство. Если сравнивать условный MS OFFICE против альтернативной реализации через веб и веб реализация окажется менее удобной, то зачем ее стоит начинать? Что она решает? В то время как таблицы помогают быстро вводить данные, совершая для этого меньше телодвижений, а так же позволяют видеть заполнение для соседних актов, т.е. это позволяет избежать описок/опечаток на стадии подготовки данных. Человеку не нужно открывать пачку документов поочередно, что бы проверить правильность внесенных данных. Он открывает таблицу и в портянке видит сразу все.
А теперь представьте что в день делается по 10-20 таких актов, несколько сотен штук в месяц... И Вы поймете что малейшее неудобство со вводом выльется в огромные время потери, которые можно было бы потратить более продуктивно.

ИМХО, как минимум веб в этом вопросе шаг назад, а не вперед.

[Adamos]

Денис _______________, делал я на сайте генерацию договора, где одним пунктом выбирается агент, а вторым - его подписант из БД. И выводится все красиво в PDF с печатью и факсимиле, хранящимися все там же...
Цимес как раз в том, что чем больше вы работаете с информацией и чем меньше - с тупыми таблицами, тем меньше вам таки приводится вводить информации извне - она и так уже под рукой.
Однако, подозреваю, мы давно утомили автора ответа этим диалогом. Думаю, мы друг друга более или менее поняли, вы свои позиции укрепили - и дальнейшая дискуссия вряд ли будет плодотворной.

[Владимир Коротенко]

Денис _______________, Грубо говоря задача какая?
Допустим из моих последних это
расчет премии продажникам
расчет проходок для кабельных заполнителей (там кстати и был экспорт в автокад)

[Денис _______________]

Владимир Коротенко,
структурирование информации для автоматического заполнения такого рода документов в строительстве:
https://minjust.consultant.ru/documents/38462?item...

Это сотни видов актов, каждый из который заполняется и подписывается комиссией для своего вида работ. Иногда на какую то работу их делается один, а иногда 10. Кроме актов есть журналы, в которые вписываются как сами акты, так и работы, по которым акты оформляются. Все это меж собой должно биться, в т.ч. с привязками к датам, графику, технологии (проекту), подписантам, присутствующим на объекте в определенные сроки, количеству и качеству используемых материалов, на которые так же оформляются акты входного контроля и делаются записи в журналах...

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

Ежемесячно, на основании этоих бумаг, формируются закрывающие акты по смете контракта, по формам КС2, КС3, КС6а. Обычное такое закрытие это от десятков тысяч рублей до сотен миллионов рублей, поэтому правильность заполнения макулатуры и ее количество решают. Подписанные акты возят сотнями листов бумаги а4, иногда коробками. Любая автоматизация здесь экономит время

[mayton2019]

Я так понимаю что microsoft visual studio 2022 тоже попадает под нож импорто-замещений.

[Денис _______________]

mayton2019,
конечно попадает

[Adamos]

Денис _______________, вот именно для таких случаев существуют CRM, где все эти бесчисленные ОКТМО и ОГРН хранятся в базе данных, а человек видит необходимый минимум информации по проекту и работе над ним, внося поправки одной кнопкой и при любой необходимости генерируя по шаблонам тонны чиновничьей макулатуры, гарантированно содержащей бьющиеся между собой данные. Причем не в офисных форматах, которые может перекосить на конкретной машине, а в аккуратных PDF, гарантирующих неизменность документа. При желании - с подписями, печатями или электронной подписью, если чиновники уже с пальмы слезли.

[Денис _______________]

Adamos,
Это не везде есть и не везде будет, потому что на объектах бывают проблемы со связью, проблемы в головах руководства, банальная экономия денег на IT в строительстве, чьи-то предрассудки, вопросы безопасности, т.к. доступ к такой CRM нужно давать не только своим сотрудникам, но и всем участникам строительства.

Кроме того, я уже писал выше, для того кто вводит данные это неудобно и такой человек теряет уйму времени на вводе данных в каждый акт, по сравнению с использованием таблиц. Как ни странно. Кроме того в большинстве случаев те кто уже реализовал такой функционал забыли про совпадающие поля. Соответственно на это накладывается кривой софт.

Согласно ГОСТу на Исполнительную Документацию, утвержденному в этом году, я должен предоставлять ее в следующих форматах:

2. Файлы документов представляются в том формате, в котором они подписаны электронной подписью. При этом файлы документов могут быть представлены в следующих форматах:
а) PDF, RTF, DOC, DOCX, XLS, XLSX, ODT, XPS - для документов с текстовым содержанием;
б) PDF, JPEG (JPG), PNG, TIFF, XPS - для документов с графическим содержанием.

При этом, все еще до сих пор, на большинстве строек такие акты делаются на бумажном носителе и подписываются вручную. А для этого они оформляются в офисе и печатаются на бумаге.

[Adamos]

Денис _______________, вот как раз безопасность в CRM и имеет место, в отличие от раскидывания всем подряд всех подряд файлов для какой угодно правки. Дать конкретному пользователю ограниченный доступ - функционал "из коробки".
Ввод данных, если это данные, а не строчки в ворде / клеточки в Ёкселе, требуется один раз - потом они под рукой, их не нужно вводить, только выбрать нужные.
PDF на первом месте в обоих списках - это правильно, разбирающийся человек составлял ;) А вот за RTF, DOC и XLS его бы выпороть, конечно.

Answer 4

[mayton2019]

Какими языками программировани....

С помощью Apache Poi https://poi.apache.org/apidocs/index.html я работал с XLSX документами (язык Java и платформа Linux. Насколько полно POI покрывает возможности MS документов - я не знаю. Другие типы не пробовал. Вообще сама постановка вопроса насчет языков - неверная. Если вы берете например LibreOffice - то там главное ядро например написано на сях а к ней идет куча API разработки https://api.libreoffice.org/ смотрите полный список по ссылке.

Будьте осторожны с заменой MS-Office. У меня есть предположение что заменить их на 100% невозможно. Уж слишком они тесно связаны с технологиями MS. Возможен такой вариант что какой-то офисный документ вы не откроете просто потому что в нем есть всякие OLE/COM e.t.c штуки которые являются компонентами ОС Windows. И заместить их ничем будет невозможно. Или вы нарушите условия импортозамещения.

Где-то также читал статью одного из разработчиков старого офисного формата Word. Он признается что формат сложен даже для него самого.

Comments

[Adamos]

заменить их на 100% невозможно

Ага, но это и не нужно. Привычки кромешной работы в офисах - это прошлый век и техническое бессилие, в современных реалиях офис нужно не заменять на 100%, а выкинуть на 90%, заменить это колупание в файликах на CRM и вздохнуть с облегчением.