Текстовые процессоры: Глупые и Неэффективные

virens

36 коммент.

Предисловие
Это перевод замечательной статьи о том, что в ряде случаев применение визуальных текстовых процессоров типа Ворда и ОпенОфиса не только не оправдано, но и чрезвычайно неэффективно. Она показывает, хотя и несколько эмоционально, существенные различия между визуальным и логическим подходом к созданию документов. В статье приводятся убедительные примеры, иллюстрирующие во многих случаях преимущество логического метода как наиболее эффективного способа создания и набора действительно хорошо выглядящих документов. Все примеры подразумевают LaTeX, как наиболее совершенную систему компьютерного типографского набора.

Текстовые процессоры:
Глупые и Неэффективные

Аллин Коттрелл

Содержание

• 1 Утверждение

• 2 Печатные документы

  • 2.1 Создание против Набора

  • 2.2 Зло имени ``Что видишь, то и получаешь''

  • 2.3 Структура документа

  • 2.4 Текстовые редакторы

  • 2.5 Сила простого текста

  • 2.6 Системы компьютерного типографского набора

  • 2.7 Соединяем всё вместе

• 3 Цифровое распространение

  • 3.1 Простой документ

  • 3.2 Сложный документ

• 4 Оговорка

• 5 Демагогия, демагогия

• 6 Ссылки

1 Утверждение

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

Формулировка моего утверждения умышленно провокационная, но я внесу ясность: когда я говорю, что текстовые процессоры глупые, я не говорю, что вы, если используете текстовый процессор, тоже глупые. Я критикую технологию, которая усердно продвигается крупными производителями программного обеспечения, и которая стала стандартном де-факто. Вы скорее всего не подозреваете о существовании альтернатив. Альтернативные решения не продвигаются крупными производителями, по известной причине: как мы увидим, они свободно доступны.

Давайте начнём с конца. Текст, который предназначен для обмена идеями и информацией с окружающими, распространяется двумя главными путями:

1. Как ``твёрдая копия'', в виде традиционных отпечатанных документов.

2. В цифровом виде: электронная почта, веб-страницы, в формате, воспроизводимом на экране.

Здесь есть некоторые совпадения. Например, документ, предназначенный для печати, может быть распространён в цифровой форме в предположении, что у получателя есть возможность распечатать его. Но давайте рассмотрим эти два способа распространения по очереди.

2 Печатные документы

Вы хотите напечатать документ на клавиатуре, и ожидаете, что он красиво напечатается на вашем принтере. Естественно, вы не хотите, чтобы это произошло сразу (чтобы печатаемый вами текст появлялся на принтере в процессе написания). Вы хотите напечатать документ сначала и затем ``сохранить'' его в цифровой форме на каком-либо носителе. Вы хотите иметь возможность вернуться к документу и редактировать его в будущем, а так же отправить его на печать при желании. Верно ли, что текстовый процессор, такой, как захвативший большую долю рынка Майкрософт Ворд, ``естественный'' способ сделать всё это? Ну, это один способ, но не лучший. Почему?

2.1 Создание против Набора

Подготовка печатного текста при использовании текстового процессора обязательно вынуждает вас соединять две задачи, концептуально различные. Этими двумя задачами являются:

1. Создание непосредственно текста. Под этим я понимаю непосредственный выбор слов для выражения мыслей, и логическое структурирование текста. Это включает такие вещи, как разбиение текста на параграфы, разделы и главы, выбор места появления главного материала в сносках или в основном тексте, выделение значимых частей текста, представление некоторых частей текста в качестве цитат вместо авторских слов, и так далее.

2. Типографский набор документа. Имеется в виду выбор гарнитуры шрифта, которой будет отпечатан текст, и способ визуального представления структурных элементов. Должны ли заголовки разделов быть полужирными или написанные капителью? Должны ли они быть выровнены по левому краю или центрированы? Должен текст быть выровнен по ширине или нет? Должны ли заметки появляться вверху страницы или внизу? Должен ли текст идти одной колонкой или двумя? И так далее.

Автор текста должен, по крайней мере в первом приближении, быть полностью сосредоточен на первой из перечисленных задач. Это главная задача автора. Адам Смит, как известно, выявил огромные преимущества, вытекающие из разделения труда. Создание и логическое структурирование текста является решающим вкладом автора в производство печатного текста. Типографский набор - дело наборщиков. Это разделение труда было выполнено, разумеется, в традиционном производстве книг и статей в докомпьютерную эпоху. Автор писал и сообщал издателю логическую структуру текста с помощью различных пометок. Наборщик переводил авторский текст в печатный документ, преобразуя логическую разметку автора в конкретный типографское исполнение. Нужно только представить себе, скажем, Джейн Остин (Jane Austen) озадаченную, в каком шрифте набрать заголовок главы ``Гордость и Предубеждение'', чтобы увидеть, насколько нелепа эта фантазия. Джейн Остин - великая писательница; она не была наборщицей.

Вы можете подумать, что это не относится к делу. Произведения Джейн Остин были издаваемы; профессиональные наборщики были заинтересованы в разметке этого текста и его печати. Вы и я не столь удачливы; если мы хотим печатную статью, мы вынуждены делать это сами (и, кроме того, мы хотим сделать это намного быстрее, нежели при помощи обычных пишущих машинок). Мы чувствуем, что будем делать это сами (на собственных компьютерах), но в нашем распоряжении много помощников. В частности, у нас есть программы создания документов профессионального качества. Эта программа (или набор программ) способна сделать это за нас, бесплатно и за несколько секунд или долей секунд; сделать работу, которую обычные наборщики выполняли для Шекспира, Джейн Остин, сэра Вальтера Скотта и остальных. Мы просто воспользуемся программой с подходящим размеченным текстом, как делали традиционно авторы.

Я полагаю, следовательно, что должны быть два различных момента в производстве печатного текста с использованием компьютера. Первый печатает собственно текст и создаёт правильную логическую структуру, отмечая эту структуру простыми пометками. Это достигается при использовании текстовых редакторов, программ, которые не должны быть смешаны с визуальными текстовыми процессорами (ниже я объясню эту разницу более подробно). Дальше текст передаётся программе типографского набора, которая быстро вернёт восхитительно набранную копию.

2.2 Зло имени ``Что видишь, то и получаешь''

Эти две работы превращаются в одну при помощи современных визуальных¹ ``что видишь, то и получаешь'' текстовых процессоров. Вы печатаете свой текст, в то же время, как видите набираемый текст на экране компьютера и его конкретное типографское представление, которое близко соответствует тому, что вы распечатаете на принтере. В результате, текст постоянно оформляется по ходу его создания. На первый взгляд это может показаться огромным удобством; при ближайшем рассмотрении это настоящее бедствие. Есть три причины этого:

1. Автор отрывается от своего дела - создания текста - для выбора типографских приёмов, в которых он может совершенно не разбираться (``маяться со шрифтами и полями'' в то время как он должен сконцентрироваться на тексте).
2. Алгоритм типографского набора, применённый в визуальном процессоре, жертвует качеством во имя скорости, требуемой для оформления и изменения вводимого пользователем текста в реальном времени. Окончательный результат сильно ниже по качеству того, который получается в настоящей программе типографского набора.

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

Первые два пункта должны быть очевидными. Позвольте мне раскрыть третий (его важность зависит от типа рассматриваемого документа).

2.3 Структура документа

Рассмотрим для примера заголовок раздела. Как только логическая структура текста становится главной целью, требуется, чтобы важные части текста помечались бы, как заголовки разделов. Можно, например, написать \section{Text of heading}. Как заголовки разделов будут воспроизведены типографски в печатном документе - отдельный вопрос. Когда вы используете текстовый процессор, то, что вы видите есть (всё!) что вы получите. Вас вынуждают решать специфические типографские вопросы об отображении заголовка.

Положим, вы решили, что хотите заголовки сделать полужирными, и немного больше остального текста. Как вы собираетесь достичь этого? Есть более одного способа это сделать, но для большинства людей наиболее очевидным и интуитивным путём (дающимся в визуальной среде) является набор текста в заголовок, выделения его, нажатия на значок ``сделать полужирным'', открывания ниспадающего меню размеров шрифта и выбора большего размера. Заголовок теперь полужирный и большой.

Отлично! Но что говорит о том, что это заголовок? В документе ничто не идентифицирует этот маленький кусочек текста как заголовок раздела. Предположим, что через некоторое время вы захотите, чтобы заголовки были написаны капителью, или нумеровались римскими цифрами, или были отцентрированы, или что-нибудь ещё. Вы бы хотели сказать ``пожалуйста, сделайте это и это для изменения всех заголовков раздела''. Но если вы применили форматирование так, как описано выше, вы должны будете пройтись по всему документу и изменить каждый заголовок вручную.

Теперь есть способ определения структурного положения участков текста, например, в Майкрософт Ворде. Вы можете, если вы аккуратны, достичь эффектов типа изменения представления всех заголовков разделов одной командой. Но лишь немногие пользователи Ворда применяют это постоянно, и это не удивительно: визуальный подход не поощряет заботу о структуре. Вы можете легко - всё слишком легко - создать видимость структуры низкоуровневыми командами. Когда пишете текст используя текстовый редактор, с другой стороны, необходимость разметки структуры возникает сразу же.

