OpenOffice.org 1.1: еще один шаг

Всяка имеет свой ум голова.
Г. Сковорода

К сожалению, украинский проект вообще выглядит как-то уж слишком доморощенным.
То, что активность как посетителей, так и создателей сайта оставляет желать много
лучшего, — не самое страшное. Гораздо хуже — пламенные призывы к повторному
изобретению велосипеда, в частности к подготовке украинского словаря, которые
демонстрируют то ли наш менталитет, то ли худшие черты движения Open Source. Ведь
данная работа один раз уже была проделана: проверка украинского правописания вполне
пристойно функционирует в русской версии, причем лингвистические модули доступны
и отдельно от всего пакета. Энтузиастам явно не хватает "руководящей и направляющей
силы" вроде Sun или хотя бы ALT Linux (благодаря ее усилиям и реализована
не только русская локализация, но и поддержка украинского языка), способной консолидировать
их усилия и направить "в мирное русло".

Украинский словарь имеется и в русской версии

Поэтому все нижеизложенное относится именно к русской версии и именно OpenOffice.org,
ведь StarOffice пока так и не переведен на близкие нам языки. Впрочем, и отличия
между двумя продуктами не слишком велики — в коммерческий пакет Sun входят кое-какие
сторонние компоненты (словари, БД Adabas В 12), дополнительные шрифты, шаблоны,
более профессионально выполненные пиктограммы. Любые виды поддержки, в
том числе и платная, с недавних пор предоставляются компанией и для OpenOffice.org,
во всяком случае именно на сайте Sun стоит искать качественную документацию пользовательского
уровня.

Единственное, что обращает на себя внимание, — различное отношение разработчиков
к важности изменений в нынешней версии: в Sun их оценили на целую единицу, тогда
как сообщество Open Source ограничилось всего одной десятой. Вероятно, каждая
точка зрения имеет право на жизнь, и можно предположить, что в первом случае во
главу угла были поставлены нововведения для программистов, а во втором — потребительские
качества. Если так, то позиция Sun кажется более дальновидной, ведь Microsoft
Office сегодня силен не только огромной инсталляционной базой, но и 3 млн. разработчиков,
а также не поддающимся исчислению легионом создателей макросов (среди них встречаются
и пресловутые "домохозяйки"). Впрочем, обо всем по порядку.

Пользователю — пользователево

Начнем с того, что в таком сложном продукте, как современный офисный пакет,
любое обновление сулит большое число изменений, исправлений, доработок и дополнительных
возможностей, важность которых в конечном итоге не всегда просто оценить. Скажем,
в OpenOffice.org 1.1 компоновка текстовых документов по умолчанию привязывается
к экранному разрешению, а не к ресурсам конкретного принтера, что в некоторых
случаях может приводить к неоднозначным результатам, однако, по свидетельству
разработчиков, улучшает переносимость документов Microsoft Word (снижается вероятность
того, что рисунки и другие объекты "разъедутся").

Совместимости вообще уделено традиционно большое внимание — улучшены фильтры
для Microsoft Office (в частности, должны корректно обрабатываться рисунки WordArt
и элементы форм), поддерживаются самые популярные форматы файлов для КПК (AportisDoc,
Pocket Word и Excel), при импорте XML можно применять XSLT-преобразования — доступна
даже пробная версия WordML-фильтра для XML-документов Microsoft Word 2003.

С ресурсоемкостью все по-прежнему

Одно из интересных наблюдений состоит в том, что нередко OpenOffice.org позволяет
открыть поврежденные файлы Microsoft Office (особенно DOC и PPT), с которыми не
справляются "родные" приложения. Учитывая, что специализированные программы
восстановления достаточно дороги, OpenOffice.org удобно иметь под рукой для оказания
"первой помощи" при непредвиденных обстоятельствах. Кстати, в OpenOffice.org
1.1 появились и средства для "ремонта" собственных документов. Использование
XML как базового формата, по идее, обещает высокую степень успешности данной процедуры,
однако не следует забывать, что SXW и другие, на самом деле, являются обычными
ZIP-архивами, и нарушение их целостности чревато полной потерей информации.

