Неважно, с каким проектом вы работаете, в какой-то момент вы, скорее всего, в конечном итоге будете работать с электронными документами.
Мы не отличались.
Будучи поставщиком бизнес-услуг, мы вскоре осознали, насколько полезной может быть внутренняя система совместной работы с документами.
По сути, это стало началом процесса разработки, который перерос в нечто большее, чем просто создание инструмента для наших личных нужд. Мы рискнули сделать первый редактор документов на основе HTML5.
Для начинающих
Сегмент онлайн-управления документами может похвастаться такими гигантами, как Google, Microsoft, Zoho и т. Д., Поэтому сначала мы решили идти в ногу со временем и использовать проверенные временем методы для разработки продуктов.
Короче говоря, файлы были преобразованы в формат HTML на нашем сервере, чтобы сделать возможной работу в браузере. Функция редактирования была включена с помощью открытого кода CKEditor. Обратное преобразование из HTML в желаемый формат стало возможным благодаря тому, что пользователи смогли сохранить свою работу.
Результат не был ни удивительным, ни приятным, так как редактор сталкивался с теми же проблемами, что и его конкуренты, от плохого набора инструментов до серьезных ошибок отображения после сохранения, преобразования или печати документа.
Troubleshoot
Одной из самых основных потребностей обычного пользователя является возможность оценить размер документа. Настольные редакторы используют разбиение на страницы в этом отношении, что является сложной задачей для онлайновых. Проблема заключается в том, что современные онлайн-редакторы работают с одной HTML-страницей, независимо от того, сколько информации она содержит.
Другими словами, если вы возьмете 700-страничный документ, браузер все равно будет воспринимать его как одну HTML-страницу, напоминающую огромный ролл, который должен полностью отображаться каждый раз, когда вы вносите изменения. Мы в шутку называем это «эффектом папируса».
Только два в настоящее время разрабатываемых редактора имеют эту функцию. В то время как нумерацию страниц Zoho лучше всего охарактеризовать как приблизительную, платформа Google Docs работает более точно, но это, в свою очередь, усугубляет пресловутый «эффект папируса», вызванный необходимостью повторного отображения файла, а также повторного применения нумерации страниц каждый раз при вводе нового символа , например.
Человек учится на своих ошибках, поэтому мы решили сделать правильную нумерацию страниц нашей главной целью. Первое, что нам нужно было сделать, это отказаться от старых методов.
Разработка с нуля
Используя настольные редакторы в качестве ориентира для успешного решения проблемы разбивки на страницы, мы решили использовать те же принципы, чтобы получить достойный результат.
Мы изменили архитектуру кода в разделе рендеринга документа, поэтому теперь все операции выполняются с видимой частью документа, а остальная часть документа отображается только при обращении к нему. Таким образом, мы решили сразу несколько проблем, что позволило:
- избегать низкоскоростной работы с многостраничными документами (например, при смене семейства типов)
- увеличивать / уменьшать сам документ (не окно браузера)
- отображать невидимые символы
- изменить размер полей
Идентичная демонстрация
Еще одна вещь, которую мы заметили при работе с онлайн-редакторами, это проблема неидентичного отображения документов в различных браузерах и после печати. С точки зрения пользователя, это всего лишь одна проблема, но от разработчика, по крайней мере, две: измерение шрифта (получение метрик шрифта) и рендеринг текста в документе.
В настоящее время онлайн-редакторы документов используют браузер для визуализации и измерения. Однако измерение в браузере никогда не бывает точным. Кроме того, в нем отсутствуют важные атрибуты, такие как восходящие, спусковые и другие метрики.
Более того, каждый браузер может иметь свои собственные средства измерения, что приводит к неправильному отображению одного и того же документа в разных браузерах.
То же самое относится и к способам отображения текста браузерами. Текущие редакторы используют браузеры для отображения текста на «холсте», предоставляемом ОС.
Вот почему нам пришлось придумать наш собственный механизм получения метрик шрифта, а также наши собственные методы рендеринга. В результате мы контролируем метрики шрифтов, поэтому мы можем отправлять запросы нашему средству визуализации.
Без сомнения, мы должны отдать должное новой технологии HTML5 (точнее, элементу canvas), которая предоставляет доступ к пикселям контента. Каждый элемент отображается точно в пиксель и, следовательно, не зависит от браузера или ОС.
Помимо одинакового отображения в разных браузерах, нам удалось получить хорошие результаты при печати документа (сохранение его в формате .pdf). Хранение параметров файла в метафайле с набором команд позволяет нам избежать преобразования, которое неизбежно вызывает потери качества.
перспективы
Функции, к которым мы привыкли в настольном редакторе, такие как межстрочный интервал, обилие шрифтов и стилей текста, многоуровневая нумерация, редактирование таблиц или многостраничных отчетов уже проникают в сферу онлайн-редактирования, независимо от того, какой браузер вы используете или где Вы пытаетесь импортировать документ из.
В долгосрочной перспективе HTML5 гарантирует множество еще более значительных преимуществ в этой сфере.
Между тем, это то, что мы в конечном итоге:
Теперь редактор является частью пакета для совместной работы TeamLab Office и может быть протестирован там после входа в систему или на нашем демонстрационном портале (который намного быстрее) по адресу html5.teamlab.com .