2.4 Текстовые редакторы

Хорошо, теперь, вероятно, пора объяснить, что такое текстовый редактор и чем он отличается от текстового процессора. Современный текстовый редактор выглядит очень похожим на визуальный текстовый процессор. Он имеет обычные механизмы ниспадающих меню и/или иконок для функций открытия и сохранения файлов, поиска и замены, проверки орфографии, и так далее. Но он не имеет типографской функциональности. Текст, который вы набираете, отображается на экране в простом виде, но без претензии на отображение окончательного печатного документа.

Когда вы сохраняете документ, он сохраняется в форме простого о текста, который в США подразумевается как ``ASCII'' (the American Standard Code for Information Interchange, Американский Стандартный Код для Обмена Информации)<sup>2</sup>. Кодировка простого текста состоит из 128 символов (иногда это называют ``7-ми битным'' набором символов, так как он требует 7 бинарных знаков для кодирования; 2 в седьмой степени составляют 128). Он включает числа от 0 до 9, латинский алфавит в верхнем и нижнем регистре, стандартные символы пунктуации и набор специальных символов. Сообщение на простом тексте будет ``понято'' любым компьютером в мире. Если вы отправите такое сообщение, вы можете быть уверенным, что получатель увидит буквально то, что вы набрали.

С другой стороны, когда вы сохраняете файл из визуального текстового процессора, файл содержит различные ``управляющие'' символы, выходящие за диапазон кодировки простого текста. Эти символы представляют форматирование, которое вы применили (например, полужирное или наклонное) и различные виды внутренних ``служебных'' символов, относящихся к внутреннему устройству визуального текстового процессора. Они не являются универсальными. Чтобы они имели смысл, вам необходима копия текстового процессора, которым создавался текст (или некоторый подходящий конвертор). Если вы откроете файл визуального текстового процессора в текстовом редакторе, вы увидите (кроме текста, или его битов), много ``забавно выглядящей чепухи'': это бинарный форматирующий код.

Так как текстовые редакторы не вставляют никакого бинарного форматирующего кода, если вы хотите показать форматирование, например наклонный шрифт, вы должны сделать это с помощью меток разметки. А именно, вы пишете примечания (используя только простой текст), которые скажут системе типографского набора сделать указанный текст наклонным. Например, для системы набора LaTeX (о которой пойдёт речь ниже) вы должны написать \textit{текст, который вы хотите сделать наклонным}. В действительности, если вы используете текстовый редактор, созданный для взаимодействия с LaTeX, вам не придётся набирать это самостоятельно. Вы можете нажать комбинацию клавиш, выбрать из меню или нажать на значок, и соответствующее примечание будет вставлено за вас; механизм набора текста в текстовом редакторе, предназначенном для LaTeX, не сильно отличается от набора в современном визуальном текстовом процессоре.

2.5 Сила простого текста

Метод создания текста в простом тексте с использованием текстового редактора и компьютерной системы типографского набора имеет несколько ``побочных'' преимуществ:

1. Портируемость: как указано выше, любой человек, используя любую компьютерную платформу, в состоянии прочесть ваш размеченный текст, даже сли он не собирается просматривать или распечатывать набранную версию. С другой стороны, файл вашего навороченного визуального текстового процессора Шик-Блеск 9.0 может быть полностью не воспроизводим для получателя, не имеющего такого же визуального процессора той же версии, что и у вас - если он или она не настолько продвинутые в компьютерах, что способны вытащить простой текст из этого бинарного ``мусора''. И это заставляет тратить дополнительно время и вас, и получателя вашего документа. Вы так же можете встретить проблемы с чтением файла текстового процессора Шик-Блеск 8.0 программой новой версии 9.0, или наоборот, но вы никогда не будете иметь таких проблем с чтением старого доброго о текста.
2. Компактность: файл текста представляет ваши записанные мысли, а не кучу бинарного ``хлама'' визуального процессора. Для небольших документов файлы визуального текстового процессора могут быть в 10 раз больше соответствующего о текста, содержащего ту же информацию.

3. Безопасность: метод ``текстовый редактор в качестве системы типографского набора'' практически гарантирует отсутствие проблем с повреждением ваших документов (только если ваш винчестер не выйдет из строя или не произойдут прочие форс-мажоры). Ваш исходный текст всегда будет с вами, даже если система компьютерного набора выйдет из строя по каким-либо причинам. Если вы регулярно используете визуальные текстовые редакторы и не имеете таких проблем с повреждением файлов, вы чрезвычайно везучий человек!

(Для дальнейшего чтения: страница Сэма Стейнголда ``Нет проприетарным форматам данных'')

2.6 Системы компьютерного типографского набора

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

Основная программа, которую я подразумеваю, называется ТеХ и она была написана Дональдом Кнутом из Стэнфордского университета. ТеХ свободно доступен (можно скачать со многих ресурсов в Интернете), для любой компьютерной платформы (вы можете, если захотите, купить диск с полным набором файлов ТеХа по очень умеренной цене). Кнут начал работу над ТеХом в 1977 году; в 1990 он заявил, что больше не собирается разрабатывать программу - не потому, что потерял к ней интерес, а потому, что к этому времени она стала почти совершенна. Она свободна от ошибок настолько, насколько любая компьютерная программа может быть, и она превосходно выполняет типографский набор практически любого материала, от простого текста до высшей математики.

Я ссылался выше на ЛаТеХ. Если ТеХ - базовый типографский движок, ЛаТеХ - огромный набор макрокоманд, изначально разработанных Лэсли Лэмпортом в 80-ых годах 20 века и ныне поддерживаемых интернациональной группой экспертов. Эти макрокоманды делают жизнь гораздо проще для среднего пользователя системы. ЛаТеХ до сих пор находится в активной разработке, так как новые возможности и пакеты надстраиваются над базовым движком. Различные ``дополнения'' для ТеХа так же разрабатываются, позволяющие, например, создавать PDF (``Портативный Формат Документов'' компании Адоб) файлы напрямую из исходного размеченного текста (я говорю ``в разработке'', но имею в виду, что они постоянно улучшаются; программы уже очень стабильны и обладают всеми возможностями).

Как упоминалось выше, вы обозначаете желаемую структуру и форматирование вашего документа для ЛаТеХа в виде набора примечаний. Есть много книг и пособий в Интернет, которые рассказывают о подробностях этих примечаний, и я не буду здесь об этом писать. Наиболее употребительные команды просты и легко запоминаются, кроме того, ЛаТеХ-ориентированный текстовый редактор (коих множество) часто упрощает вставку этих команд.

Одна из притягательных возможностей ЛаТеХ - возможность менять частично или полностью типографское представление вашего текста лишь несколькими командами. Общее представление текста управляется:

1. изменением ``класса документа'' (например, отчёт, письмо, статья, книга);

2. применением ``пакета'' или файла стиля, которые вы хотите загрузить.

Вы можете, например, полностью изменить гарнитуру шрифта (для текста, заголовков разделов, сносок и всего прочего) и/или размеров используемых шрифтов изменением лишь одного или двух параметров в ``преамбуле'' вашего исходного размеченного текста. Точно также вы можете оформить всё, что угодно, в формат двух колонок, или повернуть страницы с портретной ориентацией на ландшафтную. Вероятно, есть такая возможность и у визуальных текстовых процессоров, но обычно это менее удобно и вы гораздо более вероятно приведёте всё в беспорядок и перепутаете всё из-за неудобства форматирования.

Типографский набор вы можете сделать столь подробным, насколько вы сами хотите этого. Вы можете выбрать полностью автоматический режим: просто определите класс документа и предоставьте всю остальную работу выполнить по умолчанию макрокомандам. В большинстве случаев это приводит к хорошим результатам, набор становится существенно более высокого качества, чем в любом визуальном текстовом процессоре (естественно, такие вещи как нумерация глав, заголовков и сносок, перекрёстные ссылки и всё остальное делает автоматика). Или вы можете более глубоко вмешиваться в процесс набора, загружая различные пакеты (или даже создавая свои собственные) для управления различными аспектами типографского набора. Если вы чувствуете к этому склонность, вы можете создавать действительно восхитительные и уникальные документы.

2.7 Соединяем всё вместе

Позвольте мне кратко рассказать о том, как всё это работает. Если у вас есть правильно установленный ТеХ, это выглядит примерно так: вы набираете текст в ТеХ-редакторе. Вы можете набирать требуемые метки оформления напрямую или вставлять их через выбор в меню или нажатия на кнопки. Когда вы захотите посмотреть на печатную версию, вы выбираете в меню или нажимаете на кнопку в редакторе вызов подсистемы набора. Другая кнопка или пункт меню откроют просмотрщик, где вы увидите текст таким, каким он выйдет из принтера. Вот именно это и есть истинно визуальный просмотр, показывающий чрезвычайно точно текст, который будет выведен на принтер. Вы можете приближать его или отдалять, просматривать страницы и так далее. Вы посылаете этот текст на принтер нажатием на другую кнопку или пункт меню, или возвращаетесь к редактированию.

