Comments 74
Чтобы пользователь с установленным на ПК десктопным Word смог работать с документом на другом ПК, планшете или смартфоне, ему понадобится установить ещё один редактор.
SSH? Зачем? Давайте лучше костылить веб приложение.
С телефона или планшета очень удобно по ssh что-то делать, тут не поспоришь!
sftp, webdav, samba. А вообще с телефона странно что текстовые файлы редактировать, что документы
С телефона в принципе не очень удобно работать в ворде. И если бы ворд поддерживал ssh, то не было бы никакой разницы в удобстве - редактируешь локальный документ или удаленный.
С телефона или планшета работать с текстом в принципе неудобно и бессмысленно, имхо.
ssh? в ворде? что?
Именно так, его там нет. Почему - не знаю. Зато они сделали MS Word Online.
ssh это в первую очередь терминальный текстовый доступ (ну не туннелирование же вы предлагаете)... вы имеете в виду текстовый терминальный редактор для MS Word, без gui?
Заходите по SSH, открываете diskedit, и редактируете вордовский файл как вашей душе угодно. Единственное, неудобно в уме zip-компрессию производить.
не, ну распаковать файл то можно и текст xml руками править
p.s. я кстати морочился разок таким..
мне интересно что имел в виду @GospodinKolhoznik
Большинство пользователей не умеют применять SSH, это всё же ближе к сильно продвинутым пользователям. Поэтому мы и остановились на веб-приложении, это решение не потребует массовым пользователям переучиваться, а сразу дает возможность делать так, как привычно. Возможно, это не идеальное решение, но как минимум, практически применяемое.
Ну дак делайте так что бы было удобно применять SSH даже домохозяйкам, зачем делать костыли когда можно делать архитектурно правильно! Понятно что массовое сознание недогоняет как должно быть правильно, а как делать правильно понимают только "продвинутые"....это как раз точка вашего роста (и жаль что вы этого не понимаете) - делать так как правильно, но при этом удобно для массового потребителя; именно так бы будете задавать тренд и отличаться от тех же мелкомягких. Но...нет...."мы копируем кнопачки..."
Не понятно, как именно вы предлагаете что-то "улучшить" с использование ssh. Вы предлагаете через него графическое приложение пробрасывать что-ли?
Веб-приложение против десктопа
...а также markdown/asciidoc/latex и прочий условный plain text в git против веб-приложений и десктопов =) Но не для "простых смертных", конечно.
Например, есть возможность интегрировать редактор в систему электронного документооборота. У нас самих такого модуля нет, зато есть много предложений от разработчиков СЭДО. Что во всей этой истории важно — пользователю из самой СЭДО выходить не надо.
Как часто работают в СЭДО? Нужно специально сохранять 2 документа — внутри карточки и тот, который хранится на локальном диске. Там же, на диске, его и редактировать. Потом отредактированный вариант прилагать снова в эту карточку, перезапускать повторное согласование и так далее. Сложно.
А если у пользователя есть СЭДО с интегрированным в него редактором Р7, он может непосредственно в СЭДО создать новый документ по шаблону, заполнить и отредактировать его, отправить на согласование, получить по нему обратную связь или уже согласованный файл. Затем пользователь принимает или не принимает замечания, переходит к финальному варианту и отправляет его на окончательное утверждение. То есть редактор тут как встроенный инструмент, который можно сразу использовать в работе.
До чего дошёл прогресс. Возможность создавать RTF документы в Lotus Notes/Domino была доступна ещё в 2007 году. Только документы готовили вне системы по банальной причине: лицензий ЭДО компании покупали гораздо меньше, чем в компании существует реальных авторов и рецензентов документов. Зачастую, клерк, грузящий документ в "карточку" не понимает сути документа, а только запускает его по определённому workflow, поэтому без отчуждаемых файлов - никуда.
Дык RTF же дико ограниченный. ЕМНИП даже таблицы простенькие не поддерживает.
Поддерживает вполне себе. Другое дело, Майкрософт хорошо наладил переход из RTF в DOC и сделал только видимость обратного процесса.
Мелкомягкие просто безальтернативно решили в DOC.
В первое время ещё как-то RTF поддерживался, но как-только DOC перестал вызывать головную боль, всех любителей RTF послали в путешествие.
Нашей основной целью было заместить Microsoft с учётом возможности совместной работы в вебе и соответствием всех требований ГОСТа.
В чем заключается соответствие требованиям в ваших продуктах ?
Имеется в виду ГОСТ 2.105-2019. В части нумерованных списков с нумерацией кириллическими символами, возможность вставки рамок документов у нас доработки выполнены. Остаются двойные рамки границ у ячеек в таблиц. Работаем и над этим.
Т.е. у вас "стили гвоздями прибиты": пользователь не может изменять тип шрифта, размеры шрифта, межстрочные расстояния, отступы и т.п.?
В части нумерованных списков с нумерацией кириллическими символами
Вы имеете в виду пропуск буквы ё в нумерованном списке?
возможность вставки рамок документов
Рамки и штампы по какой группе ГОСТ: 21 или 34?
Остаются двойные рамки границ у ячеек в таблиц
И всё? А как у вас с авто-нумерацией приложений (пропуск букв Ё, З, О)…
Стили меняются для каждого уровня, формат номера можно задать произвольный. Пропуски букв в списках выполнить можно. Все так же, как и в MS.
Пропуски букв в списках выполнить можно. Все так же, как и в MS.
Из коробки этого в M$ Office нет (или знают где это включается знают не только лишь все, намекните если знаете!). Приходится колхозить свои макросы, поэтому я и спрашиваю есть ли это у вас из коробки?
А рамки по ГОСТу тоже из коробки?
Это важно, что бы пользователь мог легко и свободно назначать каждому листу свой макет, как в PowerPoint для каждого слайда.
рамки по ГОСТу тоже из коробки?
Скорее всего соблюдается обратная совместимость...
Не очень соглашусь с концепцией, что автоматизация плагинов на JS это очень удачная во всём идея. Сам факт того, что вы не можете ничего сохранить на локальном компьютере, кроме как в localStorage, обрубает просто огромное число возможностей, которые есть в автоматизации MS Office. И выполнять любые действия с документом только из виртуальной песочницы основного потока плагина, да ещё и через ограниченное число возможных действий - тоже просто "выкручивание рук" разработчикам. Приходится очень не хило подумать, чтобы что то реально сложное в документе сделать!
И про СЭД тоже мне не очень ясно. Многие вопросы СЭД сможет решать только через вашу автоматизацию по API DocumentBuilder,и это так себе идея. Основная идея интеграции редакторов в СЭД не такая как вы описали, а в возможности распараллеливания подготовки документов, с минимизацией вводимых пользователям данных (DocFlow) непосредственно в офисном пакете, а потом уже идёт последующее автоматическое движение документов по разным пользователям на ознакомление и(или) согласование(WorkFlow). Если второе, к любому офису мало как привязано, то вот с первым у вас будет проблема. Интегрировать что либо именно в ваш офисный пакет извне, как это легко сделать в MS Office за счет их системы автоматизации СОМ+, практически нереально. А без этого, у вас остается только фискальная подвязка подготовленных документов к карточкам СЭД, а значит, уже совершенно тогда не важно, ваш офисный пакет используется, или любой другой.
Не очень соглашусь с концепцией, что автоматизация плагинов на JS это очень удачная во всём идея. Сам факт того, что вы не можете ничего сохранить на локальном компьютере, кроме как в localStorage, обрубает просто огромное число возможностей, которые есть в автоматизации MS Office.
Недавно была статья Как можно использовать .NET из Javascript (React) в 2023 году, в комментах автор писал
С точки зрения обработки файлов, формат файла Visio от других форматов Office ничем не отличается, т.е.OpenXml можно применять для обработки любых офисных документов. Здесь интересным является то, что оно нормально работает из WASM.
Упс, на компьютер ничего не сохраняется. Предлагает скачать архив)
Так тут вопрос не в том, как из JS использовать .Net код. У всех аналогов MS Office есть один существенный минус, который вытекает из их же плюса кроссплатформенности: в них почти нерально встроить свои расширения, которые бы могли работать с документом в полном объёме так как нет поддержки внешней автоматизации таких процессов. Если Microsoft эту задачу решил ещё 20 лет назад, и можно было за счет технологии COM спокойно делать удалённо (даже с помощью весьма примитивного VBS) с документами что угодно средствами самих редакторов, хоть в фоновом режиме, хоть с открытым редактором (и в Р7 и в МойОфис что то похожее есть, но опять же - на более упрощённом уровне, без открытия окна редактора и только чтобы создать документ и заполнить его по алгоритму). А значит, ни о какой интеграции СЭД и речи не идёт, пока нет конкретной переделки самого ядра редакторов именно в плане внешнего управления.
При этом мне лично очень странные потуги самих Майкрософт в продвижении JS плагинов, так как особо положительного кроме централизованного деплоя они не несут (и то, для работы нужен отдельный web сервер, да ещё и в конфигуратор плагина нужно вшить к нему путь!). А гемора в их написании ну просто полные штаны(например запросы к API при работе с документом асинхроные и надо это учитывать каждый раз при практически любых действиях в плагине и т.п.). Получился какой то даже не шаг, а прыжок назад!
Программное заполнение/изменение документа действительно доступно через компонент DocumentBuilder, что способно решить многие озвученные сценарии. Актуальность встраивания редакторов в СЭД подтверждается частыми запросами к нам со стороны разработчиков. Если звезды зажигают — значит это кому-то нужно :)
Когда уже сделают киллер фичу, чтобы можно было открыть в любой момент времени документ и Ctrl+z работал????
Мы же в своих продуктах используем именно стандарт OOXML, не дорабатывая и не дополняя его.
Т.е. всегда находитесь в слабой позиции догоняющего. и подстраивающегося под майкрософт.
Нашей основной целью было заместить Microsoft с учётом возможности совместной работы в вебе и соответствием всех требований ГОСТа.
В ГОСТе как раз ODF, вы путаетесь в показаниях.
OOXML — это стандарт, который иcпользует не только MS, но и вообще все редакторы. Если мы что-то делаем свое, то оно будет отдельным форматом, и работать будет только на наших редакторах без какой-либо обратной совместимости.
OOXML — это стандарт, который иcпользует не только MS, но и вообще все редакторы
Это неправда. Либре/Опен офисы, например, используют ODF, хотя и умеют работать с OOXML.
Если мы что-то делаем свое, то оно будет отдельным форматом, и работать будет только на наших редакторах
ODF, не надо писать своё. Он не имеет проблем OOXML и рекомендован к использованию ГОСТом. Выше вы заявляли "соответствие всех требований ГОСТа". Это тоже неправда была?
Подавляющее большинство документов в мире хранится именно в OOXML. Поэтому этот формат для нас приоритетный. ODF мы, кстати, тоже поддерживаем. Ну и ODF нормативно не закреплен в качестве единственного допустимого для использования в РФ. Наоборот, согласно ПП325, ODF и OOXML должны наравне поддерживаться для всех офисных пакетов, включенных в реестр отечественного ПО.
Вообще говоря, отсутствие ГОСТ на OOXML нисколько не умаляет того факта, что этот формат является открытым международным стандартом. Тут, как говорится, "на вкус и цвет... все фломастеры разные". Нравится ODF и Либра/Опен — используйте на здоровье.
Этот формат проприетарный и защищен патентами США. Какая разница, что там где хранится? Подавляющее большинство людей в мире говорит на китайском, а вы русский используете.
Нравится ODF и Либра/Опен — используйте на здоровье.
Да, для меня использование OOXML в качестве формата по умолчанию - жирный минус.
Р7 как полноценная платформа
Нам его собираются внедрять. Дали потестировать. Была попытка открыть на I3 текстовый файл со строками (тысяч 200 строк с разделителем пробелом в строке) в электронной таблице. Через пол-часа вся эта штука так и не открылась. Странно. Microsoft Excel открывал (хоть и не полностью).
Я балдею, это ж какой воспаленный мозг придумал генерировать такого размера таблицы? Ну базы ж данных для таких вещей люди придумали...они и обрабатываются многократно быстрее.
В таких случаях говорят: "Мусье знает толк в извращениях!"
чтобы базу данных на любой чих делать, это никаких денег и квалификации персонала не хватит
очень часто случаются кейсы когда надо искать расхождения в продажах...и брать сеньора dba и погромиста чтобы он из 5 систем выгрузил в БД данные и помог девочке экономисту правильный запрос в sql написать, вместо того чтобы открыть огроменный эксель и натыкать мышкой пару фильтров с формулами? да он огромный, но это займет 15 минут от силы..и девочку учить как в БД создавать таблицы и грузить туда данные не нужно
по моему опыту, sql знает полтора человека из отдела экономистов
Экономить на квалифицированном персонале при таких объемах обработки (напомню файлик 200 тыс строк)...ээээ....ну такое себе. Либо руководитель идиот или скоро его сменит более грамотный, тот который адекватно задачам будет использовать инструментарий. Для каждой задачи существует свой инструмент, я не говорю что екселевский файлик плохо, я говорю о том что под каждое решение должен исполььзоваться свой "гаечный ключ". Здесь мы видим как гайку на 40 пытаемся откручивать ключиком на 13. Рано или поздно это вылезет боком или исполнителю или руководителю, смотря кто в данном случае придумал эдакое. На раз или два проканает, но на постоянку - врятли.
Экономить на квалифицированном персонале при таких объемах обработки
(напомню файлик 200 тыс строк)...ээээ....ну такое себе. Либо
руководитель идиот или скоро его сменит более грамотный, тот который
адекватно задачам будет использовать инструментарий
если все будут так рассуждать, то у нас ни одного рабочего бизнеса не останется
я вот видел такой пример из жизни обычного подмосковного совхоза где я подрабатываю
1) отгрузки из десятка юрлиц в сторону федеральных ритейлеров, много отгрузок...мноого
2) контора существует более 40 лет
3) периодически возникают расхождения...и если сил запросов 1С (7.7 кстати ТиС, антиквариат) не хватает, выгружают реестры в эксель и сверяют там... опенофис кстати на их файлах сказал ой...и "не шмогла" (с) ... их хитросплетения формул и данных переваривает только MSO и без вариантов
4) никаких SQL, специализированных БД и т.п.
5) контора существует много много лет и еще нас переживет
6) "денег на софт, разработчиков и админов - нет, мы лучше трактора закупим" (с)
Еще? завод по производству воды, продукцию этого завода можно в любой пятерочки встретить по всей стране, учет в 1С УПП, оперативные сверки данных менеджеры делают опять таки в экселе..просто потому что это быстро и просто. совсем прям сложные вещи которые надо делать с какойто перидичностью - я им сам отчеты уже в 1С делал кастомные
Ну и мой любимый пример (тут я соглашусь с вами правда по итогу)
Европейская компания (наверное уже не работает в РФ) по производству биоразлогаемой упаковки, у них учет был в 1С и оперативный учет в экселе...причем такой...что даже в экселе делали отчеты по МСФО...это была просто монстроподобная конструкция из десятка эксель файлов и VBA скриптов...и работало!! два бухгалтера на всю РФ документы там обрабатывало
Собственно вот это реалии жизни, а не сферическивакуумные рассуждения о том как надо...как надо мы все знаем, а как есть - вот так.
я говорю о том что под каждое решение должен исполььзоваться свой "гаечный ключ".
если деньги есть и это экономически окупается
зачастую экономически выгоднее в экселе посчитать чем потратить 50 лямов на зарплату ИТ отдела с сеньорами с зарплатой 10килобаксов в секунду
А картофан в совхозах возят на жигулях? Мноого жигулей можно взять и перевезти. Если каждый фуру нанимать дорогую будет, у нас ни одного рабочего бизнеса не останется...
Фурами возят конечно, мнооого жигулей это очень большие накладные расходы на водителей и ремонт жигулей...у одной фуры пробег под несколько млн, а жигули на 100тысячах уже развалятся...это прямое влияние на бизнес
ИТ это вспомогательный сервис, он не приносит прямого дохода и влияет на бизнес лишь коственно
От того что девочка с зарплатой 30тыр будет считать отгрузки 10 минут или 3 часа для ежеквартального отчета, картошки больше продаваться не будет
там уже внедрили 1С в далеком 2005 году, из-за чего сократили бухгалтерию с 30 человек до 6..дальше их сокращать тупо некуда, совхоз просто большой со штатом 300-500 человек, дальнейшая автоматизация просто нецелесообразна...ввалить несколько лямов на то чтобы сократить 2х человек и поднять зарплату ИТшникам до рыночной? (т.е. затраты только возрастут) никто не будет так делать
или предлагаете картошку перебирать девочек из офиса отправить, если они там свои дела закончили с отчетами? :)
ИТ это вспомогательный сервис, он не приносит прямого дохода и влияет на бизнес лишь коственно
Он сокращает издержки.
От того что девочка с зарплатой 30тыр будет считать отгрузки 10 минут или 3 часа для ежеквартального отчета, картошки больше продаваться не будет
Вот в этом и беда. Пока будет махровая нищета и девочки, согласные работать за меньше чем $2 в час, никто автоматизацией заниматься не будет. Это как раз понятно.
Он сокращает издержки.
и создает новые, я описал ситуацию когда создание современной и правильной системы будет более затратным и не принесет роста прибыли
выгодно внедрять софт для построения логистики, по ЭДО, по управлению складами ... это кстати всё делается, а ускорение экономических расчетов - это неокупаемые затраты
Вот в этом и беда. Пока будет махровая нищета и девочки, согласные
работать за меньше чем $2 в час, никто автоматизацией заниматься не
будет. Это как раз понятно.
ну тут бизнес как раз таки не виноват, это любимый капитализм и рынок (я вообще не против такого)
а вообще, по поводу затрат на ИТ ради эффективности, могу напомнить историю платежных систем в США, где МПС не могут заставить банки поменять терминалы...хотя это же повысит охват улучшит безопасность и т.п.... а глупенькие владельцы бизнеса не понимают зачем им тратить деньги за замену терминалов..когда и старые хорошо работают..
вон в РФ как хорошо, пригрозил отзывом лицензии, продавил закон об обязательном внедрении карточек в магазинах и кайфуй...зато всё современно и по феншую...бизнес? ну они торгаши, раскошелятся ;))
Ну, я не говорю, что кто-то виноват. Просто требовать от табличного редактора, чтобы он перемалывал сотни тысяч строк с такой аргументацией неправильно. Для этого существуют другие инструменты. Вы же не требуете электротяпки, а покупаете трактор, когда вам нужно большие объемы вскопать. А можно было бы сказать, что, что вы не хотите платить трактористу по рынку, а девочек нищих у вас вагон, которым трактор слишком сложно, а электротяпки в самый раз.
ну это то понятно, тут вопрос скорее в том что
MSO - может так
OOo (и ктото еще) - не может
просто вот исходя из этого, это вот как ты владеешь феррари, там 500лошадок и скорость 500кмч, и тут приходит конкурент - мы делаем точно такиеже авто! садишся, а там 75 лошадей и скорость 110кмч от силы...и ты типа "ну как же?" - а тебе - а вам просто не нужно столько, в городе запрещено ездить быстро и вообще спешить вредно
вы понимаете что это подмена понятий уже? вы оправдываете отсутствие функционала тем что он "вам не нужен", это как в эппл - убрали бекспейс на клавиатуре - потому что он не нужен - жмите shift-delete все жмут и не жалуются
не дело производителю текстового редактора - указывать как его клиенту бизнес вести ;)
Представьте, что вы исследуете/калибруете прибор. Этот прибор присылает массу параметров которые очень просто и легко можно записать в простейший текстовый файл построчно. Затем этот файл вы можете как угодно обрабатывать хоть в матлабе, хоть в экселе, хоть как угодно.
Нам начали внедрять. Что сказать... Конечно, "Не мартини, не мартини"... но с задачами справляется.
Были кейсы с производительностью, с работой с большими файлами. Но если всё-таки не пытаться "на Оке увезти 3 тонны цемента", то вполне себе.. Да, есть нюансы. Но всё решаемо, если есть желание.
Мы отходим от парадигмы "Вся аналитика и мега-расчёты делаем в Excel".
Вся аналитика и мега-расчёты - в ИС. Таблички - для готовых отчетов.
Заноза только с VBA. но и это решаем.
Убьёте меня сейчас — текстовые редакторы и так из пятикилобайтных превратились в пятигигабайтное безумие, и это чисто для плейнтекста, а тут я ещё идей подкидываю.
Но.
Был у меня вычурный случай, когда мне хотелось бы в плейнтексте совместить несколько разных кодировок в разных строках. Я немного подумал, как можно это сделать, не нарушая самого принципа плейнтекста, и понял, что это можно сделать, задавая в настройках разные кодировки для строк, заканчивающихся на CR, LF и CR/LF.
А теперь можете убивать.
Статья про текстовые процессоры, а в заголовке редакторы.
Интересно, обычный ипользователь использует хотя бы процентов пять функционала этих монструозных тестовых процессоров?
Я до сих пор встречаю документы, где отступы, межстроковые интервалы и центрирование делают пробелами :рукалицо ))
Текстовый процессор и текстовый редактор надо различать. Ворд и сотоварищи - текстовые процессоры.
Впрочем, текстовые редакторы сегодня зачастую тоже довольно грустно выглядят зачастую - те, которые с использование чего-то типа электрона лепят. Мало что умеют, зато выглядят стильно и молодёжно и весят полтонны.
В принципе, по функционалу они уже мало в чём уступают основному конкуренту от Microsoft (по крайней мере, массовому пользователю).
А когда появится автоматическая расстановка переносов слов?
В целом неплохой офисный пакет, однако ваши таблицы просто катастрофически проигрывают Excel и Google sheets из-за отсутствия поддержки динамических массивов. Без этого современный табличный процессор - не современный табличный процессор.
не знал, что Р7 - это форк лексикона, не знал....
Первое — мы сделали гладкую обратную совместимость с документами MS Office
Пока это выглядит как "мы открыли документ, но надо доработать напильриком". Абсолютной идентичности вида документа в MS Office и Р7 достичь не получается.
Открывая в Р7 чужие документы из MS Word, часто вижу поплывшие разделения страниц. И чтобы это доверстать до нормального вида я потрачу столько времени, что мне проще пересесть за комп с установленным MS Office либо вернуть документ автору на переверстку в Р7.
Здравствуйте, совместимость с документами MS Office, ещё как то работает, а вот создать текстовый документ Р7 в телефоне, вообще нереально, не изменив размер шрифта, текст очень мелкий, какие-то проблемы с масштабированием, такое ощущение, что разработчики сами никогда это не делали. У меня к автору вопрос, сможете ли Вы поработать с документами MS Word в мобильной версии, с телефона, ежедневно в течении недели (редактировать, писать регламенты, вставлять картинки, вообщем-то делать простые задачи), а потом написать статью, о своем опыте и как массово привлечь пользователей в Р7
Во что превратились текстовые редакторы