Наиболее значимыми нововведениями, пожалуй, оказались встроенные функции сохранения
текстовых документов в PDF и презентаций в SWF (Macromedia Flash). Оба формата
давно уже стали де-факто стандартами для распространения соответствующей информации
— кросс-платформенными, удобными, общепризнанными. Их поддержка — большой плюс
для OpenOffice.org, в том числе и потому, что позволяет избежать многих проблем
с совместимостью и переносом файлов (как известно, даже с RTF случаются проблемы).

Единственное, что по-прежнему вызывает недоумение, — отсутствие конвертеров (и,
похоже, даже планов по их созданию), которые позволили бы открывать документы
OpenOffice.org в приложениях Microsoft Office. Ведь с точки зрения конкуренции
гораздо разумнее максимально облегчить обмен файлами в собственных форматах,
чем постоянно расширять поддержку чужих.

Отдельно стоит остановиться на ресурсоемкости OpenOffice.org, прежде вызывавшей
немало нареканий. По большому счету, все осталось по-старому, хотя пакет, несомненно,
подвергся оптимизации. Благодаря специальному механизму "быстрого запуска"
открывается приложение (как известно, OpenOffice.org представляет собой единую
программу, выполняемую в различных "контекстах") почти мгновенно, правда,
сам он потребляет изрядное количество оперативной памяти — обычно от 40 (сразу
после запуска) до 120 MB (после работы с ПО) плюс примерно такой же объем виртуальной.
С этим нужно просто смириться, ведь, судя по всему, никаких архитектурных изменений
в обозримом будущем не предвидится. Впрочем, для современных компьютеров (даже
"офисных", а не игровых) такой недочет не слишком критичен. Зато многие
внутренние функции стали работать заметно быстрее: очевидный пример — вызов контекстного
меню со списком предлагаемых исправлений для слова, помеченного при автоматической
проверке правописания.

Из нового — применение XSLT-преобразований

Кое-какие изменения коснулись эргономики и usability: стали более логичны некоторые
функции (скажем, закрытие документа не приводит к выключению программы), абсолютно
все возможности вызываются с помощью комбинаций клавиш, появились плавающие панели
(Мастер стилей и др.) и ряд иных мелких усовершенствований. Тем не менее
приходится констатировать, что в вопросах комфорта OpenOffice.org до продукции
Microsoft еще далековато. Взять хотя бы текстовый процессор: в Word гораздо удобнее
выделять мышью строки и абзацы, работать с примечаниями, при вставке фрагментов
из других файлов (скажем, Web-страниц) очень просто убрать все форматирование,
текст можно бесконечно масштабировать без необходимости горизонтальной прокрутки
— любой "бывалый" пользователь обнаружит множество подобных нюансов.
Речь в данном случае идет вовсе не о привычках — в Microsoft Office и некоторых
других коммерческих разработках такие наиболее востребованные функции действительно
продуманы до мелочей. Конечно, по большому счету, совершенствование OpenOffice.org
— вопрос времени, лишь бы эргономике уделялось должное внимание. Но, к сожалению,
именно это, как правило, и не характерно для мира Open Source, где разработчики
привыкли "творить великое", забывая, что в конечном итоге оно тоже состоит
из мелочей. Остается уповать на Sun, хотя нельзя исключить, что все достижения
в данной области будут "оседать" только в StarOffice (как случилось
с упоминавшимися выше пиктограммами).

…А разработчиково — разработчику (пока)

Наконец-то создатели OpenOffice.org/ StarOffice удостоили своим вниманием
и сторонних разработчиков. Причем различные расширения и доработки API, реализация
поддержки OLE на платформе Windows и прочие новшества меркнут на фоне выпуска
полновесного SDK и реализации макрорекордера. Постараемся объяснить, почему именно
два последних события нам кажутся самыми важными, приняв точку зрения непрофессионального
"полупрограммиста".