Через некоторое время вы захотите просмотреть обновлённый файл. Нажмите на кнопку вызова подсистемы набора снова. На этот раз вам не придётся вызывать просмотрщик - если вы оставили его запущенным на фоне, он автоматически отобразит обновлённую набранную версию. Когда вы закончите с редактированием, вы можете удалить печатную версию файла для освобождения места на диске. Вам нужно только сохранить исходный файл размеченного текста; печатная версия может быть легко получена в любое время, как только потребуется.

3 Цифровое распространение

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

Возьмём для начала электронную почту. Обычно если человек хочет послать короткое, ``по случаю'', письмо, он печатает это письмо непосредственно в программе почтового клиента, независимо от того, является эта программа консольной (вроде Pine) или с графическим интерфейсом (например, Mozilla Thunderbird или Sylpheed)³. В этом случае письмо выходит в форме о текста (или, возможно, HTML, то есть языка разметки гипертекстовых документов, языка веб-страниц, которые сами по себе состоят из текста). Но что, если мы хотим послать более длинный текст, который подготовлен независимо от почтовой программы?

Для этих целей наиболее популярным является вложение в письмо документа, созданного в визуальном текстовом процессоре. Как альтернативная стратегия работает в этом случае?

Итак, мы провели различие между двумя ситуациями: является ли текст относительно короткий и несложный (записка, письмо, время собрания, список дел, расписание встреч) или более сложный (научная статья - вероятнее всего с множеством математических формул, отчёт с иллюстрациями, монография)? Подход `` текст плюс компьютерный набор'' предлагает разные решения для этих двух случаев.

3.1 Простой документ

В случае с простым документом мы должны спросить: вам действительно нужен компьютерный набор, информация о шрифте и всё прочее? Не является ли более продуктивным, более эффективным и экономичным сообщением просто напечатать простой текст, с минимальными элементами форматирования, которые позволяет простой текст? Это позволяет и экономить объём передаваемой информации (не забывайте, что файлы визуальных текстовых процессоров могут быть существенно больше простого текста, содержащего ту же фактическую информацию) и гарантирует, что никто не будет лишён возможностей прочесть сообщение из-за того, что они не могут запустить визуальный текстовый процессор Шик-Блеск 9.0. Вы можете прикрепить простой текст, созданный в текстовом редакторе, точно так же, как если бы прикрепили файл визуального текстового процессора, или просто можете вставить его из буфера обмена в тело сообщения (так как он содержит только простой текста). Так как исходные файлы ТеХа не содержат ничего более простого текста, вставленный размеченный текст содержит простые и очевидные метки форматирования, которые легко понять.

3.2 Сложный документ

Более длинные и сложные документы с тем же успехом могут быть прочитаны в форматированном виде. Математические символы трудно выражать в простом тексте, и, конечно, сложные диаграммы и изображения явно выходят за рамки возможностей простого текста. Как насчёт применения ТеХ в этом смысле? Я показал, что файлы визуального текстового процессора могут вызвать проблемы, поскольку у вашего получателя может не найтись визуального текстового процессора Шик-Блеск 9.0, который есть у вас. Но нельзя ли совместить их воедино? Даже если вы достаточно разбираетесь в ТеХе, чтобы попробовать его, как много ваших получателей имеют установленный ТеХ? Это резонный вопрос, но на него можно ответить. Если вы хотите, чтобы ваш получатель мог увидеть оформленную версию вашего файла без необходимости устанавливать ТеХ, вы можете:

1. Конвертировать исходные тексты ТеХа в HTML. Имеются хорошие программы для этих целей (HTML и ТеХ на самом деле имеют тесные родственные узы, так как они оба позволяют логически размечать текст, так что их взаимная конвертация может быть выполнена с высокой точностью⁴. Тогда ваш получатель сможет прочесть оформленный текст любым броузером.
2. Ваш получатель имеет доступ к Postscript-принтеру? В академической или деловой среде это очень частое явление. В этом случае вы можете послать полностью оформленную версию вашего документа в виде postscript-файла, который может быть просто отправлен на принтер. И/или его можно просмотреть на экране при установленной программе типа ghostview (свободна для загрузки из Интернета).

3. Ваш получатель имеет установленный просмотрщик PDF-файлов вроде Adobe Acroread? (Опять-таки, он свободен для загрузки) Если так, вы можете послать полностью оформленную PDF-версию вашего документа.

При рассмотрении способов передачи текста по электронной почте, мы уже упоминали подготовку текста для веб-страниц. Вы можете написать документ в HTML-формате напрямую. Если вы не хотите этого, вы можете создавать HTML-документы при помощи подходящих графических средств, типа NVU⁵. Конечно, вы так же можете получить HTML-файл из Ворда (обычно ужасный HTML, полный чужеродных тэгов, что делает его трудным для редактирования в любых других приложениях). Если вы создаёте документы в ТеХ, то очень просто конвертировать его в чистый, стандартизированный HTML.

4 Оговорка

Я попытался рассказать об альтернативном методе ``текст плюс система компьютерного набора'' в ущерб методу визуальных текстовых редакторов. Я понимаю, однако, что есть некоторые виды документов, для которых визуальные процессоры являются на самом деле лучшими инструментами. Полагаю, что это короткие, по случаю, документы, в которых дело оформления превыше содержимого: флаеры, постеры, пригласительные билеты на вечеринки и тому подобное. Вы можете сделать это и в ТеХ, но это будет не эффективно. Стандартных ЛаТеХовских классов (отчёт, статья и прочие) вам, очевидно, не хватит. И хотя ЛаТеХ очень лихо орудует различными вариантами шрифтов, которыми вы можете захотеть оформить текст, он не предназначен для смешивания и вкрапления весёленьких шрифтов, которыми вы захотите набрать несерьёзный документ. Логическая структура тут не главное: вы заинтересованы в возможностях ``чистого форматирования'' документа. Если вы хотите знать, оформляя эту строку шрифтом 36 кегля, не вытолкнет ли она последнюю строку на следующую страницу, чего вы не хотите? Тогда визуальные процессоры - ваш выбор.

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

5 Демагогия, демагогия

Наверное, не ускользнуло от вашего внимания то, что я до некоторой степени подготовился к этой теме. Да, это так. Дело в том, что это не предмет для академического спора между альтернативными методами подготовки текста. Чаша весов, в которых могущество и богатства основных производителей программного обеспечения, вся на одной стороне. Глупо, что мы рассматриваем ситуацию, в которой Микрософт Ворд уверенно стал, для большинства в мире, стандартном подготовки документов с использованием компьютеров. Но Ворд это стандарт, которому нечем больше похвалиться кроме того, что он является (или домогается того) быть стандартом.

Это очень похоже на ситуацию с раскладкой QWERTY. Вы знаете эту историю? Почему стандартное расположение клавиш на пишущей машинке (что распространилось и на компьютерные клавиатуры) имеет символы QWERTYUIOP на верхнем ряду клавиатуры? Оно не было таковым изначально. Это было придумано для того, чтобы существенно снизить скорость печати. Проблема была в том, что компетентность машинисток тех лет быстро обогнала возможности первых механических пишущих машинок: быстрая печать могла привести к застреванию клавиш, когда нажатие происходило быстрее, чем клавиша возвращалась обратно, ударившись о ленту. Раскладка QWERTY расположила клавиши таким образом, чтобы невозможно было печатать быстро. Это откровенно безумное расположение для клавиш на клавиатурах, но теперь слишком поздно что-либо менять: QWERTY - стандарт, и все попытки рационализировать клавиатуры разбивались об эту реальность.

Точно так же, я заявляю, что Ворд не имеет права быть стандартном подготовки документов, так как он однозначно менее эффективен (для большинства применений), чем уже существующие альтернативы. Надеюсь, что ещё не поздно в этом случае, что есть ещё возможность сказать НЕТ Ворду. На самом деле, в случае с Вордом, он хуже QWERTY: это не настоящий стандарт, но скорее попытка навязать его. Микрософтский ``стандарт'' для бинарного представления документа это что-то вроде прихоти корпорации Микрософт. Квази-монополия Ворда это лишь довесок к квази-монополии Микрософт Виндовс (событие, о котором я не буду здесь говорить). И до тех пор, пока на них хорошенько не надавят конкуренты, Микрософт не имеет никакого интереса в установке любого долгосрочного стандарта бинарного представления форматирования. С другой стороны, у них есть веские основания вынуждать вас ``обновлять'' Ворд время от времени. О, святая Мария Гваделупская, Ворд версии N+0 не желает читать документ, присланный вашими коллегами, созданный в Ворде версии N+1? Ну, наверное лучше обновить его, правда? Даже если в версии N+1 не появилось никаких новых возможностей по сравнению с версией N⁶

6 Ссылки

Если вы дочитали до этого места, вы скорее всего заинтересованы в более подробной информации о хороших текстовых редакторах, системе компьютерного набора ТеХ и так далее.

Лучшим местом для начала изучения ТеХ и ему подобных, вероятно, это домашняя страница TUG (TUG - TeX Users Group - Группа пользователей ТеХ). Здесь размещены все ссылки, которые вам могут потребоваться; одна из главных ведёт на сайт CTAN (Исчерпывающая Архивная Сеть ТеХ), с которого вы можете скачать полную систему ТеХ для практически любой компьютерной платформы. Эта система включает в себя программу типографского набора, большую коллекцию макрокоманд, просмотрщик и программное обеспечение для создания печатных файлов.

Пакеты ТеХа (свободные для любого использования) не включают обычно текстовых редакторов, которые вам так же потребуются (только если вы у вас нет такого). Выбор тут велик, но мой любимый текстовый редактор для работы с файлами ТеХа - Emacs, поставляемый с пакетом AUC TeX⁷. Последний делает Emacs очень дружественным к ТеХ: он будет подсвечивать синтаксис ТеХа, так что вы быстро увидите любые ошибки в вашей разметке, а так же он предоставляет широкий выбор команд ТеХ в виде обычных меню.

Если вы заинтересовались, здесь находится снимок экрана работы с TeX в текстовом редакторе Emacs⁸ (PNG, 40678 bytes).

Примечание

... визуальных¹

прим. перев.: Автор текста постоянно употребляет аббревиатуру WYSIWYG, которую затруднительно перевести адекватно на русский. Здесь и далее я буду заменять это слово на варианты слова ``визуальный'', в частности, WYSIWYG-wordprocessors на ``визуальные текстовые процессоры''.

... Информации)²

