Единое окно доступа к образовательным ресурсам

Первая международная конференция разработчиков свободных программ на Протве: Тезисы докладов

Голосов: 0

В сборнике представлены программа конференции и тезисы докладов, одобренных Программным комитетом Первой международной конференции разработчиков свободных программ на Протве, которая состоялась в Обнинске 29-30 июля 2004 года.

Приведенный ниже текст получен путем автоматического извлечения из оригинального PDF-документа и предназначен для предварительного просмотра.
Изображения (картинки, формулы, графики) отсутствуют.
       • обработка unicode (например, вывод «д» или
     «\cyrchar\cyrd{}»),
   • разбиение лигатур (например, вместо «--- » — «-{}-{}-»).
     Помимо этих существенных преобразований, TEX ML предоставля-
ет также расширенные возможности.

   • В язык встроена поддержка структурных конструкций LTEX:
                                                       A
     окружений, групп, команд с параметрами.
   • Благодаря автоматическому форматированию создаваемого кода,
     итоговые документы хорошо выглядят.

Преимущества TEXML
    Простой код на TEXML
<group><cmd name="it" gr="0"/>\пример</group>
    соответствует такому TEX-фрагменту:
{\it \textbackslash{}пример}
    Если изучить историю проектов tbook[2], xsltml[3], dblatex[4],
db2latex[5] и других, создающих TEX-код с помощью XSLT, то выяс-
нится, что во всех них были подобные проблемы:
   • не всегда экранируются специальные символы,
   • иногда забывается пробел после команды и получается
     «\itтекст » вместо «\it текст »,
   • может теряться открывающая или закрывающая фигурная
     скобка,
   • из-за объективных сложностей, системы ориентированы на
     западноевропейскую кодировку.
    Эти и другие проблемы не возникают при использовании TEXML.




                                71


Другие версии TEXML
    При поиске решения для публикации XML через LTEX выяснилось,
                                                   A
что Douglas Lovell предложил подход TEX ML ещё в 1999-м году[6], и
была даже реализация на языке Java. Этот проект, TEX MLatt´ [7], был
                                                          e
заброшен несколько лет назад, но от него осталась описание, которое
послужило основой для новой версии TEX ML.
    Существует также TEX MLapis[8], обработчик подмножества
TEX ML на языке Perl, но его возможности ограничены.


Список литературы
 [1] TeXML: an XML vocabulary for TeX http://getfo.org/texml/
 [2] The tbook system for XML Authoring
     http://tbookdtd.sourceforge.net/
 [3] XSLT MathML Library http://xsltml.sourceforge.net/
 [4] DocBook to LaTeX/ConTeXt Publishing
     http://dblatex.sourceforge.net/
 [5] DB2LaTeX XSL Stylesheets http://db2latex.sourceforge.net/
 [6] Douglas Lovell, TeXML: Typesetting XML with TeX
     http://www.tug.org/TUG99-web/pdf/lovell.pdf
 [7] TEXMLatt´ http://www.alphaworks.ibm.com/tech/texml
             e
 [8] TEXMLapis
     http://www.bluweb.com/us/chouser/proj/texmlapis/




                                72


13:15–13:30
Виталий Останин                         Санкт-Петербург, ЗАО «Взлёт»
Проект: ALT Linux Documentation Project

  Средства для разработки и представления
   документации с использованием единого
                 источника

    Аннотация:
    В докладе описывается подход к созданию документации с исполь-
    зованием единого источника. Описывается XML как базовый формат
    разметки, и DTD DocBook/XML как структура документов. Рассмот-
    рены основные принципы модульной разработки документов, инстру-
    менты для создания и преобразования документов в другие форматы.



Семантическая разметка — первичность информации и
вторичность внешнего вида
    При создании документации основная задача — это запись смысла,
информации о предмете документирования, и лишь потом визуальное
представление этого смысла. Отделение смысла от оформления назы-
вается семантической разметкой. При таком подходе в документах раз-
мечается только информация, а внешний вид формируется с помощью
дополнительных преобразований.
    В проекте ALT Linux Documentation[1] (ALT Docs), посвящённом
созданию документации, в качестве базового формата документации
был выбран язык разметки XML[2]. Основными причинами для его
выбора стали:
   • общедоступная спецификация;
   • простота (это текстовый формат, похожий на HTML);
   • расширяемость (возможность добавлять собственные теги для
     разметки метаинформации);
   • абстрагирование от кодировки документов (возможность
     создавать документы или фрагменты одного документа в
     произвольной кодировке);

                                  73


   • набор полезных спецификаций для включения документов
     (XInclude[3] и XPath[4]);
   • независимость от платформы и инструментария.
    В качестве структуры документов был выбран тип документов DTD