Многие считают, что средства создания макросов в современных офисных пакетах совершенно
излишни, ведь пользователь в лучшем случае осваивает 20% возможностей приложений.
Казалось бы, зачем ему еще и программировать? Однако макросы нужны не только для
реализации новой функциональности, но и для автоматизации повторяющихся действий.
Простой пример: если вы интенсивно применяете доступную и в Microsoft Office,
и в OpenOffice.org автозамену ("ии" — на "Internet", "оо"
— на "Office" и т. п.) или обмениваетесь документами между разными
приложениями и платформами, то очень часто словам, набранным латинскими буквами,
присваивается неправильный язык (например, русский или украинский). Соответственно
не действует проверка правописания, легко пропустить опечатку и т. д. В таком
случае вполне помогут стандартные средства поиска и замены, тем более, что в обоих
упомянутых пакетах они поддерживают регулярные выражения и прочие полезные возможности.
Однако если вы не дока в подобных вопросах, то разбираться со всеми тонкостями
вам придется чуть ли не при каждом обращении к их помощи — одним словом, это
как раз та ситуация, когда удобно записать и сохранить на будущее макросы, код
которых приведен в листингах 1 и 2.

Листинг 1. VBA Sub Макрос1() ' Макрос1 Макрос 'Макрос записан 13.02.2004 IgorD Selection.Find.ClearFormatting Selection.Find.Replacement.ClearFormatting Selection.Find.Replacement.LanguageID = wdEnglishUS With Selection.Find .Text = "<[A-Za-z]@[A-Za-z]>" .Replacement.Text = "" .Forward = True .Wrap = wdFindContinue .Format = True .MatchCase = False .MatchWholeWord = False .MatchAllWordForms = False .MatchSoundsLike = False .MatchWildcards = True End With Selection.Find.Execute Replace: = wdReplaceAll End Sub Листинг 2. Star Basic sub Macro1 rem ——————————————————————————————————— rem define variables dim document as object dim dispatcher as object rem ——————————————————————————————————— rem get access to the document document = ThisComponent.CurrentController.Frame dispatcher = _ createUnoService("com.sun.star.frame.DispatchHelper") rem ——————————————————————————————————— dim args1(18) as new com.sun.star.beans.PropertyValue args1(0).Name = "SearchItem.StyleFamily" args1(0).Value = 2 args1(1).Name = "SearchItem.CellType" args1(1).Value = 0 args1(2).Name = "SearchItem.RowDirection" args1(2).Value = true args1(3).Name = "SearchItem.AllTables" args1(3).Value = false args1(4).Name = "SearchItem.Backward" args1(4).Value = false args1(5).Name = "SearchItem.Pattern" args1(5).Value = false args1(6).Name = "SearchItem.Content" args1(6).Value = false args1(7).Name = "SearchItem.AsianOptions" args1(7).Value = false args1(8).Name = "SearchItem.AlgorithmType" args1(8).Value = 1 args1(9).Name = "SearchItem.SearchFlags" args1(9).Value = 65536 args1(10).Name = "SearchItem.SearchString" args1(10).Value = "<[A-Za-z]*[A-Za-z]>" args1(11).Name = "SearchItem.ReplaceString" args1(11).Value = "&" args1(12).Name = "SearchItem.Locale" args1(12).Value = 255 args1(13).Name = "SearchItem.ChangedChars" args1(13).Value = 2 args1(14).Name = "SearchItem.DeletedChars" args1(14).Value = 2 args1(15).Name = "SearchItem.InsertedChars" args1(15).Value = 2 args1(16).Name = "SearchItem.TransliterateFlags" args1(16).Value = 1280 args1(17).Name = "SearchItem.Command" args1(17).Value = 3 args1(18).Name = "Quiet" args1(18).Value = true dispatcher.executeDispatch(document,_ ".uno:ExecuteSearch", "", 0, args1()) end sub