прим. перев.: И снова, всюду аббревиатура ASCII будет заменяться на ``плоский/простой текст'', тем более, что символы нашего алфавита тоже туда не входят.

... Sylpheed)³

прим. перев.: В оригинале было ``Netscape или Eudora'', но первый уже помер и я заменил его на потомка - Thunderbird, а второй заменил по религиозным соображениям (нет в Дебиане) на Sylpheed

... точностью⁴

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

... NVU⁵

прим. перев.: В оригинале - Netscape Communicator, но он, как поётся в песне, мёртв, а я - ещё нет. Заменён на NVU, для которого есть дебиановский пакет.

... N⁶

Это особенно ценно, на мой взгляд, для человека, использовавшего Ворд на протяжении нескольких лет до перехода на ТеХ, и кто остро интересуется типографским набором, никаких стоящих возможностей не было добавлено в Ворд для виндовс с версии 2.0 с примерно 1990 года

... TeX⁷

прим.перев.: мой выбор не совпадает с мнением автора - посмотрите на Kile, который входит в поставку почти любой nix-системы; может быть, он и вам понравится.

... Emacs⁸

прим.перев.: А если захотите посмотреть на Kile - вот ссылка.

Читать далее

Обработка изображений: конвертация из RAW-формата

virens

9 коммент.

Задача: требуется конвертировать снимки в RAW формате в Linux.
Решение: в Debian GNU/Linux есть несколько утилит, способных нам помочь - их можно просто поставить и сразу с ними работать.

Зачем и кому оно надо?
Многие цифровые камеры позволяют сохранять данные в RAW-формате - данные прямо с матрицы фотоприёмника, повторяющие структуру массива фотосенсоров (RGRGRG..., GBGBGB...). Для того, чтобы изображение можно было редактировать, его необходимо конвертировать из RAW-формата, использовав информацию о балансе белого, контрастности и интерполировав чёрно-белые значения баеровской матрицы в цветные пиксели. Некоторые конверторы, способны выдавать именно чёрно-белый массив точек, без цветовой интерполяции.
RAW-конвертор выполняет следующие преобразования:

• Интерполяция баеровского массива точек в цветное изображение: наиболее важная функция. Почти все фотосенсоры (за исключением матриц Foveon) используют баеровский примитив RGGB. В процессе интерполяции из этих пикселей восстанавливаются цвета итеративными методами, что обеспечивает минимальное количество артефактов;

• Баланс белого: съёмка часто производится при различных источниках света, каждый из которых имеет свою цветовую температуру. Она указывается при конвертации из RAW-формата.

Какие средства есть в Дебиане?
Простой поиск в репозитории

# apt-cache search RAW | grep image

выдаёт немало интересного, среди чего выделяются:

dcraw - decode raw digital camera images
gimp-ufraw - Gimp importer for raw images
mrwtoppm - tool to convert Minolta DiMAGE 5/7/7i RAW images to PPM
mrwtoppm-gimp - GIMP-plugin to support Minolta DiMAGE 5/7/7i RAW images

Всего этого должно хватить, чтобы более или менее комфортно работать с RAW-форматом в Linux.

Ставим и смотрим
Замечание по ходу: я прекрасно знаю, что этими несколькими программами средства по работе с RAW в Линукс не исчерпываются, однако пока я расскажу о том, что есть под руками, а потом, если будет желание, время и возможности, и о других программах. А пока о том, что есть непосредственно в Дебиан, во всяком случае в Debian v3.1 Sarge.

1. gimp-ufraw
Итак, первой программой, которой я воспользовался для работы с RAW-файлами, была gimp-ufraw - плагин для GiMP, дающий возможность конвертировать RAW. После установки этого плагина и перезапуска GiMP в меню появилась строчка, свидетельствующая о поддержке "чистого" формата. При попытке открыть RAW-файл, полученный с камеры, появляется диалог конвертора:

Скажу прямо, для бесплатной программы очень и очень неплохо. Можно поменять экспокоррекцию, баланс белого, цветовую температуру. Далее имеются настройки для цветовых профилей - по умолчанию sRGB, но скачиваением и установкой плагинов можно добавить огня в эти настройки. Самое интересное - управление кривыми: можно выставить линейные кривые, гамма-кривые и логарифмические. Внизу имеется гистограмма и проценты пере- и недоэкспонированных пикселей. Что ж, для GiMPовского плагина это, наверное, пять с плюсом.
Кроме RAW-файла Casio QV4000 были так же успешно открыты файлы с камер Canon EOS300D и FujiFilm S2 Pro. Тут надо отметить один забавный момент: в навороченном Adobe Photoshop CS2 тоже есть RAW-конвертор, но помимо перегруженности его совершенно бесполезными ползунками (и отсутствием нужных), был удивлён, что он не смог открыть RAW с моей камеры Casio. Вот так проприетарный продукт! А такой простой камеры не знает... Так что ufraw в этом плане обгоняет в том числе и проприетарные конверторы.
В общем, gimp-ufraw очень понравился, и он стал основным инструментом по работе с RAW-форматом.

2. dcraw
Далее была опробована программа dcraw, которая конвертирует RAW-файлы в формат ppm и фотошоповский psd. Утилита консольная и очень мощная, с большим количеством параметров. Она, как и gimp-ufraw, без проблем разобралась с raw-файлом моей камеры Casio, и конвертировала его в 16-бит ppm:

$ dcraw -2 kx821000.raw

Это, согласно справке dcraw (вызов без параметров, помимо man dcraw), преобразует в 16-бит ppm мой указанный файл. Отлично, справилось и открылось GiMP.
Среди других интересных и полезных опций программы:

-a Use automatic white balance
-w Use camera white balance, if possible
-m Don't convert camera RGB to sRGB
-d Document Mode (no color, no interpolation)
-f Interpolate RGGB as four colors
-s Use secondary pixels (Fuji Super CCD SR only)
-2 Write 8-bit PPM with 0.45 gamma (default)
-3 Write 16-bit linear PSD (Adobe Photoshop)
-4 Write 16-bit linear PPM

я бы выделил -d, которая позволяет вытащить из файла просто баеровский массив точек, без конвертации в цвета. Почти то, что и упало на матрицу. Для художественной съёмки это в общем особенно не нужно, а для научной - очень пригодится: часто нужен именно массив точек, без интерполяции на цвета. Благодаря dcraw теперь это можно получить.

Заключение
Всё меньше и меньше областей превосходства проприетарных программ над бесплатными - и это не может не радовать. Вот и в обработке RAW-файлов пользователи открытых систем не обделены хорошими и мощными утилитами, такими, как gimp-ufraw и dcraw. Есть и другие программы, но о них в других постах.

Читать далее

IceWM Window Manager: Ледяной десктоп антарктических пингвинов

virens

46 коммент.

Много оконных менеджеров в Linux, хороших и разных, и у каждого свои преимущества и недостатки. В этом посте я не буду сравнивать оконные менеджеры в Linux, а просто расскажу об оконном менеджере, которым пользуюсь с момента перехода на Debian. Это IceWM - холодный и строгий, простой и быстрый - компромисс между функциональностью и скоростью.


