ONLYOFFICE против Collabora: почему мы уверены, что наше решение лучше

    Здравствуйте! Команда ONLYOFFICE возвращается на Хабр, как мы и обещали. Постараемся писать чаще и больше, и вообще держать вас в курсе событий. В последнее время нам есть что рассказать и показать.

    Тему первой статьи подсказала нам сама жизнь. Не так давно наравне с вопросом: «А чем вы лучше Google Docs?» нам начали задавать вопрос «Ну и чем вы лучше Collabora?». Это связано с нашей интеграцией с сервисами ownCloud и Nextcloud, официальным партнером которых как раз таки является Collabora.

    Если говорить о преимуществах, то у Collabora есть перед нами очень большое — идеологическое. Оно заключается в том, что этот продукт является продолжателем дела OpenOffice и LibreOffice. Непросто бороться с ними за пользователей, но у нас есть весомые аргументы в свою пользу. Сейчас расскажем.



    Где редактор? Краткий экскурс в анатомию Collabora и ONLYOFFICE


    Collabora — это представление редактора, открытого на сервере, в вашем браузере. И этот редактор — LibreOffice. Во многом поведение Collabora напоминает «тонкий клиент», потому что у вас на компьютере почти ничего не происходит. Всё волшебство происходит исключительно на сервере. Правда, есть одно отличие — Collabora не выглядит в точности как LibreOffice, у неё есть собственный интерфейс (мы вернемся к нему позже).

    В ONLYOFFICE мы стараемся задействовать именно ресурсы клиента. То есть, редактор действительно работает у вас в браузере, просто периодически он обменивается данными с сервером. Если в Collabora на сервере происходит чуть более, чем всё, то у нас на сервере происходит всего несколько процессов, в числе которых сохранение, конвертация и проверка орфографии. Это позволяет экономить ресурсы сервера и работать быстрее.

    Об отрисовке и наборе текста


    Заметить, как устроена отрисовка в Collabora несложно. Страница разбита на блоки, это позволяет ей загружаться быстрее (вы же помните, что эти картинки вам приходят с сервера?). Но интернет — штука хитрая, поэтому некоторые из них могут подгружаться медленнее или не прогружаться совсем. Нам при тестировании этого продукта доводилось смотреть на серые пятна.

    В целом устройство Collabora предполагает некоторое природное замедление: редактор находится на сервере, он оторван от пользователя. Тот курсор, который мы видим на экране, на самом деле, не тот курсор, который стоит в редакторе. Между ними есть задержка — отправка координат. Вы видите просто картинку из редактора.

    ONLYOFFICE — это полноценный редактор в браузере. Мы полностью обрабатываем все события пользователя на клиенте и отправляем информацию о них на сервер. Получается гораздо оперативнее.

    Функциональность: о потенциальном и реальном


    Наследие LibreOffice — это значительное преимущество Collabora. Её разработчикам не надо писать все функции заново, у них автоматически есть всё, что есть в Libre. Другими словами, оглавление* у них было раньше, чем сам продукт (с 2003-го примерно).

    *и тут вы 100% вспомните нам, что у нас вот, например, нет оглавления до сих пор. Мы советуем вам быстро это сделать прямо сейчас, пока не поздно. Потому что жить этой претензии осталось недолго.

    На самом деле, радоваться всё равно рано: мы уже упоминали, что у Collabora свой собственный веб-интерфейс, и в него пока протащили далеко не всё. Вы не можете добавить не то что оглавление, но даже банальную автофигуру или диаграмму. В общем, несмотря на то, что открытие документов у Collabora сейчас на уровне десктопной Libre, возможности редактирования у неё пока исключительно базовые. Потому что, видимо, нет функциональности — нет проблем*

    *но мы пошли другим путем

    Знаете, бывают такие мероприятия, где мы представляем редакторы ONLYOFFICE и нас спрашивают что-то вроде: а можно ли у вас поменять шрифт или выделить текст жирным? Мы расстраиваемся и просим дать нам задачку потруднее, потому что давно прошли этот этап — добавили все возможные объекты, красивые диаграммы, работу с автофигурами и формулами. Сейчас доделываем оглавление, сводные таблицы (они сейчас открываются только на просмотр) и цифровую подпись.

    Проблемы с совместимостью в наследство


    Здесь всё понятно: Collabora получила в качестве наследства все проблемы и баги Libre. И главная проблема тут — плохая совместимость (очень) с форматами Microsoft. Как мы помним, то, что майкрософтовские форматы OOXML (docx, xlsx, pptx) — родственники форматов OpenDocument, не прибавляет им совместимости.

    Хотя, конечно, если вы и все, с кем вам доводится работать, остаетесь верны ODF, то для вас это не будет проблемой. Это будет проблемой для тех, кто откровенно предпочитает Microsoft, или же работает с широким кругом документов из разных источников. Им (особенно первым) Collabora не подойдет.

    Напомним, что большинство документов на этой планете привязано к docx, xlsx и pptx. Как бы мы ни восхищались открытыми офисными пакетами, Microsoft — по-прежнему мировой лидер и их редакторы по-прежнему стоят повсюду и сохраняют документы именно в такие форматы с 2007 года.

    В ONLYOFFICE мы используем форматы docx, xlsx и pptx в качестве базовых, потому что мы хотим отлично открывать большую часть документов, а не меньшую. И да — мы точно откроем такие документы в миллион раз лучше, чем Collabora (и Libre). Это наша работа, мы специализируемся на этих форматах.

    Работаем ли мы с ODF? Да, но конвертируем. И качество конвертации постоянно растет.

    Архитектура: почему использовать Collabora — это дорого?


    В основном потому, что она задействует ресурсы сервера. Это главный минус того, чтобы просто запустить на сервере редактор и всех к нему подключать. В конце концов, если бы это было выгодно, то эту схему давно использовали бы Вы-Знаете-Кто*.

    (*Microsoft)

    Поясним: вы открываете документ и он занимает 500 Мб памяти (и при этом еще может увеличивать расход в процессе форматирования). Потом ваш коллега открывает свой документ — ещё минус 500 Мб памяти. А если кто-то откроет документ в 700 страниц — ещё минус 1,5 Гб. Сколько памяти и серверов вам потребуется, чтобы покрыть потребности своей команды? Можно посчитать: если у вас два ядра и два гигабайта памяти на каждое из них, то вам хватит этого на 8-10 человек. А если у вас еще +8-10 человек, то вам уже нужен второй сервер.

    Можно пытаться что-то оптимизировать, например, использовать одно общее ядро для запуска, но документ все равно записывается в память — в память сервера в случае Collabora.

    Схема, которую выбрали разработчики Collabora, просто пожирает ваши ресурсы. Если у вас большая компания, то с таким офисом вам придется заниматься исключительно серваками: их потребуется много и необходимо будет постоянно балансировать между ними нагрузку, потому что клиенты не должны мешать друг другу (но они будут).

    Возможности балансировки не бесконечны, хотя бы потому, что в такой схеме клиент привязывается к серверу. Главная привязка тут — совместное редактирование. Например, вы приглашаете коллегу присоединится к редактированию отчета, над которым вы сейчас работаете. Отлично, но в схеме Collabora ему нужно зайти в тот же редактор на том же сервере, на котором вы сейчас. И неважно, что на нём ещё 10 человек правят свои документы, понимаете куда мы клоним? Вы будете мешать друг другу и всё будет тормозить.

    Конечно, в Collabora пытаются как-то нивелировать это всё и экономить память. Например, вы можете заметить, что открытый документ, который вы некоторое время не трогаете, становится неактивным. Пока он неактивен, там не проходит автосохранение, изменения не подгружаются. Экономия.

    Архитектура ONLYOFFICE: почему это оптимальнее?


    Потому что мы используем вычислительные ресурсы клиента, а не сервера. Конечно, мы расходуем серверные ресурсы тоже, но в существенно меньшей степени, чем Collabora. Связь между клиентом и сервером поддерживается, но незначительная. Тестирование (и практика) показывает, что на сервере (возьмем, например, с процессором семейства Intel Core i5) с развернутым ONLYOFFICE мы комфортно может позволить себе 75 пользователей (точнее, 75 открытых вкладок с редакторами) на ядро.

    Таким образом, на гипотетической машине с двумя ядрами в Collabora смогут работать только 8-10 пользователей, а в ONLYOFFICE — 150.

    Совместное редактирование: боль или радость


    В Collabora появилось совместное редактирование. Оно основано на том, что редактирующие заходят в один редактор на одном сервере. С этим связано вот какое неудобство: есть вещи, которые включаются для всего документа. То есть, если вы вдвоем в документе в Collabora и кто-то включает Track Changes, то Track Changes включается для всех. И вы не сможете этого избежать. Возможно, поэтому в Collabora пока нет непечатаемых символов.

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

    Что вы хотите сделать, когда нажимаете undo?


    Другой момент в совместной работе в Collabora — устройство undo/redo. Вот вы что хотите, когда нажимаете ctrl-z? Предполагаем, что, как и любой здравомыслящий человек, вы хотите отменить СВОЁ последнее действие. Посмотрим, как устроена undo в наших редакторах, чтобы понять, сможем ли мы достичь этой цели.

    В Collabora undo/redo сквозное для всего документа. Рассмотрим ситуацию:

    Пользователь 1 вводит букву «А»
    Пользователь 2 вводит букву «Б»

    Пользователь 1 хочет отменить букву «А». Он не сможет это сделать. Кнопка Undo будет активна только у второго пользователя, потому что последнее действие принадлежало ему. В общем, бедняга Пользователь 1 так и не сможет отменить своё последнее действие, пока Пользователь 2 не отменит своё последнее действие, то есть букву «Б». Это означает, что в Collabora нет разницы, совместное редактирование или нет, главное — откатывать изменения в той последовательности, в которой они поступали в документ.

    Благодаря такой схеме undo/redo рождаются такие магические моменты, когда вы вроде бы ничего не делаете, но при этом в тулбаре происходят изменения: как, например, у Пользователя 1, когда Пользователь 2 отметил букву Б, сразу стала активной кнопка undo. Вроде бы пустячок, а получается как будто то, что происходит у вас в редакторе, зависит не от вас, а от каких-то внешних факторов.

    Что касается ONLYOFFICE, то вы сможете отменить своё последнее действие в любом из режимов совместного редактирования (у нас их два, подробнее в этой статье). Как нам это удается? В основном, потому что мы почти всё делаем на клиенте. Там же хранится список действий — не только своих, но и чужих. Свои собственные действия помечаются, чтобы потом была возможность их откатить. Сервер при этом используется как база данных, с помощью которой мы синхронизируем правки на клиентах. Технические подробности реализации мы уже описывали вот тут. Самое главное отличие реализаций undo/redo — у нас оно работает «от пользователя», а у Collabora — «от документа».

    Краткие выводы


    • Collabora лучше, чем ONLYOFFICE открывает документы OpenDocument, но гораздо хуже открывает OOXML (docx, xlsx, pptx).
    • Функциональность ONLYOFFICE на данный момент шире, чем функциональность Collabora. Но в Collabora потенциально есть все фичи, которые есть в Libre.
    • На одном сервере с 2-мя ядрами смогут одновременно работать 8-10 пользователей, если на нём развернута Collabora, или 150 пользователей, если на нём установлен ONLYOFFICE.
    • В Collabora обработка всех действий от пользователя происходит на сервере, в ONLYOFFICE — на клиенте.
    • Collabora работает медленнее, это издержки архитектуры.
    • Совместное редактирование в Collabora основано на том, что пользователи заходят в один документ в одном и том же редакторе, что порождает ряд неудобств.
    • В ONLYOFFICE у каждого пользователя свой полноценный редактор в браузере. Сервер используется как БД для хранения пользовательских правок и последующей сборки файла.

    Вы можете сделать свои выводы или рассмотреть аспекты, которые мы упустили. Но знаете что? По нашему мнению, пока что Collabora — продукт медленный (это решается хорошим интернетом), сырой (но можно доработать), с большим количеством багом (но их, конечно, пофиксят), но самое главное — их архитектура экономически невыгодна и к этому подорожник не приложишь, в то время как ONLYOFFICE можно использовать уже сейчас. Начать можно, например, с нашего решения для интеграции со сторонними облачными сервисами, такими как Nextcloud и ownCloud.

    P.S. Кстати, мы недавно выпустили редакторы ONLYOFFICE c переработанным интерфейсом, в котором инструменты сгруппированы в тематические вкладки. Это позволило нам облегчить навигацию по инструментам редактора, а ещё сделать видимыми многие важные вещи — например, плагины (про них скоро расскажем отдельно). Как выглядит новый интерфейс и что стало где в этом видео.
    ONLYOFFICE
    54,00
    Компания
    Поделиться публикацией

    Комментарии 46

      +1
      Если бы у onlyoffice был электронный документооборот вы убили бы sharepoint! Посмотрите в сторону ельмы бпм! У вас вполне готовая экосистема для полного покрытия стека enterprise!
        0
        В документообороте нам действительно есть над чем поработать. Спасибо.
        –1
        Здесь всё понятно: Collabora получила в качестве наследства все проблемы и баги Libre. И главная проблема тут — плохая совместимость (очень) с форматами Microsoft. Как мы помним, то, что майкрософтовские форматы OOXML (docx, xlsx, pptx) — родственники форматов OpenDocument, не прибавляет им совместимости.
        Работаем ли мы с ODF? Да, но конвертируем. И качество конвертации постоянно растет.

        Главная проблема, что полноценная «конвертация» тех же формул невозможна из-за кучи нюансов поведения.
        Так как там разница уровня ="" в ООо обработается как ноль в математической формуле, а в экселе — выдаст ошибку. Или что при объединении ячеек в ООо запросто можно сохранить данные в скрытых ячейках (если при объединении ячеек данные не были слиты вместе в первую) и к ним можно обращаться, а в экселе они теряются.
        Как это можно сохранять, конвертируя документы туда/сюда мне лично не понятно.
          0
          OOXML не запрещает писать данные в ячейки, «скрытые» при помощи merge. Microsoft просто не предоставляет такой возможности в интерфейсе, как и мы. OpenOffice же предлагает выбор. Поэтому у нас не возникает проблем при конвертации таких файлов.

          Про формулу ="" не совсем понятно, что имелось ввиду, у меня во всех редакторах ошибка "#VALUE!".
            0
            В A2 пишем ="", т.е. присваиваем формуле значение 'пусто' (например, удобно не отображать нули if(a1>0;a1*2;""))
            Если в другую написать =A2*1, получаем в ООо — 0 (более того, даже =""*1 даст ноль на выходе), в Excel — #ЗНАЧ!
            Причем если в ячейке реально пусто, а не формулой задано, то и там, и там считает 0.
            Так вот, если принять какую-то сторону, то это автоматически приводит к ошибкам при работе с другим форматом, так как люди пишут свои формулы под именно такое поведение. Либо добавлять костыли с анализом, какой в реальности формат поступил на вход вашей программы.

            Таких мин раскидано много. И, кстати, я уже спрашивал в личку, как и про — у вас есть таблица сравнений разницы между функциями в OOo и Excel, но ответа не получил.
            Ещё лучше б, если б это была а-ля вики с возможностью дополнения пользователями, вам же самим проще было бы соломку стелить.
              0
              хм… в LibreOffice выдает #ЗНАЧЕН!
                0
                Вот за это, если честно, я не люблю форки. В ООо такое поведение было с 3 версии.
                Обратная совместимость? Да зачем она нужна! Кому надо форкнут форк, опенсурс же…
                А вот в гугло таблицах ровно то же поведение, как и в OOo.
                Что логично. Пустая ячейка независимо от формата = 0, а если в значение записали пустую строку — то вдруг уже не равно нулю? Ну, тогда бы и на отсутствие значения ошибку бы писали…
                  0
                  Ну, я так понимаю, все остальные Офисы переняли такое поведение, как раз, для совместимости. Один OpenOffice ведет себя по другому. Да, и не проще ли, скрывать отображение нулевых значений через формат ячеек? Вроде такого Формат ячеек > Тип: 0;-0;;@
                    0
                    все остальные Офисы переняли такое поведение, как раз, для совместимости
                    Ну вот привел в пример гугловские таблицы. Так что не все.
                    Правильно, надо перенимать совместимость с другими ломая с своими старыми…
                    Да, и не проще ли, скрывать отображение нулевых значений через формат ячеек? Вроде такого Формат ячеек > Тип: 0;-0;;@

                    В зависимости от задач. Задача может стоять и уровня отображать все, в том числе и ноль, если в другой ячейке не пусто, а если там пусто — ничего не отображать. Только в итоге уже на эту ячейку ссылается подсчет в третьей, который будет выдавать ошибку или. То есть решить вопрос — можно. Однако как это поможет при открытии уже созданного документа в данном софте (и да, привет либере за это!)
                    А условной форматирование — дико не удобный инструмент при большом количестве строк/ячеек, где подобное поведение нужно. Список уж больно большой получится таких стилей и надо будет как-то привязку к ячейкам в названии, чтоб понимать где что, а ячейки — сдвигаются бывает.

                    Другой вопрос, что это не единственное отличие.
                    Например, сколько можно вложений функций делать в разных функциях экселя? Раньше было не так уж и много (а в последних версиях я просто не пробовал), а в ООо их реально десятками вкладывал в друг друга.
          +2
          Странно сравнивать проприетарное решение и OpenSource. ИМХО, Ваш главный конкурент гугл докс. С ним и нужно сравнивать.
            +1

            Ничего странного. Мало кто выбирает пользовательский софт по идеологическим соображениям.

              0
              В этой статье мы сравниваем два open source решения. Исходный код ONLYOFFICE открыт. Вы можете найти его на гитхабе. Что касается сравнения с Google Docs, мы уже писали о нём.
                0
                Тогда извините. Может, стоит поместить информацию об этом на Вашем сайте на более видное место?
              0

              Пробовал OnlyOffice десктопный, который без сервера — оч. понравился, и у меня вопрос — автоматической расстановки переносов нет вообще или только бесплатной бессерверной системы? И если планируется, то в насколько дальней перспективе? Очень злободневно для написания документации.

                0
                Переносы в планах, но не ближайших к сожалению.
                +1
                Collabora лучше, чем ONLYOFFICE открывает документы OpenDocument, но гораздо хуже открывает OOXML (docx, xlsx, pptx).
                любой документ docx, xlsx...?
                хорошо бы «типичные» примеры документов выложить, что бы можно было судить — насколько критично это «хуже»
                  0
                  В принципе, любой. ONLYOFFICE такие документы откроет как свои, потому что для нас эти форматы являются базовыми. Collabora в любом случае будет конвертить в свой нативный формат. OOXML и ODF, конечно, оба XML, но вообще это будет песнь льда и пламени, потому что между собой они не особо совместимы.

                  За идею с документами спасибо. Постараемся сделать нечто подобное. А сейчас у нас есть вот такие презентации со сравнениями, там по открытию есть информация.
                  0
                  А если кто-то откроет документ в 700 страниц — ещё минус 1,5 Гб.
                  Вы считаете, что обрабатывать документы такого размера, что на сервере, что в браузере, это здоровая практика?
                  Проясните Вашу позицию по способам обработки документов подобного размера, она не понятна. Каким образом можно продуктивно использовать универсальный инструмент для создания и поддержания таких документов.
                    0
                    Практика нездоровая. Но одно дело так напрягать клиент (собственно и открывший этот документ), а другое сервер.
                      0
                      Поверьте, 1,5 гига я вам устрою и не на 700 страницах.
                      Хватит формул на несколько мегабайт. А с учетом, что стандартно хранится история на сотни шагов, то при глобальных изменениях объем, занимаемый документом в оперативке — станет космический. И это в том же ООо, установленном на локальном компьютере.
                      обрабатывать документы такого размера, что на сервере, что в браузере, это здоровая практика?
                      После приведенных примеров, чем браузер хуже спец.редактора?
                        0
                        После приведенных примеров, чем браузер хуже спец.редактора?


                        Не правильно задан вопрос. В данном случае спец редактор располагается либо на сервере либо в браузере, ну да ладно. Суть дела в другом. В случае с такими большими документами плох сам подход, негодный выбор технологии. Поясню подробнее.
                        Какая идеология заложена у MSO. Он ориентирован на обработку информации которая быстро теряет свою актуальность, такие данные используются в первую очередь в финансово-экономической области, где жесткие сроки по отчетности, информация меняется непрерывно. Вот цепочка действий на которую «заточен» MSO: access в качестве коннектора/прокси/словарей для извлечения данных из большой БД -> exel для анализа данных -> word для составления заключения -> powerpoint для наглядного пояснения сути дела начальству -> outlook для рассылки и обратной связи.
                        OpenOffice более заточен для создания научных статей, период актуальности информации существенно больше, данные меняются намного более медленно, провел эксперимент записал, следующий эксперимент когда ещё будет. Поэтому open/libre office сильнее с стилями оформления, но слабее с таблицами, информация меняется редко, частые смены не актуальны.
                        Данные аспекты в разнице предметных областей вообще никак не учитываются, но и это ещё не все.
                        Документ в 700 страниц, согласитесь, это фактически книга. А к написанию и изданию книг человечество выработала другой подход, другие технологии. В издательском деле актуально разделить действия на группы текст, художественное оформление, корректура, верстка, печать. Такой подход доказал свою состоятельность. А что мы имеем здесь, каша, все свалено в одну кучу.
                        Именно поэтому я и просил разъяснить позицию автора, непонятно зачем смешивать вместе, в чем суть такого смешения.
                          0
                          Документ в 700 страниц, согласитесь, это фактически книга.
                          Это может быть тупо выписка из реестра (тысяч сто строчек из экселя, которые нужно вставить в вордовский документ по требованию заказчика, реальный кейс из оценки). Объем страниц ничего не говорит про содержимое.
                          . А к написанию и изданию книг человечество выработала другой подход, другие технологии. В издательском деле актуально разделить действия на группы текст, художественное оформление, корректура, верстка, печать. Такой подход доказал свою состоятельность. А что мы имеем здесь, каша, все свалено в одну кучу.
                          И как это связано к изначальному:
                          Вы считаете, что обрабатывать документы такого размера, что на сервере, что в браузере, это здоровая практика?
                          То есть изначально вас интересовала работа именно на сервере или в браузере, а сейчас вы рассуждаете об заточенных под конкретную задачу решениях. А что мешает те же решения реализовать на сервере или в браузере, мне не понятно? Ну вот будет у нас в бразуере десяток решений отдельно для оформления, отдельно для корректуры, отдельно для верстки и т.п. — в чем проблема? Тут в браузере даже фотошопы реализовывают, что, тоже запретить?
                            0
                            Это может быть тупо выписка из реестра (тысяч сто строчек из экселя, которые нужно вставить в вордовский документ по требованию заказчика, реальный кейс из оценки). Объем страниц ничего не говорит про содержимое.

                            Вы имеете в виду автоматизированную обработку текста из OLTP отчета. И что с этим будет дальше? Я не соглашусь с Вашим утверждением «Объем страниц ничего не говорит про содержимое.» Такой объем очень плохо пригоден для восприятия человеком. Этот документ формальная отписка, по правилам она скорее всего нужна, возможно даже она будет использована 1-2 раза. Но в таком состоянии это не годиться для повседневного использования, тут мы имеем дело с вариантом исходных данных необходимых для дальнейшей обработки в формате msword, упрощенно это заготовка, полуфабрикат.

                            И как это связано к изначальному:

                            Мне, да и большинству людей не нравятся плохо сделанные вещи, плохо сверстанные книги, не нравятся документы которые сделаны для того что бы запутать и не показать содержания. Если Вы, например, условно допустим, отрицаете правила типографского и издательского дела, то Вам будет гораздо сложнее создавать удобные для использования документы больших размеров. У Вашего Заказчика может появится негатив, если приведенный выше документ будет плохо сверстан из-за нарушений закономерностей восприятия. Это в итоге скажеться на материальной оценке Вашего труда. Так что связь есть и она ощутима.

                            То есть изначально вас интересовала работа именно на сервере или в браузере, а сейчас вы рассуждаете об заточенных под конкретную задачу решениях. А что мешает те же решения реализовать на сервере или в браузере, мне не понятно? Ну вот будет у нас в бразуере десяток решений отдельно для оформления, отдельно для корректуры, отдельно для верстки и т.п. — в чем проблема? Тут в браузере даже фотошопы реализовывают, что, тоже запретить?

                            Меня изначально интересовала полезность предлагаемого инструмента для работы. И выясняется, что никто на настоящий момент не сумел показать идеологию и ценностную сущность предлагаемого решения для конечного потребителя, ни для коротких документов, ни для больших. Получается следующее. Про MSoffice мне понятно, про Libre/open office понятно, про google docs тоже понятно, а для чего ONLYOFFICE сделали не понятно, про то где его целесообразно применять молчат. Какое уж тут сравнение форм и платформ, тут про полезность ничего толком рассказать не могут. В общем ждем продолжения статей, очень много неясного.

                            Что касается вашего вопроса о проблеме специальных инструментов. Проблема заключается в том что бы превзойти уже существующие, дать что то более совершенное, аналог уже не привлекателен. В этом главная сложность.
                              0
                              Вы имеете в виду автоматизированную обработку текста из OLTP отчета.
                              Нет, я имею ввиду CTRL+C из экселя и CTRL+V в ворд. «Потому что документ должен быть именно в этом формате» Реальный кейс лет десять назад, перед которым, кстати, спасовал ООо.
                              Мне, да и большинству людей не нравятся плохо сделанные вещи, плохо сверстанные книги, не нравятся документы которые сделаны для того что бы запутать и не показать содержания.
                              «Но если бы у рыбы была шерсть, то у нее были бы блохи, а блохи — это....» Вы опять подменяете задачи и решительно побеждаете в споре.
                              Кстати, тот же МС ворд прекрасно позволяет готовить макеты, если работать в нем правильно. Об этом убедительно говорит опыт доктора наук, которая много своих книг и методических пособий сделала с помощью него. Поэтому то, что вы тут рассуждаете, что раз 700 страниц, то нужен спец.инструмент — это всего лишь ваша предубеждение, которые вы позиционируете, как единственно верное.
                              Меня изначально интересовала полезность предлагаемого инструмента для работы.
                              Нет
                              Вы считаете, что обрабатывать документы такого размера, что на сервере, что в браузере, это здоровая практика?
                              Такая постановка вопроса говорит о том, что вы явно противопоставили обработку документов на сервере, в браузере и еще где-то. Точнее — локально, так как других вариантов нет. На что возникает вопрос «а какая разница между этими способами», после чего вы начали рассуждать о спец инструментах. Хотя, вроде бы никто не запрещает реализовывать спец инструменты хоть на сервере, хоть в браузере.
                              А теперь неверной подменой задач вы начинаете спец задачи трактовать как основные и на этом фоне данный инструмент не пригодным.

                              У онлиофиса ровно тоже самая целесообразность, что у мс офиса, а либро/ооо, гугло доков и прочих, прочих, прочих. И ровно та же полезность. Если она конкретно вам не подходит — не понятно закой черт страдать фигней и требовать выдать вам напильник заместо долота в теме про сравнение долота от разных фирм производителей.
                                0
                                Поэтому то, что вы тут рассуждаете, что раз 700 страниц, то нужен спец.инструмент — это всего лишь ваша предубеждение, которые вы позиционируете, как единственно верное.

                                Ответ был, для массового использования непригодно. Об этом свидетельствует опыт издательского и типографского дела за несколько столетий.
                                У онлиофиса ровно тоже самая целесообразность, что у мс офиса, а либро/ооо, гугло доков и прочих, прочих, прочих. И ровно та же полезность.
                                Вы либо заблуждаетесь не осознавая разницы, либо «лгать изволите». То что вы подготавливали рукописи в MSword не является достаточным опытом для сравнительной оценки этих иструментов. Этого крайне мало. Если бы сравнили подготовку в msoffice и libre толкового аналитического отчета по товарной группе за короткий период, актуальность которого «протухнет» через 10 дней, Ваша реакция была бы иной, совсем иной.

                                Можно взять другую область, подготовку технической документации по требованиям ЕСКД со всеми её согласованиями и утверждениями. Люди ночуют на работе, поскольку верстка «слетает», и на каждое добавление рисунка или абзаца приходиться полностью переверстывать документ. Только не берите в интернете шаблоны для учебных работ, нормоконтроль признает их непригодными и не допускает документ к утверждению.

                                И msoffice и libre и google docs отличаются не только внешним видом и функционалом их главное отличие в направленности на различные профессии и группы пользователей. У меня ребенок пишет свои учебные работы в google docs, для него нет разницы между google docs и msoffice, в google docs предпочтительнее немножко меньше возни. Если Вы будете предлагать использовать google docs экономистам и бухгалтерам, Вы моментально заработаете репутацию неадекватного человека разрушителя.
                                А так конечно, во всех случаях можно вставлять буквы, таблички и рисунки, на первый взгляд все все делают одинаково, разница минимальна. Только реакция потребителей почему-то полярная.
                                И немного off top. То что Вы пишете книги это здорово. Попробуйте любопытства ради испытать «сладкую парочку» LATEX+Revision Control System, только попросите что бы Вам это установили, настроили и помогли понять как это работает. Это сложнее ворда на начальном этапе, но если «распробуете», Вам понравиться.
                                  0
                                  Ответ был, для массового использования непригодно. Об этом свидетельствует опыт издательского и типографского дела за несколько столетий.
                                  Итак, вы опять продолжили: «если бы у рыб была шерсть, то у них были бы блохи...»
                                  Несколько столетий издательского и типографского дела и LATEX в примерах, как это мило. фейспалм.жпг
                      –3

                      Редактировать документы нужно в десктопных редакторах (LibreOffice, MSOffice и т.п.).
                      Браузер должен служить только для отображения веб-страниц (новости, интернет-магазин, форумы и т.п.).


                      Использовать браузер ДЛЯ ВСЕГО-НА-СВЕТЕ (в том числе, чтобы плодить корпоративных рабов) — 1) негуманно, 2) уродливо.
                      У меня всё.

                        0

                        Редактировать документы нужно там, где это удобно и эффективно. Рынок предлагает разные варианты, для разных потребностей и вкусов. Может быть в итоге останется только один, но вряд ли это будет десктопное приложение, запускаемое на локальной машине пользователя.

                          +1
                          Скажите, у вас ведь до сих пор кнопочный телефон без проигрывания mp3, камеры и интернета?
                          0
                          Сделайте ещё сравнение с МойОфис (Collabio Office)
                            +2
                            Обязательно сделаем в будущем! Пока они не предоставляют свободного доступа к продукту. А вообще было бы здорово, если бы такое сравнение писали сами пользователи, у которых уже была возможность потестировать его.
                            0
                            Вот кстати, если вы всерьёз хотите конкурировать с MSOffice, позаботьтесь о том, чтобы работали клавиатурные сокращения. Я пытаюсь пользоваться таблицей DesktopEditors, но мне очень не хватает Ctrl+1, Ctrl++, Ctrl+-, Ctrl+D и т. д.

                            Доработка копеечная, но очень поможет в пересадке пользователей, особенно опытных.
                              0
                              «Ctrl+1» — обрабатываем. Возможно имели ввиду «Ctrl+Shift+1»?
                              Остальные комбинации — постараемся добавить в ближайших выпусках.
                                0
                                Обрабатывать-то обрабатываете, но сравните богатство возможностей диалога MSOffice с вашим.
                              0
                              Когда тестировали был шок, что Ваш продукт рассылает письма сотрудникам с рекламой.
                              Ну то есть он у нас живет своей жизнью, что то сам там делает, пишет письма и прочее (а вот что прочее??).

                              Это руководству сразу не понравилось и была поставлена точка.
                                0
                                Уточните, пожалуйста, о каком продукте идет речь?

                                Мы действительно оставляем за собой право уведомлять пользователей о выходе новых версий и акциях ONLYOFFICE. Никакой сторонней рекламы мы не распространяем. При желании от рассылки можно отписаться.
                                0
                                В Collabora обработка всех действий от пользователя происходит на сервере, в ONLYOFFICE — на клиенте.
                                я не считаю это недостатком
                                все зависит от организации взаимодействия с сервером, с случае с ONLYOFFICE взаимодействие тоже необходимо
                                Collabora работает медленнее, это издержки архитектуры.
                                может издержки конкретной реализации?
                                Давайте представим, что к-л продукт «грамотно» рендерит ту часть, с которой работает пользователь и не тянет весь контент на клиента, и не занимает место в памяти сервера, размещая там весь документ. Сервер будет «знать» — с какими частями работает «какой» клиент
                                В случае с клиентским кодом, если надо вытянуть весь док на клиента и потом его синхронизировать с состоянием на сервере..., мне кажется — куча доп. работы и нагрузка на каналы
                                Как пример… Сейчас наблюдаю работу «документооборота»..., в его реализации есть локальный клиент, мало того что от отжирает 300 Мб памяти, еще без к-л деятельности, он еще и документы «пописывает» на стороне клиента, а для этого — выгружает док сервера/подписывает/загружает. Для объемных документов — это жутки тормоза и время ожидания.
                                Второй момент: при открытии/закрытии документа одним клиентом, состояние блокировки не всегда обновляется корректно на сервере (возможно из-за сетевых задержек), как результат — другой клиент не может «ничего» сделать с этим документом и 1-му надо закрыть все приложение!
                                  0
                                  Мы считаем, что чем меньше нагрузка на сервер — тем лучше. Так как если пользователь работает с документом — странно передавать (через сервер) эти тормоза человеку, который работает на этом же сервере, но с другим документом. Много людей — потребуется много серверов, а это не выгодно. И, по-нашему мнению, Collabora так поступает лишь по одной причине — потому что у них нет браузерного редактора. И совместного редактирования тоже нет. И был выбран максимально простой вариант — открывать Либру на сервере и транслировать мышь и клавиатуру пользователей. Рабочий вариант, никто не спорит. Но уж точно не «грамотный».
                                    0
                                    Collabora так поступает лишь по одной причине — потому что у них нет браузерного редактора. И совместного редактирования тоже нет. И был выбран максимально простой вариант — открывать Либру на сервере
                                    в приведенном куске вами «осуждался» подход к обработке на сервере

                                    Еще момент: не факт, что либра не сможет, в будущем, предоставлять более гибкие средства взаимодействия (в контексте запуска отдельных процессов и оверхеда по памяти)
                                    Нагрузка на сервер, безусловно, важна и если разбирать Collabora и либре — есть куда стремиться. Но упор на преимущество подхода «исполнения на клиенте», для меня, не звучит убедительно

                                    Добавим тезис о популярности docx и прочих проприетарных форматов…
                                    Ситуация: фирма1 присылает фирме2 документ на согласование/правку, в большинстве случаев согласовывают содержание, а не форму. Учтем еще — каждая организация имеет свой свод «корпоративных» стандартов. Конечный документ будет не в редактируемом виде (скорее-всего хардкопия) и в электронном виде — PDF вполне кандидат на данную роль. Как у вас обстоит дело с сохранением верстки при конвертации в PDF средствами ONLYFFICE?
                                    Меня вполне устраивало качество конвертации docx в PDF либрой (с учетом граблей оформления в МСО)
                                    Т.о. интересуют возможности оформления документов (присутствующие в продукте), а не формат. Выходной формат, самый распространенный — PDF
                                      0
                                      У нас четкое разграничение в редакторах. Логическая (форматная) часть -> измерение -> отрисовка. И сохранение в пдф — это просто подмена отрисовщика на канве/нативного на сохранялку в пдф. Поэтому сохранение в пдф 1-в-1 так, как вы видите в редакторе документ. Согласен на 100%, что если файл не для редактирования и его надо передавать — то только PDF. Чтобы со встроенными шрифтами и без багов/особенностей измерятеля.
                                    +1
                                    В Collabora обработка всех действий от пользователя происходит на сервере, в ONLYOFFICE — на клиенте.
                                    я не считаю это недостатком

                                    Могу привести ООо в пример. Берем «большой» файл, который в оперативке занимает метров 300. Ок, удаляем страничку с кучей данных. В оперативке еще +300 метров сожралось, так как история откатывать обязана шагов на сто назад документ, да еще типа того шустро. Продолжаем еще так делать раз десять и опа, ООо упал, выжрав гига полтора. Это на локальной машинке. На сервере таких пользователей может оказаться несколько, каждый выжрет по паре гигов и?
                                      0
                                      LO тоже так делает? Надеюсь баг зафиксировали ;)
                                      повторюсь… обработка на сервере (как подход к архитектуре приложения) я не считаю недостатком.
                                      То что ошибки приложения есть — это не повод «ругать» архитектуру
                                        0
                                        LO тоже так делает?
                                        да может и последний ООо уже так не делает, если честно. Ибо более двух лет назад сталкивался с подобным поведением.
                                        Надеюсь баг зафиксировали ;)
                                        Я, не являясь тестировщиком в полной мере в среднем за день сталкиваюсь с парочкой новых багов в разных приложениях. В особо плохие дни — с десятками. За пару дней — четыре тикета в мантисе. Да меня только фиксация багов в нужных приложениях уже достала, что бы тратить еще полжизни на фиксацию во всех подряд, да еще с проверкой, где они повторятся, а где нет. Вначале бы свернули деятельность по распылению на форки, а то выяснилось, что файл свободного формата .ods созданный в опенсурном же ООо может не верно работать в его форке Либре — офигенчик же, я считаю.

                                        обработка на сервере (как подход к архитектуре приложения) я не считаю недостатком.
                                        обработка на сервере таких вещей может являться большой нагрузкой на серверы, особенно с учетом того, как эти приложения пишут. В этом плане возложить на локальную машину, которая чаще всего сейчас может позволить себе подобные «излишки» (вспоминая требования того же 97 офиса, возможностей которого большинству за глаза) — это отличный вариант.

                                        PS. С другой стороны мне вспоминается клиент зимбры на джаве (если не ошибаюсь), который установленный локально вызывал дичайшие тормоза системы на всех компьютерах фирмы, после чего всех перевели в браузер и вуаля, проблемы тормозов исчезли… С другой стороны, если бы выбрали запуск данного клиента на сервере и трансляцию мыши и клавиатуры пользователю (с) — сервер бы, скорей всего, сдох в максимальных мучениях.
                                    0
                                    Файл, выгруженный из БД, csv, 4.5 мегабайта. Ни оформления, ни формул. 5 тысяч строк, около 30 полей.
                                    LibreOffice: 35 мегабайт ОЗУ
                                    ONLYOFFICE: 240 мегабайт ОЗУ (потребление браузера)
                                    Collabora: не открыл файл. Файлик поменьше сожрал 190 метров (потребление браузера).
                                    Потребление бэка на демо-доступах не отображалось.

                                    Веду учет расходов в onedrive табличном редакторе. Примерно на двух тысячах строчках оно начинает лагать. В результате стал делить на периоды, не реже чем раз в год начинать новый лист.
                                      0
                                      Подскажите, проблема с установкой owncloud/nextcloud + onlyoffice на одном сервере уже отсутствует? Пробовал весной(вариант с docker контейнером) — так и не удалось завести, с советами на форуме Onlyoffice. Поставил тогда же Collabora по родному мануалу и заработало сразу…

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

                                    Самое читаемое