Концептуальных отличий в них совсем немного (главное, не забыть в OpenOffice.org
указать символ "&" в качестве замены), однако код выглядит и воспринимается
совершенно по-разному. Согласитесь, что Selection гораздо ближе и понятнее любому
пользователю (практически всякого приложения), чем frame и dispatcher. О настройке
параметров функции поиска и замены и говорить нечего. При этом следует также иметь
в виду, что справка по Star Basic не содержит даже упоминаний об объектной модели
UNO, положенной в основу программного интерфейса OpenOffice.org. Аналогично среда
пакета не поддерживает автоматически заполняемые списки членов классов, подсказки
о параметрах процедур и другие крайне полезные инструменты, знакомые по работе
с VBA. Вместо них у каждого UNO-объекта имеются, к примеру, специальные отладочные
свойства DBG_properties и DBG_methods, перечисляющие все доступные ресурсы.

Но об этом ведь тоже нужно откуда-то узнать. В качестве отправной точки стоит
воспользоваться официальным
учебным пособием, а лучше руководством от Sun, расположенным по адресу docs.sun.com/db/coll/so7en,
хотя оно, на наш взгляд, страдает излишним наукообразием, в частности рассказывает
об интерфейсах и прочих программистских "прелестях", которые непосредственно
в Star Basic и макросах не применяются. Что поделаешь, сказываются Java-корни.
Естественно, один этот документ не дает полного представления о модели UNO —
она очень обширна, максимально универсальна и, как следствие, более сложна в освоении.
Скажем, поскольку OpenOffice.org/ StarOffice представляет собой единое приложение,
постольку одни и те же макросы будут доступны во всех программах-контекстах, а
стало быть, для решения многих специальных задач потребуется сначала выяснить
тип активного документа. Безусловно, в такой архитектуре можно усмотреть и плюсы,
и минусы, но приходится признать, что в общем случае программировать на Star Basic
сложнее, чем на VBA. Именно поэтому так важно появление макрорекордера (с помощью
которого и получен соответствующий листинг), ведь, кроме выполнения своих прямых
обязанностей, он вполне сослужит службу и в качестве обучающего средства.

Что же касается исчерпывающей информации обо всех программистских тонкостях, то
ее следует искать
в SDK, куда входит тысячестраничное руководство для разработчиков (максимально
полное описание API, ориентированное в основном на Java и C++, но содержащее полезные
сведения и для простых смертных, предпочитающих Star Basic), примеры и пр. Приятно
также, что активность создателей пакета быстро нашла отклик и у сторонних специалистов.
Конечно, ресурсы вроде www.ooomacros.org
(полный список находится на api.openoffice.org/TipsAndTricks/external.html)
пока еще сложно сравнивать с Office Extension, но, как известно, и Москва не сразу
строилась.

Таким образом, хотя внешне доработки OpenOffice.org 1.1 не кажутся такими уж принципиальными,
пакет, несомненно, сделал еще один важный шаг к завоеванию популярности у различных
категорий пользователей. Безусловно, его создателям еще многое предстоит сделать,
в первую очередь — довести до ума (что называется, "вылизать") уже
имеющуюся функциональность, поскольку всякие мелкие (по большому счету, несущественные,
но все-таки мешающие) нюансы встречаются довольно часто. Очень хотелось бы в ближайших
версиях увидеть более совершенную встроенную среду разработки, обеспечивающую
хотя бы минимум удобств и интеллектуальных возможностей, ведь сам по себе макрорекордер
— отнюдь не панацея. В целом же проект, как нам кажется, движется в правильном
направлении и постепенно становится все более конкурентоспособным — на деле,
а не в мечтах и фантазиях фанатичных приверженцев.