Как выглядит IceWM?
IceWM напоминает доведённый до ума интерфейс Windows 95: панель задач, кнопка Пуск IceWM, всплывающие подсказки, трей, часы... Только стильно, красиво и не занимает много ресурсов. Установка IceWM в базовой комплектации отнимет около 7Мб, что совсем не много за более чем функциональный интерфейс. Однако по умолчанию тема для IceWM (в Debian, во всяком случае) мягко говоря страшновата - такой тонкий намёк на то, что надо оконный менеджер подстроить под себя.


Кроме того, в меню могут отсутствовать кириллические символы - что видно на скриншоте - и там вместо русских пунктов меня будет просто пустота. Лечится это очень просто: нужен пакет gsfonts, который обычно устанавливается вместе с GiMP. После установки его потребуется в меню "Выход" (самый нижний пункт) нажать "Перезапустить IceWM" (просто пункт IceWM, пока у вас кириллица не видна). После этого русские менюшки видны на ура.

Русский есть, но темы уж больно убогие. Это поправимо, так как в дистрибутиве Debian есть специальный пакет, icewm-themes, который можно поставить и наслаждаться кучей разнообразных тем. Это потребует 16 Мб, зато не придётся лезть на сайт и качать их.


Если вы хотите, чтобы ваш десктоп был более рациональным, подберите тему под свой вкус и представления о красоте. Вот, например, используемая мной сейчас тема TrueCurve-1.0.4


Эта тема, как и многие другие, лежит на freshmeat. О том, какие есть самые красивые темы для IceWM, можно узнать здесь.

Следует отметить, что далеко не в каждой теме есть обои - так что не удивляйтесь, если после смены темы у вас на фоне замаячит однотонный фон или вообще сеточка иксов. Обои можно поставить руками, для чего в конфиге темы придётся кое-что поправить - но об этом ниже.


Подгоняем ледяной десктоп под себя
IceWM создан для того, чтобы быть лёгким и удобным - но у каждого представление об удобстве своё, так что следующий естественный шаг - подогнать IceWM под себя.
Так, русский в нём поправили, другие темы попробовали, что-то для себя выбрали. Но всё равно как-то аскетично. Нельзя ли что-то поправить или переделать, навесить немножко полезных рюшечек? И вообще, что можно сделать в IceWM для индивидуализации десктопа и оптимизации своей работы в нём?

Короткий ответ: многое. Для начала идём в скрытый каталог ~/.icewm (в домашнем каталоге) и смотрим, что там внутри:

keys
menu
preferences
programs
theme
toolbar
winoptions

Какой файл и на что влияет? Как говорится здесь, размещение параметров в нескольких файлах выполнено весьма логично:

 keys
Горячие клавиши запуска приложений

menu
Управляет содержимым "стартового" меню

preferences
Управляет поведением и общим внешним видом IceWM

programs
Управляет содержимым "programs", подменю стартового меню

toolbar
Управляет рядом запускающих кнопок на панели задач, и имеет такой
же синтаксис как и файл меню

winoptions
Управляет поведением отдельных приложений

Для того, чтобы изменить поведение IceWM, можно влезть в конфиг и поискать параметр по ключевому слову - высока вероятность, что вы его отыщете быстро, так как конфиг подробно прокомментирован. Вот его кусочек:

# "Hide window" shortcut
KeyWinHide="Alt+F11"

# "Rollup window" shortcut
KeyWinRollup="Alt+F12"

# "Window menu" shortcut
KeyWinMenu="Alt+Space"

# "Next item" shortcut
KeySysSwitchNext="Alt+Tab"

Как видите, всё можно настроить под себя. Лучше всего посмотреть на часто используемые комбинации клавиш и поправить конфиг так, чтобы вы смогли их использовать. Управлять так окнами гораздо проще и быстрее. Например, у меня сворачивание окна стоит на "CTRL+Пробел", переключение на "Alt+Tab" и остальные комбинации я тоже подогнал под себя - и управление окнами у меня теперь идёт со скоростью света, что сильно экономит время.
Кроме того, окно можно поднимать и опускать по слоям - чтобы, например, одно окно всегда было ниже остальных (очень выручает при работе в GiMP). Вот как выглядит меню при щелчке по правой крайней кнопке наверху окна:


У меня оно вызывается по "Shift+Esc", вы можете настроить это под свой вкус.

Итак, помимо стандартных операций с окнами, можно:

+ скрывать окна (при этом их не будет на строке задач, но при переключении задач они будут последними в списке);
+ скручивать (останется только заголовок окна);
+ перемещать по слоям (меню, поверх других, под другими, десктопный уровень);
+ перемещать на другие рабочие столы;
+ сделать видимым на всех рабочих столах;
+ сделать пиктограммой в трее.

Также очень советую настроить горячие клавиши (хоткеи) под себя для запуска часто используемых приложений. Отредактируйте файл настройки ~/.icewm/keys для установки быстрых клавиш на запуск часто используемых программ. Кнопка Win (здесь она называется Super) на клавиатуре очень пригодится - должны же мы использовать эту подаренную нам микрософтом клавишу? Вот на неё и повесьте запуск приложений. Например, у меня они такие:

key "Super+t" xterm -font -misc-*-*-*-*-*-*-*-*-*-*-100-*-ru
key "Super+p" gimp
key "Super+z" xscreensaver
key "Super+q" scribus
key "Super+i" gqview
key "Super+w" /opt/openoffice.org2.0.4/program/swriter
key "Super+x" /opt/openoffice.org2.0.4/program/scalc
key "Super+Shift+i" /opt/openoffice.org2.0.4/program/simpress
key "Super+g" gnumeric
key "Super+a" xmms
key "Super+Shift+w" abiword
key "Super+m" firefox
key "Super+b" mozilla-thunderbird

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

Навешиваем рюшечки
Их не так много, как в других средах, но всё-таки есть. Первым делом я бы посоветовал подогнать комбинации клавиш управления окнами под себя - и вы забудете о мыши и тыканью по маленьким кнопочкам. Это отнимает время и силы - кроме того, вы теряете концентрацию внимания на том, что вы делаете. Через некоторое время горячие клавиши управления окнами будут отточены до уровня рефлекса, и вы перестанете замечать это.
Потом, можно поставить несколько полезных приложений. Как вам нравится полупрозрачный календарик? Тогда поставьте пакет gdeskcal, который есть в Debian:

apt-get install gdeskcal

и вы сможете видеть календарик на месяц, с полупрозрачностью, с возможностью смены тем, надписью на дате важных событий... Маленькая программа, но очень полезная, и к тому же интегрируется в трей IceWM.

Для созерцания ресурсов очень подойдёт программа torsmo или conky. Тоже есть полупрозрачность, а подогнать её под свои конкретные нужды помогает её конфиг .torsmorc, в котором можно поправить всё, что угодно. Однако чаще используется conky, как настроить conky можно прочитать здесь.

Ещё полезные программы - xpad и knotes. Это липкие записки, которые клеят на мониторы или холодильники - теперь тоже самое можно делать на рабочем столе. Knotes будет сидеть в трее и при нажатии на неё увидите все свои заметки. Вот как выглядит всё это в рабочем состоянии:


Если вас не устраивают обои, идущие с темой, можно поставить свои. Впрочем, это немного неочевидно - здесь я опишу этот процесс. Итак, идём в ~/.icewm/preferences, открываем на редактирование и ищем переменную DesktopBackgroundImage, которую меняем на:

DesktopBackgroundImage="/home/логин/.icewm/обои.jpg"

Никто не запрещает использовать KDEшные и GNOMEистые программы, которые любят лезть в трей. Например, для монтирования удалённых сетевых ресурсов я часто использую Smb4K, и он без всяких вопросов садится в трей IceWM. Несколько более капризен klaptop_check, который мониторит состояние батарей на ноутбуке: через 15-20 секунд после запуска пропадает с экрана. Но если запустить до него любое КДЕшное приложение, он сидит себе в трее IceWM как родное.

В общем, просто и со вкусом. Подобранные под себя хоткеи, обои и быстрые клавиши управления окнами делают IceWM незаметным, но незаменимым помощником при работе в графическом режиме, за что его и использую всё это время.

Что умеет IceWM?
Так как это оконный менеджер, а не навороченная среда, возможностей у него не так много - это тот самый компромисс, о котором я говорил выше. Многое придётся делать руками или ставить дополнительные программы, например, монтировать устройства. Впрочем, в этом есть положительный момент: вы привыкаете к эффективной работе, вешая всё на горячие клавиши и скрипты, подстраивая графическую оболочку под себя.

Итак, возможности IceWM:

+ панель задач, на которой отображаются запущенные приложения;
+ меню приложений, вложенные пункты меню;
+ трей, в котором есть часы, потребление процессорного времени, активность сетевых интерфейсов, значки приложений (поддерживает приложения, сворачивающиеся в трей);
+ смена обоев (правда, требуется перезагрузка иксов);
+ темы (разнообразные, в том числе имитирующие другие ОС);
+ независимые горячие клавиши;
+ переключение рабочих столов (по умолчанию 4, можно менять);
+ список окон, быстрая навигация по открытым окнам;
+ убирание панели задач с экрана (как в угол, так и вниз);
+ управление "слоями" окон;
+ всплывающие подсказки (на русском);
+ полная локализация (никаких проблем с кириллицей, для чего требует defoma и gsfonts).

