Комментарии 46
Если бы у onlyoffice был электронный документооборот вы убили бы sharepoint! Посмотрите в сторону ельмы бпм! У вас вполне готовая экосистема для полного покрытия стека enterprise!
НЛО прилетело и опубликовало эту надпись здесь
OOXML не запрещает писать данные в ячейки, «скрытые» при помощи merge. Microsoft просто не предоставляет такой возможности в интерфейсе, как и мы. OpenOffice же предлагает выбор. Поэтому у нас не возникает проблем при конвертации таких файлов.
Про формулу ="" не совсем понятно, что имелось ввиду, у меня во всех редакторах ошибка "#VALUE!".
Про формулу ="" не совсем понятно, что имелось ввиду, у меня во всех редакторах ошибка "#VALUE!".
Странно сравнивать проприетарное решение и OpenSource. ИМХО, Ваш главный конкурент гугл докс. С ним и нужно сравнивать.
Пробовал OnlyOffice десктопный, который без сервера — оч. понравился, и у меня вопрос — автоматической расстановки переносов нет вообще или только бесплатной бессерверной системы? И если планируется, то в насколько дальней перспективе? Очень злободневно для написания документации.
Collabora лучше, чем ONLYOFFICE открывает документы OpenDocument, но гораздо хуже открывает OOXML (docx, xlsx, pptx).любой документ docx, xlsx...?
хорошо бы «типичные» примеры документов выложить, что бы можно было судить — насколько критично это «хуже»
А если кто-то откроет документ в 700 страниц — ещё минус 1,5 Гб.
Вы считаете, что обрабатывать документы такого размера, что на сервере, что в браузере, это здоровая практика?
Проясните Вашу позицию по способам обработки документов подобного размера, она не понятна. Каким образом можно продуктивно использовать универсальный инструмент для создания и поддержания таких документов.
Практика нездоровая. Но одно дело так напрягать клиент (собственно и открывший этот документ), а другое сервер.
НЛО прилетело и опубликовало эту надпись здесь
После приведенных примеров, чем браузер хуже спец.редактора?
Не правильно задан вопрос. В данном случае спец редактор располагается либо на сервере либо в браузере, ну да ладно. Суть дела в другом. В случае с такими большими документами плох сам подход, негодный выбор технологии. Поясню подробнее.
Какая идеология заложена у MSO. Он ориентирован на обработку информации которая быстро теряет свою актуальность, такие данные используются в первую очередь в финансово-экономической области, где жесткие сроки по отчетности, информация меняется непрерывно. Вот цепочка действий на которую «заточен» MSO: access в качестве коннектора/прокси/словарей для извлечения данных из большой БД -> exel для анализа данных -> word для составления заключения -> powerpoint для наглядного пояснения сути дела начальству -> outlook для рассылки и обратной связи.
OpenOffice более заточен для создания научных статей, период актуальности информации существенно больше, данные меняются намного более медленно, провел эксперимент записал, следующий эксперимент когда ещё будет. Поэтому open/libre office сильнее с стилями оформления, но слабее с таблицами, информация меняется редко, частые смены не актуальны.
Данные аспекты в разнице предметных областей вообще никак не учитываются, но и это ещё не все.
Документ в 700 страниц, согласитесь, это фактически книга. А к написанию и изданию книг человечество выработала другой подход, другие технологии. В издательском деле актуально разделить действия на группы текст, художественное оформление, корректура, верстка, печать. Такой подход доказал свою состоятельность. А что мы имеем здесь, каша, все свалено в одну кучу.
Именно поэтому я и просил разъяснить позицию автора, непонятно зачем смешивать вместе, в чем суть такого смешения.
НЛО прилетело и опубликовало эту надпись здесь
Это может быть тупо выписка из реестра (тысяч сто строчек из экселя, которые нужно вставить в вордовский документ по требованию заказчика, реальный кейс из оценки). Объем страниц ничего не говорит про содержимое.
Вы имеете в виду автоматизированную обработку текста из OLTP отчета. И что с этим будет дальше? Я не соглашусь с Вашим утверждением «Объем страниц ничего не говорит про содержимое.» Такой объем очень плохо пригоден для восприятия человеком. Этот документ формальная отписка, по правилам она скорее всего нужна, возможно даже она будет использована 1-2 раза. Но в таком состоянии это не годиться для повседневного использования, тут мы имеем дело с вариантом исходных данных необходимых для дальнейшей обработки в формате msword, упрощенно это заготовка, полуфабрикат.
И как это связано к изначальному:
Мне, да и большинству людей не нравятся плохо сделанные вещи, плохо сверстанные книги, не нравятся документы которые сделаны для того что бы запутать и не показать содержания. Если Вы, например, условно допустим, отрицаете правила типографского и издательского дела, то Вам будет гораздо сложнее создавать удобные для использования документы больших размеров. У Вашего Заказчика может появится негатив, если приведенный выше документ будет плохо сверстан из-за нарушений закономерностей восприятия. Это в итоге скажеться на материальной оценке Вашего труда. Так что связь есть и она ощутима.
То есть изначально вас интересовала работа именно на сервере или в браузере, а сейчас вы рассуждаете об заточенных под конкретную задачу решениях. А что мешает те же решения реализовать на сервере или в браузере, мне не понятно? Ну вот будет у нас в бразуере десяток решений отдельно для оформления, отдельно для корректуры, отдельно для верстки и т.п. — в чем проблема? Тут в браузере даже фотошопы реализовывают, что, тоже запретить?
Меня изначально интересовала полезность предлагаемого инструмента для работы. И выясняется, что никто на настоящий момент не сумел показать идеологию и ценностную сущность предлагаемого решения для конечного потребителя, ни для коротких документов, ни для больших. Получается следующее. Про MSoffice мне понятно, про Libre/open office понятно, про google docs тоже понятно, а для чего ONLYOFFICE сделали не понятно, про то где его целесообразно применять молчат. Какое уж тут сравнение форм и платформ, тут про полезность ничего толком рассказать не могут. В общем ждем продолжения статей, очень много неясного.
Что касается вашего вопроса о проблеме специальных инструментов. Проблема заключается в том что бы превзойти уже существующие, дать что то более совершенное, аналог уже не привлекателен. В этом главная сложность.
НЛО прилетело и опубликовало эту надпись здесь
Поэтому то, что вы тут рассуждаете, что раз 700 страниц, то нужен спец.инструмент — это всего лишь ваша предубеждение, которые вы позиционируете, как единственно верное.
Ответ был, для массового использования непригодно. Об этом свидетельствует опыт издательского и типографского дела за несколько столетий.
У онлиофиса ровно тоже самая целесообразность, что у мс офиса, а либро/ооо, гугло доков и прочих, прочих, прочих. И ровно та же полезность.Вы либо заблуждаетесь не осознавая разницы, либо «лгать изволите». То что вы подготавливали рукописи в MSword не является достаточным опытом для сравнительной оценки этих иструментов. Этого крайне мало. Если бы сравнили подготовку в msoffice и libre толкового аналитического отчета по товарной группе за короткий период, актуальность которого «протухнет» через 10 дней, Ваша реакция была бы иной, совсем иной.
Можно взять другую область, подготовку технической документации по требованиям ЕСКД со всеми её согласованиями и утверждениями. Люди ночуют на работе, поскольку верстка «слетает», и на каждое добавление рисунка или абзаца приходиться полностью переверстывать документ. Только не берите в интернете шаблоны для учебных работ, нормоконтроль признает их непригодными и не допускает документ к утверждению.
И msoffice и libre и google docs отличаются не только внешним видом и функционалом их главное отличие в направленности на различные профессии и группы пользователей. У меня ребенок пишет свои учебные работы в google docs, для него нет разницы между google docs и msoffice, в google docs предпочтительнее немножко меньше возни. Если Вы будете предлагать использовать google docs экономистам и бухгалтерам, Вы моментально заработаете репутацию неадекватного человека разрушителя.
А так конечно, во всех случаях можно вставлять буквы, таблички и рисунки, на первый взгляд все все делают одинаково, разница минимальна. Только реакция потребителей почему-то полярная.
И немного off top. То что Вы пишете книги это здорово. Попробуйте любопытства ради испытать «сладкую парочку» LATEX+Revision Control System, только попросите что бы Вам это установили, настроили и помогли понять как это работает. Это сложнее ворда на начальном этапе, но если «распробуете», Вам понравиться.
Редактировать документы нужно в десктопных редакторах (LibreOffice, MSOffice и т.п.).
Браузер должен служить только для отображения веб-страниц (новости, интернет-магазин, форумы и т.п.).
Использовать браузер ДЛЯ ВСЕГО-НА-СВЕТЕ (в том числе, чтобы плодить корпоративных рабов) — 1) негуманно, 2) уродливо.
У меня всё.
Редактировать документы нужно там, где это удобно и эффективно. Рынок предлагает разные варианты, для разных потребностей и вкусов. Может быть в итоге останется только один, но вряд ли это будет десктопное приложение, запускаемое на локальной машине пользователя.
НЛО прилетело и опубликовало эту надпись здесь
Сделайте ещё сравнение с МойОфис (Collabio Office)
Вот кстати, если вы всерьёз хотите конкурировать с MSOffice, позаботьтесь о том, чтобы работали клавиатурные сокращения. Я пытаюсь пользоваться таблицей DesktopEditors, но мне очень не хватает Ctrl+1, Ctrl++, Ctrl+-, Ctrl+D и т. д.
Доработка копеечная, но очень поможет в пересадке пользователей, особенно опытных.
Доработка копеечная, но очень поможет в пересадке пользователей, особенно опытных.
Когда тестировали был шок, что Ваш продукт рассылает письма сотрудникам с рекламой.
Ну то есть он у нас живет своей жизнью, что то сам там делает, пишет письма и прочее (а вот что прочее??).
Это руководству сразу не понравилось и была поставлена точка.
Ну то есть он у нас живет своей жизнью, что то сам там делает, пишет письма и прочее (а вот что прочее??).
Это руководству сразу не понравилось и была поставлена точка.
В Collabora обработка всех действий от пользователя происходит на сервере, в ONLYOFFICE — на клиенте.я не считаю это недостатком
все зависит от организации взаимодействия с сервером, с случае с ONLYOFFICE взаимодействие тоже необходимо
Collabora работает медленнее, это издержки архитектуры.может издержки конкретной реализации?
Давайте представим, что к-л продукт «грамотно» рендерит ту часть, с которой работает пользователь и не тянет весь контент на клиента, и не занимает место в памяти сервера, размещая там весь документ. Сервер будет «знать» — с какими частями работает «какой» клиент
В случае с клиентским кодом, если надо вытянуть весь док на клиента и потом его синхронизировать с состоянием на сервере..., мне кажется — куча доп. работы и нагрузка на каналы
Как пример… Сейчас наблюдаю работу «документооборота»..., в его реализации есть локальный клиент, мало того что от отжирает 300 Мб памяти, еще без к-л деятельности, он еще и документы «пописывает» на стороне клиента, а для этого — выгружает док сервера/подписывает/загружает. Для объемных документов — это жутки тормоза и время ожидания.
Второй момент: при открытии/закрытии документа одним клиентом, состояние блокировки не всегда обновляется корректно на сервере (возможно из-за сетевых задержек), как результат — другой клиент не может «ничего» сделать с этим документом и 1-му надо закрыть все приложение!
Мы считаем, что чем меньше нагрузка на сервер — тем лучше. Так как если пользователь работает с документом — странно передавать (через сервер) эти тормоза человеку, который работает на этом же сервере, но с другим документом. Много людей — потребуется много серверов, а это не выгодно. И, по-нашему мнению, Collabora так поступает лишь по одной причине — потому что у них нет браузерного редактора. И совместного редактирования тоже нет. И был выбран максимально простой вариант — открывать Либру на сервере и транслировать мышь и клавиатуру пользователей. Рабочий вариант, никто не спорит. Но уж точно не «грамотный».
Collabora так поступает лишь по одной причине — потому что у них нет браузерного редактора. И совместного редактирования тоже нет. И был выбран максимально простой вариант — открывать Либру на серверев приведенном куске вами «осуждался» подход к обработке на сервере
Еще момент: не факт, что либра не сможет, в будущем, предоставлять более гибкие средства взаимодействия (в контексте запуска отдельных процессов и оверхеда по памяти)
Нагрузка на сервер, безусловно, важна и если разбирать Collabora и либре — есть куда стремиться. Но упор на преимущество подхода «исполнения на клиенте», для меня, не звучит убедительно
Добавим тезис о популярности docx и прочих проприетарных форматов…
Ситуация: фирма1 присылает фирме2 документ на согласование/правку, в большинстве случаев согласовывают содержание, а не форму. Учтем еще — каждая организация имеет свой свод «корпоративных» стандартов. Конечный документ будет не в редактируемом виде (скорее-всего хардкопия) и в электронном виде — PDF вполне кандидат на данную роль. Как у вас обстоит дело с сохранением верстки при конвертации в PDF средствами ONLYFFICE?
Меня вполне устраивало качество конвертации docx в PDF либрой (с учетом граблей оформления в МСО)
Т.о. интересуют возможности оформления документов (присутствующие в продукте), а не формат. Выходной формат, самый распространенный — PDF
У нас четкое разграничение в редакторах. Логическая (форматная) часть -> измерение -> отрисовка. И сохранение в пдф — это просто подмена отрисовщика на канве/нативного на сохранялку в пдф. Поэтому сохранение в пдф 1-в-1 так, как вы видите в редакторе документ. Согласен на 100%, что если файл не для редактирования и его надо передавать — то только PDF. Чтобы со встроенными шрифтами и без багов/особенностей измерятеля.
НЛО прилетело и опубликовало эту надпись здесь
Файл, выгруженный из БД, csv, 4.5 мегабайта. Ни оформления, ни формул. 5 тысяч строк, около 30 полей.
LibreOffice: 35 мегабайт ОЗУ
ONLYOFFICE: 240 мегабайт ОЗУ (потребление браузера)
Collabora: не открыл файл. Файлик поменьше сожрал 190 метров (потребление браузера).
Потребление бэка на демо-доступах не отображалось.
Веду учет расходов в onedrive табличном редакторе. Примерно на двух тысячах строчках оно начинает лагать. В результате стал делить на периоды, не реже чем раз в год начинать новый лист.
LibreOffice: 35 мегабайт ОЗУ
ONLYOFFICE: 240 мегабайт ОЗУ (потребление браузера)
Collabora: не открыл файл. Файлик поменьше сожрал 190 метров (потребление браузера).
Потребление бэка на демо-доступах не отображалось.
Веду учет расходов в onedrive табличном редакторе. Примерно на двух тысячах строчках оно начинает лагать. В результате стал делить на периоды, не реже чем раз в год начинать новый лист.
Подскажите, проблема с установкой owncloud/nextcloud + onlyoffice на одном сервере уже отсутствует? Пробовал весной(вариант с docker контейнером) — так и не удалось завести, с советами на форуме Onlyoffice. Поставил тогда же Collabora по родному мануалу и заработало сразу…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ONLYOFFICE против Collabora: почему мы уверены, что наше решение лучше