DocBook/XML[6], разработанный для создания документации. В дан-
ной схеме семантическая разметка создаётся в DocBook/XML, а преоб-
разование информации в различные форматы выполняется с помощью
XSL-стилей[5]. Собственно, XSL-стили и определяют внешний вид ин-
формации.
    Для DTD DocBook/XML существуют XSL-стили, которые позво-
ляют получать из одного и того же исходного документа выходные
форматы для печатных публикаций (PDF и PS), online-публикаций
(XHTML/HTML одним файлом или разбитым на много файлов), спра-
вочных систем (man pages, Eclipse Help, Java Help, HTML Help).

Модульная разработка документов
    При написании документации часто встречается ситуация, когда
разные фрагменты документа пишут разные авторы. При создании до-
кументации из модульных фрагментов нужно иметь возможность объ-
единять документы и их сопутствующие файлы (например, файлы с
изображениями). При этом каждый фрагмент автор пишет как самосто-
ятельный документ в произвольной кодировке.
    Для объединения документов можно использовать спецификацию
XInclude[3] (которая пока находится в стадии рекомендации, однако
уже поддерживается многими программными средствами. При этом в
результирующем документе нужно обеспечить уникальность идентифи-
каторов тегов (id) и уникальность имён файлов с изображениями (im-
ages) из разных фрагментов. Такой уникальности можно достичь либо
специальным преобразованием id/images, либо соблюдением общего со-
глашения об именовании id/images.
    Ещё один момент, который нужно учитывать при модульной разра-
ботке документации — это сбор имён авторов из фрагментов для вывода
в общем списке авторов, например, на титульной странице.
    Для всех этих задач в ALT Linux Documentation Project разра-
ботан набор стилей, доступный по адресу http://docs.altlinux.ru/
releases/xsl/current/common/




                                74


Средства для создания и публикации документов
    Для создания документов в формате DocBook/XML можно исполь-
зовать как обычный текстовый редактор, так и специализированные
редакторы — emacs, vim, conglomerate1 , tkxmlive2 . Документы мож-
но создавать в любой кодировке (которую поддерживает XML-парсер),
правильно указанной в объявлении XML.
    Для обработки и преобразования документов в проекте ALT Docs
используются библиотеки и утилиты libxml2/libxslt[7]. Несмотря на на-
звание — парсер и инструментарий для Gnome — это независимый от
Gnome[8] кроссплатформенный набор инструментов, написанный на C,
компактный, быстрый и не требующий дополнительной установки Java.
    Парсер libxml2 поддерживает большинство спецификаций семей-
ства XML, в том числе XML Inclusions 1.0[3], XPath 1.0[4], а также
многие расширения EXSLT[9], что позволяет максимально использовать
возможности стилей DocBook XSL.
    Для выполнения всех этапов сборки можно использовать Gnu Make
http://www.gnu.org/software/make/.


Список литературы
 [1] ALT Linux Documentation Project http://docs.altlinux.ru
 [2] Extensible Markup Language (XML) 1.0
     http://www.w3.org/TR/REC-xml/
 [3] XML Inclusions (XInclude) Version 1.0
     http://www.w3.org/TR/xinclude/
 [4] XML Path Language (XPath) http://www.w3.org/TR/xpath
 [5] The Extensible Stylesheet Language Family (XSL)
     http://www.w3.org/Style/XSL/
 [6] DocBook DTD http://docbook.org
 [7] The XML C parser and toolkit of Gnome http://xmlsoft.org/
 [8] GNOME: The Free Software Desktop Project
     http://www.gnome.org/
  1 http://www.conglomerate.org
  2 http://tkxmlive.sourceforge.net



                                      75


 [9] EXSLT is a community initiative to provide extensions to XSLT
     http://www.exslt.org/
[10] FOP (Formatting Objects Processor)
     http://xml.apache.org/fop/index.html




13:30–13:55
Алексей Крюков                      Москва, МГУ им. М.В. Ломоносова,
                                              Исторический факультет
Проект: СОЛУНЬ          http://www.thessalonica.org.ru

  Разработка расширений для OOo Writer на
         примере проекта СОЛУНЬ

    Аннотация:
    В докладе рассматривается процесс переноса отработанных решений
    с платформы MS Word на OpenOffice.org, а также сравнительные до-
    стоинства используемых для этой цели средств разработки (Basic,
    Python, Java). Основное внимание уделяется программированию по-
    иска/замены и ввода различных национальных символов в текстовых
    документах. Попутно предполагается обратить внимание на основные
    подводные камни, ждущие разработчика на этом пути.

    Проект СОЛУНЬ (в латинском написании — Thessalonica), которо-
му посвящено настоящее сообщение, сам по себе имеет узкоспециаль-
ное назначение, будучи предназначен для облегчения жизни филологов-
классиков и историков-эллинистов. Тем не менее, представляется, что
знакомство с его историей (достаточно сказать, что версия этой про-
граммы для OpenOffice.org прошла в своём развитии три этапа, будучи
последовательно переписана на Basic, Python и Java) способно предо-
хранить от большого количества синяков и шишек многих разработчи-
ков расширений для OpenOffice.org.
    СОЛУНЬ начала своё существование в виде макропакета для Mi-
crosoft Word 97 и выше, предназначенного для решения двух ключевых
проблем, с которыми ежедневно сталкивается любой специалист, чья ра-
бота связана с классическим греческим языком. Во-первых, отсутствие

                                  76


общепринятой 8-битной кодовой страницы, которая покрывала бы ак-
центированные греческие символы, породило множество используемых
для этой цели несовместимых друг с другом кодировок. Соответственно,
становится актуальной задача преобразования текста из этих кодировок
в Юникод и обратно. Во-вторых, необходимо обеспечить возможность
доступа ко всему множеству акцентированных символов с клавиатуры.
    Познакомившись с OpenOffice.org, я должен был прежде всего от-
ветить для себя на вопрос, предоставляет ли он необходимые возмож-
ности для реализации аналогичных функций. Поначалу мне казалось,
что реализация конвертера во всяком случае не должна вызывать за-
труднений: ведь для этого требуется лишь возможность многократного
поиска и замены фрагментов текста с нужным форматированием. В то
же время я не видел возможности обеспечить ввод акцентированных
символов внутренними средствами OpenOffice.org, так как настраива-
емость клавиатуры в нем ограничена и заведомо не идёт ни в какое
сравнение с уникально богатыми в этом отношении возможностями MS
Word. Практическая работа над проектом показала ошибочность обоих
этих предположений.
    Точно так же не оправдалась надежда малой кровью перевести го-
товые макросы с VBA на StarBasic. Главная проблема заключалась даже
не в различии объектной модели, а прежде всего в том, что разработку
проекта пришлось начать с реализации ряда чисто технических функ-
ций. Например, пытаясь обеспечить сохранение настроек, я столкнулся
с тем фактом, что API OpenOffice.org предоставляет лишь низкоуров-
невый интерфейс для доступа к реестру приложения. Соответственно,
потребовалось затратить определённые усилия на создание модуля, ко-
торый предоставлял бы некий набор функций, сходных с привычными
по WordBasic getPrivateProfileString/setPrivateProfileString. Аналогич-
ным образом дело обстояло с доступом к элементам диалоговых окон.
Совсем уж нетривиальный код потребовался для того, чтобы создать
списки доступных приложению шрифтов и языков, необходимые для
формирования пользовательского диалога, в котором можно было бы
выбрать нужные параметры форматирования. Надо сказать, что уси-
лия, затраченные на этом этапе, не пропали впустую: отлаженные моду-
ли Basic впоследствии оказалось не так сложно портировать на другие
языки.
    Лишь завершив этот предварительный этап работы, я смог перей-
ти к к программированию алгоритма поиска и замены символов, и тут
меня постигло жестокое разочарование: оказалось, что поиск формати-
рованного текста в OpenOffice.org работает некорректно, и полагаться


                                  77


на него нельзя1 . Наиболее естественным обходным путём был поиск
фрагментов текста без указания форматирования с последующей его
проверкой, но и этот вариант оказался чреват непредсказуемыми по-
следствиями. Лишь после выхода стабильной версии OpenOffice.org 1.1
удалось найти приемлемое решение, состоявшее в отказе от множества
последовательных операций поиска: теперь поиск выполняется един-
ственный раз, с длинным регулярным выражением в качестве аргумен-
та. Зато оказалось, что API OpenOffice.org предоставляет возможность
перехватывать клавиатурные нажатия, адресованные активному окну, в
результате чего удалось реализовать менеджер раскладок клавиатуры,
обладающий даже б´ льшими возможностями, нежели соответствующая
                    о
часть макропакета для MS Word.
     По мере разрастания проекта становилось всё очевиднее, что боль-
шинство его модулей выглядело бы намного изящнее, будучи реализова-
но в качестве объектов. Увы, такая возможность недоступна в StarBasic
(в отличие от MS VBA!). Собственно, в этом заключалась главная при-
чина, заставившая меня обратиться к Python, а затем и к Java. Моё пер-
воначальное предпочтение Python было обусловлено следующими двумя
обстоятельствами. Во-первых, Python сходен с Basic в том отношении,
что оба эти языка позволяют напрямую обращаться к свойствам и мето-
дам каждого объекта UNO, в то время как в Java такой объект должен
быть вначале представлен в качестве реализации того или иного интер-
фейса (это делается с помощью вызовов UnoRuntime.queryInterface()).
Вторая причина выглядит несколько неожиданной, но, в сущности, со-
здаёт едва ли не больше затруднений: дело в том, что Makefile’ы для
представленных в OpenOffice.org SDK примерных проектов на Java от-
нюдь не отличаются прозрачностью и, самое главное, слишком тесно
привязаны к структуре каталогов самого SDK, ввиду чего извлечь от-
туда полюбившийся образец оказывается не так-то просто.
     Реализация компонентов OpenOffice.org на Python, безусловно,
технически проще, однако она заставляет разработчика учитывать ряд
ограничений. Самое главное из них заключается в том, что на дан-
ный момент практически не существует удобного способа инсталляции
модулей Python, которые не представляли бы собой в то же время реа-
лизацию компонентов UNO. Именно поэтому приходится жёстко выдер-
живать схему один файл—один компонент, и, соответственно, регистри-
ровать в качестве сервисов UNO даже те объекты, которые предназна-
чены только для использования внутри данной программы. Поскольку
   1 Пользуясь случаем, хочу лишний раз привлечь внимание аудитории к заполненному

мною по этому поводу issue 10569.


                                       78


же сервис UNO непременно должен быть реализацией какого-либо ин-
терфейса, приходится дополнять пакет описаниями новых интерфейсов,
что создаёт дополнительные проблемы. Наконец, сама реализация шлю-
за Python—UNO, несмотря на все усилия её разработчика, в настоящее
время содержит немало ошибок, которые могли бы служить темой от-
дельного сообщения. Так, лишь в OpenOffice.org 1.1.2 была исправлена
проблема с компилированными библиотеками *.pyd под win32, из-за ко-
торой, естественно, едва ли не большую часть модулей из стандартной
поставки Python нельзя было использовать на этой платформе. Такого
рода ошибки в конечном счёте и сделали необходимым перенос кода
СОЛУНИ на Java.
     Таким образом, история проекта СОЛУНЬ служит лишним под-
тверждением того факта, что Java по-прежнему остаётся предпочти-
тельным средством разработки расширений для OpenOffice.org. В то
же время единство объектной модели UNO позволяет осуществлять пе-
ренос уже готовых проектов на другой язык без особых потерь, делая
необходимые для этого затраты усилий не столь критичными, как это
могло бы быть в иной ситуации.



13:00–13:45
Пётр Савельев                       Санкт-Петербург, JSC Eltel / DrWeb

Практика использования формата документов
     OpenOffice.org для веб-публикации

    Аннотация:
    Практика использования формата документов OpenOffice.org для веб-
    публикации



Введение
    Проект посвящён использованию возможностей преобразования и
публикации документов OpenOffice.org. Внутреннее представление до-
кументов OpenOffice.org определяет сравнительную лёгкость написа-
ния для них XSLT-преобразований, а также использования уже име-
ющегося XML для организации хранения данных в СУБД. Основной

                                   79


целью проекта была минимизация усилий пользователя при подготовке
документа к веб-публикации. Для реализации были выбраны, помимо
OpenOffice.org, Zope и PostgreSQL.

OpenOffice.org
    Офисный пакет, позволяющий производить оформление документа
исключительно стилями, что заметно облегчает как непосредственно
работу с документом, так и его преобразование. Ещё одной ключевой
особенностью стало использование WEBDAV как протокола доступа к
документам в сети.

Zope
    Система публикации документов. Благодаря архитектуре (написана
на Python), позволяет легко создавать собственные модули, дополняю-
щие или перегружающие уже существующие возможности.

PostgreSQL
    СУРБД, одной из ключевых особенностей которой является воз-
можность создания хранимых процедур и функций как на SQL-
подобном диалекте, так и на Python, Tcl или Perl. Возможно также
подключать бинарные модули (.so), написанные на С. Модуль xml (ав-
тор John Gray) был использован в качестве базы для добавления функ-
циональности XSLT-преобразований.

Организация и развитие проекта
    В качестве результата работы надо проектом видится система, поз-
воляющая сохранять документы прямо из OpenOffice.org (через WEB-
DAV), производящая автоматический импорт при сохранении, и авто-
матический экспорт в различные форматы при запросе определённых
URL.

Уровень базы данных
     В PostgreSQL хранится XML, импортированный из документов
OpenOffice.org. Предполагается импорт документа в виде одной XML-
записи, на данный момент различные части документа (styles.xml, con-
tent.xml, meta.xml etc.) хранятся в различных таблицах.

                                80



    
Яндекс цитирования Яндекс.Метрика