Чего в IceWM можете не искать:

- значков на рабочем столе (есть ROX-filer);
- полупрозрачных окошек (только отвлекает от работы);
- навороченных конфигураторов (есть конфиги, простенькие графические конфигурялки).

Многие настройки можно включить в конфигах, которые, кстати, очень просты и обильно прокомментированы. Для тех, у кого идиосинкразия к конфигам, есть графические GTKшные конфигураторы - iceme (для изменения содержимого стартового меню в IceWM) и icepref (изменение настроек в ~/.icewm/preferences). Обе входят в дистрибутив Дебиан.

Так что если вы ищете простой, быстрый и функциональный оконный менеджер, посмотрите в сторону IceWM, и может быть, вы сочтёте для себя его стильную аскетичность подходящей. Вот каким он может быть:



Ссылки
Время от времени я пишу о всё новых замечательных возможностях, которые нахожу в IceWM. Например, о темах для IceWM - какими красивыми они бывают и откуда их взять. Или о том, что настройка IceWM может быть проведена из удобной графической панели управления. Другие справочные материалы и ответы часто задаваемые вопросы по IceWM на русском можно найти тут. А если и этого мало, то в IceWM есть ещё много возможностей, которые вам понравятся!

Читать далее

Knoppix Linux Math - Математические программы живьём

virens

11 коммент.

Иногда бывает полезно ознакомиться с программой, прежде чем её искать, качать и ставить. Для ознакомления с научными приложениями Linux есть замечательный живой дистрибутив Knoppix Linux Math, построенный на базе хорошо известного Кноппикса. Здесь рассматривается версия 5.0.1 Knoppix Linux Math, распространяемая на DVD.

Запуск и работа в Knoppix Linux Math не представляет никаких сложностей, однако по сравнению с обычным Кноппиксом имеется дополнительное меню, в котором перечислены специализированные программы.

И тут есть на что взглянуть! Имеется LaTeX с интегрированной средой Kile и TeXmacs, строитель графиков GNUplot, система численных расчётов GNU/Octave и символьных Maxima, пакет статистических расчётов GNU R, алгебраическая система GAP и другие приложения. Помимо них, есть и другие, не менее знакомые поклонникам свободных систем: OpenOffice.org, Scribus, Audacity, XMMS...

Редкие и малоизвестные программы
Заинтересовал пакет визуальной геометрии Dr.Geo. Наверное, он может подойти для обучения геометрии: программа позволяет создавать фигуры из примитивов и обладает довольно продвинутой системой управления ими.

Однако придётся привыкнуть к её нетривиальному интерфейсу: так, чтобы нарисовать окружность, сперва следует поставить точку центра (отдельным инструментом "Точки") и касательной. Хотя мысль интересная...

Также имеется генератор фракталов XaoS. Простой и понятный интерфейс: левая кнопка мыши - приближение, правая - отдаление, средней кнопкой можно перемещать фрактал внутри окна.

Можно вызвать заложенные фракталы и поменять их параметры, менять число итераций расчётов и прочее.

С помощью программы KALI можно изучать группы симметрии - очень удобно. Где же она была, когда я учил кристаллографию!?

Можно создавать симметричные структуры на основе имеющихся групп симметрии и сразу их просматривать.

Программа Surf умеет строить поверхности на основе своего собственного языка. С ним я пока не разобрался, поэтому сходу ничего построить не удалось :-)

Можно создавать симметричные структуры на основе имеющихся групп симметрии и сразу их просматривать.


Программы более известные
Конечно, для многих одним из главных инструментов работы является LaTeX и естественно, что на Knoppix Linux Math он имеется. Также есть оболочки для него на выбор: Kile 1.8 и TeXmacs 1.0.6.4, которые можно сразу попробовать в деле и решить, какая из них больше вам подходит. Или просто вооружиться любимым текстовым редактором (благо, их в Knoppix Linux Math великое множество).

Приятно видеть в сборе сразу такое количество серьёзных математических инструментов, как GNU/Octave, свободный аналог MATLAB, MAXIMA, из которой вышли Maple и MathCAD, GNU R - система статистических расчётов и другие. Это позволяет оценить их возможности, и уже после этого принимать решение, стоит ли их ставить и изучать.


Заключение
Целью этого краткого обзора было рассказать о существовании такой разновидности Knoppix Linux (и, соответственно, Debian GNU/Linux), которая способна проиллюстрировать многообразие математических программ без необходимости их установки. Бывает очень полезно предварительно ознакомиться с возможностями программы, или узнать о новых программах. В любом случае, этот живой дистрибутив стоит того, чтобы с ним познакомиться поближе.

На всякий случай, скачать Knoppix Linux Math (Математический Линукс) можно здесь.

Читать далее

Разбор завала документов: мысли, идеи, подходы

virens

3 коммент.

В предыдущих статьях по этой теме говорилось о применении программы SWISH++ для быстрой сортировки pdf-документов, а в этом посте приводились некоторые конкретные решения этого вопроса. Есть ещё несколько вопросов и идей насчёт разгребания завала документов.

Какие ещё завалы можно разобрать?
Теоретически любые, которые так или иначе сводятся к обработке текста. Если немного напрячь фантазию и порыться в репозитории, то можно таким же (или очень сходным манером) разгрести горы:
- скачанных HTML-страниц. Тут меня терзают смутные желания по поводу установки полновесного поискового движка mnogosearch, который под такие цели и заточен. Однако он потянет за собой Апача, который мне совсем не нужен;
- офисных документов. Здесь выруливает ОпенОфис, так как его документы - фактически сжатый XML, но можно поискать счастья и с вордовыми документами, для чего имеется программа antiword;
- тэгов в mp3/ogg - файлах. Если вы утруждаете себя их заполнением, то проблема поиска в этом случае сильно упрощается - SWISH++ их поддерживает изначально;
- документов LaTeX. То же самое: так как это фактически размеченный плоский текст, то проблем не возникает. Конечно, если они все на английском;
- простых плоских текстов. Например, у меня огромная библиотека художественной литературы в сжатой файловой системе SquashFS - индексирую её, индекс сохраняю там же, потом монтирую и прямо в сжатой файловой системе провожу поиск;
- pdf-файлов. Ну, про это я уже уши прожужжал :-) Накачал кучу статей по специальности, надо бы отсортировать. Не руками же, в самом деле.
Поиск и удаление дубликатов
Это то, что я не осветил в тех постах. Часто от жадности скачиваю сразу всё, а потом выясняется, что часть файлов у меня уже есть. Как их найти и потереть во всём многообразии уже имеющихся документов?
Ленивые линуксоиды должны были что-то придумать на этот счёт - придумать и включить в Дебиан. Так и есть: в репозитории ищем и находим очаровательную утилиту fdupes. Она сравнивает файлы как побайтово, так и с помощью подсчёта md5-суммы при том, что занимает какие-то пару сотен килобайт. Работает невероятно быстро, сортировка производится в полуавтоматическом режиме: программа выводит в консоли дублирующиеся файлы и спрашивает, какой из них оставить. Вот как это выглядит:

penta4@penta4rce:~$ fdupes -r -d /mnt/wd250Gb/my/matlab/Study/Statii/ImageProcessing/
[1] /mnt/wd250Gb/my/matlab/Study/Statii/ImageProcessing/Algorythms/Linear/Gabor/jei_2005.pdf
[2] /mnt/wd250Gb/my/matlab/Study/Statii/ImageProcessing/Algorythms/Linear/Gabor/jei_2004.pdf

Set 1 of 1, preserve files [1 - 2, all]:

Отвечаем, какие файлы оставить - остальные программа сразу снесёт. Будьте внимательны: восстановить их потом будет нелегко, если вообще возможно. У программы много настроек, она умеет отличать жёсткие и мягкие ссылки, искать рекурсивно и так далее - man fdupes много чего интересного рассказывает.

Заключение
Приведённые соображения (главным образом по pdf-документам) должны помочь в ленивом и продуктивном решении такой непростой задачи. Если у кого есть мысли по этому поводу - буду очень рад услышать и увидеть их в комментариях. Они открыты для всех :-)

Читать далее

Розыски пропавшего принтера: /dev/lp0 Recover Howto

virens

13 коммент.

Проблема: срочно надо было отпечатать страницу на лазерном принтере, подключённом к параллельному порту - а принтер пропал...

С чего всё началось
Давным-давно я настроил CUPS - настроил и, как полагается, забыл. Работал и работает, как швейцарские часы. И тут надо было срочно распечатать страничку на лазерном принтере HP LaserJet 5L из ОпенОфиса - без проблем: Файл - Печатать - LaserJet 5L. И... тишина. Вечером надо отпечатать, а утром нести - принтер пропал очень вовремя.

Два вопроса
Собственно, всё же работало. WTF!?
Пробую лёгкой артиллерией - попытался рестартовать подсистему печати:

/etc/init.d/cupsys restart

Никаких изменений. Пробую печатать на струйник HP DeskJet 930C, подключённый к USB - работает, но в нём засохли картриджи. Вечер перестаёт быть томным!

Снёс лазерный принтер в CUPS, заново его поставил. То же самое: принтер появляется, по при попытке на него что-то распечатать отключается: Printer stopped и пишет, что не может соединиться с принтером в течении 30 секунд. Значит, дело в принтере. И потом, usb-шный струйник печатает, а лазерник нет. Значит, дело не в CUPS и надо "что-то в консерватории поправить".

Кто виноват?
Иду в каталог /dev и тихо выпадаю в осадок: устройства lp0 там нет. Кто его удалил!? Первая мысль - шут с ним с аптаймом в 72 дня, перезагружу - должен появиться. Ведь до этого всё работало! Потом отдёрнул руку от shutdown и решил так просто не сдаваться (забегая вперёд - это был правильный шаг).

Иду в логи искать ответ на первый вопрос. Всё, как на зло, тихо и спокойно. Начинаю "грепать по сорцам", и тут мне /var/log/daemon.log конфиденциально сообщает, что принтер в отключке вот уж неделю как:

Sep 20 18:24:58 localhost udev[885]: configured rule in '/etc/udev/rules.d/udev.rules[28]' applied, 'lp0' becomes 'usb/%k' Sep 20 18:24:58 localhost udev[885]: creating device node '/dev/usb/lp0' Sep 20 18:25:10 localhost udev[919]: removing device node '/dev/usb/lp0' Sep 20 18:25:10 localhost udev[1005]: removing device node '/dev/lp0'

Так, теперь понятно, кто виноват - udev, разработчиков его мать :-) Ну подфортил, прямо душу порадовал. Но у нас есть mknod и MAKEDEV - и ещё есть маны по ним, но читать маны вместо подготовки к выступлению - это уж слишком экстремально.

Что делать?
Теперь второй вопрос вырисовывается более конкретно: надо либо читать маны по MAKEDEV, либо погуглить. Оказалось, что я далеко не одинок.
Натыкаюсь на рецепт:

./MAKEDEV -v lp

Применил. Да, можно сказать, полегчало, и оно создало аж три устройства, но в /dev/.static/dev/ - не здорово, то есть здорово, но не там. Хочу, чтобы было, как прежде. Но на всякий случай проверяю:

cat ~/new.text > /dev/.static/dev/lp0

Печать идёт, и это радует. Но из ООО и других программ тишина.
Ладно, гуглю дальше. И тут добрая душа выдаёт то, что я так долго ждал: команду для mknod с номерами устройства:

mknod -m 666 /dev/lp0 c 6 0

Применяю, получилось!
Возвращаюсь в веб-панель CUPS. Сношу принтер и тут замечаю, что в разделе URL есть заветное Parallel port. А я всё заставлял его печатать в HP JetDirect. Аааа... Вот где собака порылась! Ставлю его, сообщаю /dev/lp0 и выбираю модель принтера. Жму "отпечатать тестовую страницу" - есть!

Выводы: отвалившейся принтер - ещё не повод делать себе и системе харакири. Немного погуглив, проблему победил, знаниями обогатился и маны mknod буду обязательно курить.

Ссылки:
Здесь, собственно, даются параметры для создания mknod-ом ссылки на параллельный порт. Товарища по блогу постигла та же напасть, и он её превозмог.
Хорошо почитать об этом же здесь и тут могут быть полезные сведения.

Читать далее

Быстрая сортировка по релевантности PDF-документов: скрипты

virens

5 коммент.

Задача: с помощью поисковой машины SWISH++ искать и сортировать по каталогам pdf-документы
Решение: при помощи программы pdftotext, утилиты find, скриптовых языков Bash и Perl, а также некоторой смекалки и использования мощи линуксовой консоли, решаем проблему.

В этой статье я начал рассказ про замечательную поисковую систему SWISH++ и о том, как её приспособить под такие специфичные нужды, как поиск внутри pdf-документов. Здесь я напишу о том, как это автоматизировать ещё больше.

Вариант решения задачи
Как говорят поклонники Perl, "there is more than one way to do it". Я решил её так, если кто укажет на более лёгкий / правильный / экономичный / красивый путь - просьба отписаться в комментариях.
Итак, вкратце алгоритм таков:

• утилитой find ищем все документы pdf и вытаскиваем из них текст утилитой pdftotext
• индексируем найденные файлы программой index++
• задаёмся порогом релевантности (подбираем опытным путём)
• ищем по ключевым словам программой search++
• найденные файлы pdf перемещаем в каталог со словами поиска
• при необходимости повторить :-)

Ниже этот процесс описывается подробнее.

Поиск документов pdf и вытаскивание текста
Собственно, для этого просим утилиту find найти все файлы по маске *.pdf и для каждого выполнить вытаскивание текста программой pdftotext без выдачи предупреждений и без вставки символов разрыва страницы. Это делается командой:

find -name '*.pdf' -exec pdftotext -nopgbrk -q {} \;

С русским языком программа pdftotext дружит слабо, хотя и пытается что-то вытащить. Тем не менее, большинство статей на английском, так что это нам не страшно.

Построение индекса
Тут всё очень просто - просим index++ проиндексировать все текстовые файлы, начиная с текущего каталога:

index++ -e "text:*.txt" .

Точка в конце и означает, что поиск ведётся с текущего каталога.

Поиск по ключевым словам скриптом
На десерт - мой скрипт на PERL, который выполняет автоматизированный поиск и сортировку. Просьба аксакалов перловедения ногами не пинать - "не ругайте баяниста, он играет, как умеет". Цветовая разметка, сделанная в Kate, приведена для удобства чтения, скрипт подробно прокомментирован (чтобы я сам потом не забыл, что да как).

#! /usr/bin/perl
use strict;
# use warnings;

`index++ -e "text:*.txt" .`; #Создание индексированного списка текстовых файлов
в текущей директории с подробной выдачей статистики пользователю

# ### <-------- Блок создания переменных и определения порога
my $kmvThreshold = 30; #Обрубать по порогу: практика показала, что ниже
порога релевантности 30-40 документы не соответствуют критериям поиска
my $ii;
my $iimax;
### <-------- Блок создания переменных и определения порога


# ### <-------- Блок ввода запроса и организация каталога для перемещнения
туда найденный файлов
print "Query to PDF search?", "\n"; #Выдать запрос на ввод поисковой фразы
my $kmvQuery = ; #Поисковый запрос к базе индексированных файлов
 chop $kmvQuery;#обрубить символ возврата каретки

my $kmvNewDirName = $kmvQuery; #Создаём переменную для имени каталога
$kmvNewDirName =~ s/\s+//xgi; #Замена в тексте запроса пробелов для
создания каталога, в который будут перемещены найденные файлы
`mkdir $kmvNewDirName`;  #Создаём новый подкаталог в текущем каталоге,
в который будут перемещены найденные файлы
### <-------- Блок ввода запроса и организация каталога для перемещения
туда найденный файлов


# ### <-------- Блок обработки запроса
my @kmvSearchResultsRaw = `search++ $kmvQuery`; #Поиск по запросу и его результаты
$iimax = scalar @kmvSearchResultsRaw;#Размер массива результатов - сколько строк
### <-------- Блок обработки запроса


### <-------- Блок принятия решения о перемещении файлов в соответствии
    с релевантностью
for ($ii=0;$ii<$iimax;$ii++) #перебираем в цикле строки
{
my $kmvCurrent = substr($kmvSearchResultsRaw[$ii],0,3);#берём первые три
символа - информация о релевантности (три - так как она может быть и 100)
 if (int $kmvCurrent > 0 and $kmvCurrent > $kmvThreshold) #Если в строках
первое число и оно больше порога (может быть и не число, а количество найденных совпадений)
 {
my ($kmvResultRelev,$kmvResultHomeName,$kmvResultFilesize,$kmvResultFilename) =
($kmvSearchResultsRaw[$ii] =~ m/(\S+)\s(\S+)\s(\S+)\s(\S+)/xgi);
#Эта строка стоила мне половину вечера курения книги по Перл.
Для "Не Достигших Полного Просветления на Пути Perl" объясню всю эту адскую конструкцию.
Строка $kmvSearchResultsRaw[$ii] разбирается на четыре переменные (которые слева)
по следующему сценарию: (символы_не_пробела) пробел  (символы_не_пробела) пробел
(символы_не_пробела) пробел (символы_не_пробела) - поиск глобальный
(не до первого совпадения), допускает пробелы и не учитывает регистра.
 $kmvResultFilename =~ s/.txt/.pdf/xgi; #Выданное имя файла txt заменяется на pdf
 print "Moving ", $kmvResultFilename, "\n"; #напечатать сообщение о перемещении
     найденного файла
 `mv $kmvResultFilename $kmvNewDirName`; #перемещение найденного файла в
   новый каталог
 }
}
### <-------- Блок принятия решения о перемещении файлов в соответствии
    с релевантностью

Что-то вроде этого. Может быть, в скрипте есть некоторые топорные решения, но мне не до изящества кода - надо архивы разгребать.

Плоды прогресса
Проведение натурных экспериментов показало достаточно высокую точность и адекватность сортировки. Запрашивая сначала по точным критериям, а потом по всё более общим (запросы два-три слова), я разгрёб 2400 документов за полтора часа. Задача для системы усложнялась тем, что тексты были однородны по тематике. Точность (после визуального сравнения) составляет где-то 60-70%. Конечно, отобранный материал пробегается глазами по заголовкам, то есть реализуется полуавтоматический режим.
Впереди ещё оптимизация поиска, надо будет подучить систему немного, и тогда уже вволю конкурировать с Гуглом и Яндексом.

Читать далее

Быстрая сортировка по релевантности PDF-документов: нам поможет SWISH++

virens

6 коммент.

Задача: имеется куча скачанных статей в формате PDF и нужно их сортировать по каталогам.
Решение: можно сидеть и уродоваться месяц, если документов несколько тысяч, а можно воспользоваться свободной поисковой машиной SWISH++

Зачем всё это надо
Всё очень просто: я накачал кучу хороших (и не очень) статей по своей специальности с целью расширить кругозор, и теперь надо все эти PDF файлы рассортировать по каталогам. И потом желательно иметь возможность искать внутри них информацию - и не просто по совпадению, а по релевантности: я не помню, в каком pdf-нике находится нужный мне обзор, а имена файлов типа 1234Njhsd.pdf мне мало что говорят. Быть может, это позволяет сделать Beagle, но попробуем обойтись более простыми и лёгкими средствами, которые есть в Дебиан.

Идея!
Некоторое время посидев и потыкав по pdf-никам и пытаясь ручонками всё это разобрать, я понял, что надо это спихнуть на машину. Сел и начал думать, методично прочёсывая свой локальный репозиторий Дебиана apt-cache search-ем.
Итак, что я хочу? Возможность искать внутри pdf-файлов, но для этого нужно из них выдрать текст. Это несложно, ведь имеется программа pdftotext. В результате своей деятельности она создаёт файл с таким же названием, но расширением txt. Отлично, половина задачи решена. Теперь надо искать по релевантности внутри текстовых файлов.
Из пришедших в голову идей:

• поставить небольшой спам-фильтр, типа ifiles, и натренировать его сортировать кидаемые в него текстовые файлы по каталогам.

Плюсы: через некоторое время статьи сами будут попадать, куда надо, но для этого придётся учить баесовский алгоритм.
Минусы: нужно заранее знать всю структуру каталогов, что невозможно, трудно добавлять новые (придётся снова учить алгоритм), нетривиальная сортировка самих документов.

• поставить какую-нибудь поисковую машину типа mnogosearch, но оно очень здоровое и работает с HTML, а нужен плоский текст.

Плюсы: наверное, с релевантностью там нормально;
Минусы: но это уже стрельба из крейсера по птицам ;-)

• поставить поисковую машину SWISH++ в качестве простого, быстрого, гибкого и неприхотливого локального поисковика.

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

Короче, поставил SWISH++. Прекрасно, осталось написать перловый скрипт с разбором результата выдачи, отсекать файлы, не проходящие по порогу релевантности и перемещать их в каталог, соответствующий запросу. И кто там свистел про смерть unix-way!? А? Разбежались по кустам? То-то же! :-)

О поисковой машине SWISH++
Сведений об этой поисковой машине в Сети не просто мало - их почти нет. Только статья о применении этой системы для серьёзных поисковых запросов. Некоторыми товарищами считается самой быстрой поисковой системой.
Из описания дебиановского пакета можно немного узнать об этой программе - Простой Системе Индексации Для Людей. В основном предназначена для использования в качестве простого и быстрого поискового движка, полностью переписана на C++.
Основные возможности SWISH++

• Индексирование файлов с тэгами
• Разумное индексирование почтовых и новостных файлов
• Индексирование man-страниц
• Применение фильтров "на лету" вместо индексирования
• Индексирование не-текстовых файлов типа Micorosoft Office (требуется antiword)
• Модульная архитектура индексирования
• Избирательное индексирование новых файлов
• Индексирование удалённых веб-сайтов
• Обработка больших коллекций файлов
• Молниеносная скорость поиска
• Настраиваемое игнорирование слов
• Возможность запуска как поискового сервера (демонизация)
• Лёгкий для разборки формат выдачи результатов
• Тщательно прокомментированный исходный код

Система SWISH++ состоит из двух программ: index++ и search++. Первая программа отвечает за индексирование, вторая программа ищет файлы по запросам в файле индекса. Типа Гугла, только маленького (600 Кб) и настольного.

Индексация файлов
Программа index++ проводит индексацию текстовых документов: текст, HTML, XML, LaTeX, почта - всё, что представляет собой по сути простые текстовые файлы но, быть может, со вкраплениями служебных тегов. Индексация проводится очень быстро - на Р4 630 (3ГГц) и 2Гб DDRAM каталог из 270 файлов индексируется за 5 секунд, хотя автор программы предупреждает, что индексация - дело, требующее много памяти.
Поставив уровень подробности 3, можно попросить систему выводить информацию в процессе индексирования. Уровень подробности на индексацию не влияет, по умолчанию программа действует без шума и пыли.
Для индексации (с выводом подробной информации и процессе) текстовых файлов с расширением txt в текущем каталоге и во вложенных рекурсивно даём команду:

index++ -v3 -e "text:*.txt" .

Точка в конце важна, читаем мануал и узнаём почему. Вывод будет примерно такой:

watters_etal_paleobio_2001.txt (2704 words)
WaveMetriconChip64.txt (1351 words)
wshedtopoalgoJMIV.txt (4042 words)
Ye.IJDAR.1.txt (4470 words)
YucelITIP01.txt (1678 words)
./edg:
morphology.txt (753 words)
LuengoEtAl_IbPRIA05.txt (1227 words)
Cuisenaire2005_1250.txt (1162 words)
icpr2004_nucleus.txt (1234 words)
OrtizEtAl_SPIE01.txt (1463 words)
Angulo_VIIP04.txt (1658 words)
682.txt (1901 words)
comorph.txt (1948 words)
index++: ranking index...
index++: writing index...
index++: done: 00:05 (min:sec) elapsed time 548 files,
271 indexed 2465116 words, 1046139 indexed, 56281 unique

В результате в текущем каталоге появится файл swish++.index где лежат сведения о проиндексированных файлах. Отлично: такая куча файлов так быстро проиндексирована. Теперь мы готовы искать интересующие нас документы. В конце мануала (краткого, но очень толкового) приводятся ссылки на литературу - чувствуется, автор в этом деле поднаторел очень крупно.

Поиск файлов
Программа search++ ищет по запросу в индексированной базе swish++.index, созданной программой index++. Ну, для примера поищу-ка я в этой базе статьи по математической морфологии, в которых нет упоминания про медицину:

$ search++ morphology and erosion and dilation not medicine

Мгновение спустя вижу результат (вывод сокращён):

# results: 125
99 ./Krylov2.txt 3771 Krylov2.txt
49 ./13300407.txt 3103 13300407.txt
46 ./morph1.slides.printing.6.txt 4369 morph1.slides.printing.6.txt
37 ./lecture_morphology_sara.txt 6746 lecture_morphology_sara.txt
30 ./SIGGRAPH2002_Sketch-Mitchell.txt 5308 SIGGRAPH2002_Sketch-Mitchell.txt
26 ./MorphologicalImageProcessing.txt 7642 MorphologicalImageProcessing.txt
25 ./phdsymp2002_ledda.txt 8298 phdsymp2002_ledda.txt
23 ./lab2_manual.txt 9313 lab2_manual.txt
23 ./Project 1.txt 9946 Project 1.txt
22 ./morphology.txt 11212 morphology.txt
22 ./edg/morphology.txt 11212 morphology.txt
22 ./slides-6-geometry.txt 11717 slides-6-geometry.txt
22 ./V1BFOGG8.txt 10797 V1BFOGG8.txt
18 ./71650638.txt 13978 71650638.txt

Первая колонка - релевантность, вторая - расположение файла относительно текущей директории, третья - размер файла, четвёртая - имя. Просто и понятно. Можно использовать, как в любом поисковике, AND и NOT для задания более подробной выборки. Анализируя результат поиска, могу сказать, что при релевантности ниже 40-30 можно смело не смотреть тексты - они явно не о том. Результаты этого поиска, кстати, очень даже адекватные: именно это меня и побудило написать скрипты для потоковой сортировки PDF-ников. Но об этом в следующем посте.

Ссылки:
Всё про эту систему рассказать в одном посте просто нереально. Привожу те крохи, которые наскрёб гугл, яху и яндекс по этой замечательной программе.
Домашняя страница проекта на сорсфорж. Здесь много информации по поисковым движкам, и, в частности, про SWISH++, а также статья по поиску в базах данных с использованием перловых скриптов. Документация по SWISH-e, предка SWISH++.

Читать далее