[Comm] LyX

[Comm] LyX

[Oleg Vladimirovich]

Всеобщий привет !

Открыл для себя LyX - обалденная вещь !
Но : захожу "Формат/Стиль символов/Язык/Украинский", однако ни единого
символа (буквы) означенного языка (их всего, отличных от Русского - 3 штуки)
ввести не могу. Зачем тогда режим  "Формат/Стиль символов/Язык/......." ?

Спасибо за внимание.
С уважением, Олег Вл.

Re: [Comm] LyX

[Alexej Kryukov]

On Friday 05 September 2003 19:40, Oleg Vladimirovich wrote:
> Всеобщий привет !
>
> Открыл для себя LyX - обалденная вещь !
> Но : захожу "Формат/Стиль символов/Язык/Украинский", однако ни
> единого символа (буквы) означенного языка (их всего, отличных от
> Русского - 3 штуки) ввести не могу. 

В LyX начиная с версии 3.0 сломан ввод национальных символов.
Но это относится только к xforms-сборке. Собирайте его с qt
и всё будет OK. Да и выглядит приятнее.

> Зачем тогда режим  "Формат/Стиль
> символов/Язык/......." ?

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

Re: [Comm] LyX

[DM]

Hello, Oleg!

On Fri, 5 Sep 2003 19:40:33 +0400 You wrote:

> Открыл для себя LyX - обалденная вещь !
> Но : захожу "Формат/Стиль символов/Язык/Украинский", однако ни
> единого символа (буквы) означенного языка (их всего, отличных
> от Русского - 3 штуки) ввести не могу. Зачем тогда режим 
> "Формат/Стиль символов/Язык/......." ?
 
Простейший совет: открой для себя LaTeX и сопутствующие ему tetex и kile. 
Сначала будет посложнее, зато потом... По крайней мере, не будешь привязан
к конкретному редактору. 

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

-----------------------------------------------
DM: dead underscore m at list point ru

Re: [Comm] LyX

[Gleb Kulikov]

В сообщении от 6 Сентябрь 2003 02:49 DM написал:
> Простейший совет: открой для себя LaTeX и сопутствующие ему tetex и 
> kile.
^^^^^^^
Это что?

-- 
			Салют, /GLeb

Re: [Comm] LyX

[Alexej Kryukov]

On Friday 05 September 2003 23:49, DM wrote:
> Hello, Oleg!
>
>
> LyX изначально неплох, но ввиду постоянно возникающих проблем с
> локализацией (их периодически правят, они опять появляются; видимо,

Хм... Сколько я знаю, в версии 3.* проблема только одна, и править
ее никто даже и не пытался. Однако она возникает, только
если использовать xforms. Lyx с qt -- это совсем другое дело.

> авторы не прилагают в этом направлении усилий, всё держится на
> патчерах, которые иногда не успевают) я от него отказался. Однажды
> перевёл все наработанные тексты в чистый LaTeX и с тех пор не знаю
> проблем.

Ну, для несложных документов использование LyX вполне оправдано.

Re: [Comm] LyX

[DM]

Hello, Alexej!

On Sat, 6 Sep 2003 13:04:15 +0400 You wrote:

> > LyX изначально неплох, но ввиду постоянно возникающих проблем
> > с локализацией (их периодически правят, они опять появляются;
> > видимо,
> 
> Хм... Сколько я знаю, в версии 3.* проблема только одна, и
> править ее никто даже и не пытался. Однако она возникает,
> только если использовать xforms. Lyx с qt -- это совсем другое
> дело.

Когда выходила первая версия LyX под qt у меня что-то не пошло.
Разбираться не стал, поскольку к тому моменту уже отказался от
его использования, и интерес был чисто спортивным. А проблемы с
локализацией были как минимум три (все в версии xforms): не
вводились с клавиатуры локализованные символы, путались кодировки
(при локали 1251 символы воспринимались в koi8-r), и при экспорте
в LaTeX в выходной файл автоматически попадала запись о кодировке
koi8, независимо от того, какая на самом деле установлена у
пользователя. Кстати, они были не только у меня, я видел их в
багтраке Альта. 

> Ну, для несложных документов использование LyX вполне
> оправдано.

Сейчас, ИМХО, уже нет. Было, пока не появилась нормальная версия
OO. Для чего-то масштабов книги чистый LaTeX удобнее, если его
хотя бы по минимуму знать, а для заявлений, закладных,
объяснительных и пояснительных ОО подходит лучше, особенно если
учесть его наличие и под Win тоже.

А так, что он даёт? Мои воспоминания, основанные на версиях
примерно годовалой давности, примерно следующие.

Формат файла у него собственный, никем больше не поддерживается,
ладно хоть не закрытый :-) . Мне, кстати, действительно
непонятно, что заставило разработчиков сделать свои собственные
особенности форматирования, а не поддерживать стандартный LaTeX
--- второй вариант был бы гораздо удобнее во всех отношениях.

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

Визуализация условная. Ну и зачем мне условная визуализация, если
я и так в состоянии отличить {enumerate} от {itemize}. А точную
визуализацию всё равно даёт только полная генерация ps или pdf,
что опять-таки доступно в связке <<любимый редактор LaTeX>>.

Если с тех пор что-то серьёзно изменилось, буду рад. 
Но сомневаюсь.

-----------------------------------------------
DM: dead underscore m at list point ru

Re: [Comm] LyX

[DM]

Hello, Gleb!

On Sat, 6 Sep 2003 10:06:23 +0700 You wrote:

> В сообщении от 6 Сентябрь 2003 02:49 DM написал:
> > Простейший совет: открой для себя LaTeX и сопутствующие ему
> > tetex и 
> kile.
> ^^^^^^^
> Это что?

$>apt-cache search kile

kile - LaTeX source editor - TeX shell.

Есть в Мастере, есть в Сизифе, про другие не знаю, но, вероятно,
должон быть. Редактор, сделанный на основе kate, для
редактирования текстов в LaTeX. На мой вкус, довольно удобная
штука. 

Если ты фанат emacs, то и там есть режимы редактирования
TeX/LaTeX (я не фанат emacs, так что кроме как об их
существовании, ничего о них сказать не могу).


-----------------------------------------------
DM: dead underscore m at list point ru

Re: [Comm] LyX

[Alexej Kryukov]

Спасибо за развернутый ответ, приятно пообщаться на эту тему :-)

On Monday 08 September 2003 00:38, DM wrote:

> Когда выходила первая версия LyX под qt у меня что-то не пошло.

Вроде теперь в Сизифе есть сборка с qt. Лично я его собирал
под разные дистрибутивы и вручную, и из src.rpm, и никогда 
никаких проблем не видел.

> Разбираться не стал, поскольку к тому моменту уже отказался от
> его использования, и интерес был чисто спортивным. А проблемы с
> локализацией были как минимум три (все в версии xforms): не
> вводились с клавиатуры локализованные символы, путались кодировки

Вот именно. Но это не отдельная проблема, а та же самая, 
что и ниже.

> (при локали 1251 символы воспринимались в koi8-r), и при экспорте

Есть такое дело. Строго говоря, там даже не koi8, а просто 
бессмыслица, которая случайно с ней совпадает, а могла бы не
совпадать ни с чем. Но это относится именно к xforms с ее 8-битным
вводом. А qt внутри юникодовая, и ей всё равно, во что конвертировать.
Так вот там входная кодировка *настраивается*: достаточно
изменить одну запись в файле lyx/languages (который для этого
имеет смысл скопировать к себе в ~/.lyx).

> в LaTeX в выходной файл автоматически попадала запись о кодировке
> koi8, независимо от того, какая на самом деле установлена у

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

> пользователя. Кстати, они были не только у меня, я видел их в
> багтраке Альта.
>
> > Ну, для несложных документов использование LyX вполне
> > оправдано.
>
> Сейчас, ИМХО, уже нет. Было, пока не появилась нормальная версия
> OO. Для чего-то масштабов книги чистый LaTeX удобнее, если его
> хотя бы по минимуму знать, а для заявлений, закладных,
> объяснительных и пояснительных ОО подходит лучше, особенно если
> учесть его наличие и под Win тоже.

Это, конечно, дело вкуса. Я приведу лишь одно соображение:
возможна ведь ситуация, когда хочешь
сочинить документ, особенно не напрягаясь, но при этом допускаешь
возможность дальнейшей его доработки в чистом LaTeX. Вот
в этом случае LyX является неплохим выбором, хотя бы потому,
что дает на выходе лучший LaTeX-код, нежели любой фильтр
типа word2tex. Кстати, преобразование из OOo в LaTeX пока
что представляет проблему (есть проект writer2latex, который
выглядит многообещающе, но в текущем виде, по-моему, 
неработоспособен).

> А так, что он даёт? Мои воспоминания, основанные на версиях
> примерно годовалой давности, примерно следующие.
>
> Формат файла у него собственный, никем больше не поддерживается,
> ладно хоть не закрытый :-) . Мне, кстати, действительно
> непонятно, что заставило разработчиков сделать свои собственные
> особенности форматирования, а не поддерживать стандартный LaTeX
> --- второй вариант был бы гораздо удобнее во всех отношениях.

Я об этом писал когда-то на Софтерре. По моим понятиям, смысл этого
формата в том, что он -- машинно-ориентированный, т. е. предназначен
для того, чтобы *однозначным* способом фиксировать все телодвижения
пользователя. А вот когда дается команда на компиляцию, тогда
уже можно посмотреть, каким способом *лучше* перевести разом
весь документ в latex. Именно поэтому на выходе получается
относительно читаемый latex-код. В отличие, например, от HTML,
генерируемого визуальными редакторами.

> Возможности --- тот же урезанный LaTeX, причём выброшенного
> иногда не хватает. Поддержки под Win без костылей (aka CygWin)

А зачем она нужна? Задачу обмена документами это бы не облегчило,
веь установка LyX всё равно потянет за собой полное дерево TeX.
Передавать кому-то сидящему на винде исходники в формате latex
тоже ведь практически нереально, хотя tex под винду и существует.
Как ни верти, а нужно компилировать pdf и распространять именно его.

> нету. Если бы не периодически возникающие глюки, его можно было
> бы, действительно, пользовать как текстовый процессор для
> несложных текстов. Но глюки есть. Если бы была возможность
> нормально и _полно_ редактировать таблицы (то есть формировать
> таблицы если не всех, то хотя бы большинства типов, доступных в
> LaTeX, динамически их менять и перенастраивать) можно было бы
> терпеть даже глюки. Но возможности нет.

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

Re: [Comm] LyX

[DM]

Hello, Alexej!

On Mon, 8 Sep 2003 13:20:06 +0400 You wrote:

> Вроде теперь в Сизифе есть сборка с qt. Лично я его собирал
> под разные дистрибутивы и вручную, и из src.rpm, и никогда 
> никаких проблем не видел.

Вот сейчас поставил LyX-qt и проверил. lyx-qt-1.3.1-alt2

Результаты:

1. Меню: <<Помощь/Введение>>. Выводится текст явно в koi-8 (у меня 1251). 

2. Открываю свой старый текст в lyx. Текст в 1251, поле
inputencoding в документе заполнено как auto. Текст
воспринимается в koi-8. Руками меняю имя кодировки в файле на
cp1251 --- никакого эффекта. В то же время новый файл создаётся
LyX с нормальными настройками. Видимо, глюк из-за совокупного
влияния разных версий LyX и настроек. Прямо перекодировал файл в
koi8, после этого он всё-таки открылся правильно. Но вот
почему-то подписи на рисунках (технические, которые выводит LyX
для указания интервалов) оказались явно не в той кодировке
(только при просмотре в LyX, в PS-выводе всё нормально). Кнопка
<<Оглавление>> имеет надпись в koi8, само оглавление в окне
выводится в той же самой koi8 (хотя в PS, опять-таки, всё
правильно). Кнопки <<Сноска>>, разбросанные по тексту, также
имеют надписи в koi8.

3. Создаю новый файл, ввожу в него русский текст. Явно указываю
кодировку 1251. Экспортирую его в LaTeX. Результат: в файле явно
прописана строка

\usepackage[cp1251]{inputenc}

но при этом текст почему-то экспортнулся в кодировке koi8-r.

(Кстати, в предыдущем письме я, видимо, ошибся. Память иногда
подводит :-) Ошибка при экспорте состояла именно в том, что
_текст_ экспортировался в koi-8, независимо от фактической и
прописанной в настройках кодировки).

Резюме по экспресс-проверке:

1. Глюки с клавиатурным вводом русского текста, имевшие место
ранее, не замечены. 

2. Глюки с кодировками при импорте-экспорте и с работой в среде с
кодировкой 1251, по крайней мере, частично, сохранились.

Надо будет сползать на bugs. Если там закрыли виденные мной
записи об этих багах, обновить, чтоли...

> Это, конечно, дело вкуса. Я приведу лишь одно соображение:
> возможна ведь ситуация, когда хочешь
> сочинить документ, особенно не напрягаясь, но при этом
> допускаешь возможность дальнейшей его доработки в чистом LaTeX.

А вот эта возможность мне представляется, скорее, теоретической.
Маленький текст, который требует специфического (а значит, почти
наверняка, визуального, а не структурного) форматирования и при
этом впоследствии будет куда-то вставлен? Что это может быть?
_Мне_ в голову не приходит. _У меня_ обычно либо достаточно
большие тексты в LaTeX, либо повседневные документы в ОО. 

> > Формат файла у него собственный, никем больше не
> > поддерживается, ладно хоть не закрытый :-) . Мне, кстати,
> > действительно непонятно, что заставило разработчиков сделать
> > свои собственные особенности форматирования, а не
> > поддерживать стандартный LaTeX--- второй вариант был бы
> > гораздо удобнее во всех отношениях.
> 
> Я об этом писал когда-то на Софтерре. По моим понятиям, смысл
> этого формата в том, что он -- машинно-ориентированный, т. е.
> предназначен для того, чтобы *однозначным* способом фиксировать
> все телодвижения пользователя. А вот когда дается команда на
> компиляцию, тогда уже можно посмотреть, каким способом *лучше*
> перевести разом весь документ в latex. Именно поэтому на выходе
> получается относительно читаемый latex-код. В отличие,
> например, от HTML, генерируемого визуальными редакторами.

Пардон, но кто мешал определить все особенности форматирования в
виде команд LaTeX'а, собрать эти команды в стандартный набор и
подключать его к каждому документу обыкновенным \include ? Чтобы
сам файл оставался всегда правильным LaTeX-исходником и мог
обрабатываться непосредственно? Если бы это было так, то я
проигнорировал бы _все_ перечисленные мной недостатки. Глюки
можно побороть, а удобный и специализированный LaTeX-редактор на
дороге не валяется.

> > иногда не хватает. Поддержки под Win без костылей (aka
> > CygWin)
> 
> А зачем она нужна? Задачу обмена документами это бы не
> облегчило, веь установка LyX всё равно потянет за собой полное
> дерево TeX. 

А это личные особенности. Дома я давно сижу под Linux, всё, что
не касается основного места работы, делается под ним, но иногда
дома делается что-то для работы, а иногда на работе --- что-то
для дома. На работе винда. Поэтому _мне_ удобнее ОО, чем LyX. За
других, естественно, не расписываюсь :-)

> Передавать кому-то сидящему на винде исходники в
> формате latex тоже ведь практически нереально, хотя tex под
> винду и существует. 

А вот тут --- позвольте не согласиться. У меня дома рабочая среда
для крупных текстов: Linux + tetex + kile. На работе win2000 +
MikTeX + TeXnic Center (мож, где в названиях 'c' с 'k' перепутал,
ну да ладно). Всё вполне совместимо и переносимо. 

> Как ни верти, а нужно компилировать pdf и
> распространять именно его.

Распространять --- да. А обмениваться рабочими вариантами текстов
--- ни разу. 

> Возможность редактирования таблиц имеется. Пусть даже она
> неполная, но для кого-то это всё равно удобнее, чем создавать
> таблицу в LaTeX вручную. 

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

-----------------------------------------------
DM: dead underscore m at list point ru

Re: [Comm] LyX

[Alexej Kryukov]

On Tuesday 09 September 2003 00:28, DM wrote:
> Hello, Alexej!
>
> Вот сейчас поставил LyX-qt и проверил. lyx-qt-1.3.1-alt2

Текущая версия 1.3.2.

> Результаты:
>
> 1. Меню: <<Помощь/Введение>>. Выводится текст явно в koi-8 (у меня
> 1251).
>
> 2. Открываю свой старый текст в lyx. Текст в 1251, поле
> inputencoding в документе заполнено как auto. Текст
> воспринимается в koi-8. Руками меняю имя кодировки в файле на
> cp1251 --- никакого эффекта. В то же время новый файл создаётся

Да без толку ее менять. Я же говорю, что данное поле влияет
только на запись опций пакета inputenc, больше ни на что.

> LyX с нормальными настройками. Видимо, глюк из-за совокупного
> влияния разных версий LyX и настроек. 

В совокупное влияние различных версий я не очень верю.
Пользовательский файл preferences всего один, и он 
перезаписывается после каждого захода в окно настроек.

> Прямо перекодировал файл в
> koi8, после этого он всё-таки открылся правильно. Но вот
> почему-то подписи на рисунках (технические, которые выводит LyX
> для указания интервалов) оказались явно не в той кодировке
> (только при просмотре в LyX, в PS-выводе всё нормально). Кнопка
> <<Оглавление>> имеет надпись в koi8, само оглавление в окне
> выводится в той же самой koi8 (хотя в PS, опять-таки, всё
> правильно). Кнопки <<Сноска>>, разбросанные по тексту, также
> имеют надписи в koi8.

Все эти фокусы оттого, что qt стремится вывести текст в локальной
кодировке, а LyX настроен на koi8. Потому что Вы, судя по всему,
файл languages так и не поправили. Вот и поправьте. Строка,
относящаяся к русскому, должна принять следующий вид:

russian     russian	"Russian"	false  cp1251     ru	 ""

Единственно, русская справка так и будет открываться кракозябрами,
если не перекодировать ее в 1251. Тут уж ничего не поделаешь: 
если мы настроили LyX на cp1251, то только ее он и будет 
использовать для русского. Всё остальное (надписи "сноска" уж
во всяком случае) должно стать читаемым.

>
> 3. Создаю новый файл, ввожу в него русский текст. Явно указываю
> кодировку 1251. Экспортирую его в LaTeX. Результат: в файле явно
> прописана строка
>
> \usepackage[cp125настрое1]{inputenc}
>
> но при этом текст почему-то экспортнулся в кодировке koi8-r.

Вот по этому самому, что в файле languages прописана koi8.

> (Кстати, в предыдущем письме я, видимо, ошибся. Память иногда
> подводит :-) Ошибка при экспорте состояла именно в том, что
> _текст_ экспортировался в koi-8, независимо от фактической и
> прописанной в настройках кодировки).

Ага.

> > Это, конечно, дело вкуса. Я приведу лишь одно соображение:
> > возможна ведь ситуация, когда хочешь
> > сочинить документ, особенно не напрягаясь, но при этом
> > допускаешь возможность дальнейшей его доработки в чистом LaTeX.
>
> А вот эта возможность мне представляется, скорее, теоретической.
> Маленький текст, который требует специфического (а значит, почти
> наверняка, визуального, а не структурного) форматирования и при
> этом впоследствии будет куда-то вставлен? Что это может быть?
> _Мне_ в голову не приходит. _У меня_ обычно либо достаточно
> большие тексты в LaTeX, либо повседневные документы в ОО.

Ну, вот сейчас я работаю над памяткой для авторов, которая
вся пронумерована по пунктам и разбита на разделы
(типично логическое форматирование).
Потом, возможно, понадобится сделать из нее брошюру --
тогда буду доделывать в latex. Но пока не надо.
Или можно набирать небольшую статью, если известно, что
весь сборник будет верстаться в LaTeX.

> Пардон, но кто мешал определить все особенности форматирования в
> виде команд LaTeX'а, собрать эти команды в стандартный набор и
> подключать его к каждому документу обыкновенным \include ? Чтобы
> сам файл оставался всегда правильным LaTeX-исходником и мог
> обрабатываться непосредственно? Если бы это было так, то я
> проигнорировал бы _все_ перечисленные мной недостатки. Глюки
> можно побороть, а удобный и специализированный LaTeX-редактор на
> дороге не валяется.

Вы меня не поняли. Приведу простой пример. Скажем, пользователь
переключил язык с русского на немецкий (а если это сделать,
то можно даже вводить умляуты, и они будут адекватно отображаться).
Спрашивается, нужно ли здесь вставлять \selectlanguage{german},
или заключать последующий текст в аргумент \foreignlanguage{german}
{...}? Если там будет одно-два слова, то, очевидно, второе, а
если целый абзац, то первое. Но откуда же программе знать, чтО будет
дальше, если текст только еще вводится? Вот поэтому LyX в обоих
случаях ставит свою внутреннюю команду \lang, а уже потом,
при компиляции документа, разбирается, как его перегонять
в latex.

По тому же алгоритму можно было бы делать выбор между командами
форматирования типа \textbf{...} и декларациями типа \textbf (хотя
в действительности вот этой разницы LyX не понимает). В общем, 
стоит задача *упростить* разметку, сделав ее однозначной. 
А Вы, наоборот, предлагаете всё усложнить путем введения 
каких-то специфических команд, подключаемых через
\include.

Да и почему Вам непременно надо, чтобы файл мог обрабатываться
непосредственно? Экспортировать-то в latex можно в любой
момент, и это фактически делается при каждой компиляции.

> А это личные особенности. Дома я давно сижу под Linux, всё, что
> не касается основного места работы, делается под ним, но иногда
> дома делается что-то для работы, а иногда на работе --- что-то
> для дома. На работе винда. Поэтому _мне_ удобнее ОО, чем LyX. За
> других, естественно, не расписываюсь :-)

Я бы не противопоставлял одно другому. Да, без OOo прожить
практически нереально. Но есть случаи, когда LyX удобнее.

> > Передавать кому-то сидящему на винде исходники в
> > формате latex тоже ведь практически нереально, хотя tex под
> > винду и существует.
>
> А вот тут --- позвольте не согласиться. У меня дома рабочая среда
> для крупных текстов: Linux + tetex + kile. На работе win2000 +
> MikTeX + TeXnic Center (мож, где в названиях 'c' с 'k' перепутал,
> ну да ладно). Всё вполне совместимо и переносимо.

Для себя -- да, конечно. А еще можно поставить gvim или emacs --
с ними под винду работать так приятно, что потом на linux
возвращаться не захочется :-) Но не обязаны же все хорошие
юниксовые программы иметь виндовые версии.

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

Re: [Comm] LyX

[DM]

Hello, Alexej!

On Tue, 9 Sep 2003 01:46:30 +0400 You wrote:

> > Вот сейчас поставил LyX-qt и проверил. lyx-qt-1.3.1-alt2
> 
> Текущая версия 1.3.2.

Уж какая была...

> В совокупное влияние различных версий я не очень верю.
> Пользовательский файл preferences всего один, и он 
> перезаписывается после каждого захода в окно настроек.

Ну а что? Если два lyx-файла, в обоих прописано cp1251, в обоих
текст в этой же кодировке, но один открывается нормально, а
другой нет?

> Все эти фокусы оттого, что qt стремится вывести текст в
> локальной кодировке, а LyX настроен на koi8. Потому что Вы,
> судя по всему, файл languages так и не поправили. Вот и
> поправьте. Строка, относящаяся к русскому, должна принять
> следующий вид:
> 
> russian     russian	"Russian"	false  cp1251     ru	 ""

Большое спасибо! Наконец мне объяснили, что надо делать. 
Теперь работает. 

Риторический вопрос: а почему при установке не проверяется хотя
бы системная локаль? Почему при наличии кучи поддерживаемых
кодировок не сделано элементарное: настройки кодировки не
вынесены в отдельные пакеты, из которых нужно поставить один? 

Почему, блин, нигде в печатной доке про это не написано?

Я балдею :-)

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

> Ну, вот сейчас я работаю над памяткой для авторов, которая
> вся пронумерована по пунктам и разбита на разделы
> (типично логическое форматирование).
> Потом, возможно, понадобится сделать из нее брошюру --
> тогда буду доделывать в latex. Но пока не надо.
> Или можно набирать небольшую статью, если известно, что
> весь сборник будет верстаться в LaTeX.

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

> Вы меня не поняли. Приведу простой пример. Скажем, пользователь
> переключил язык с русского на немецкий (а если это сделать,
> то можно даже вводить умляуты, и они будут адекватно
> отображаться). Спрашивается, нужно ли здесь вставлять
> \selectlanguage{german}, или заключать последующий текст в
> аргумент \foreignlanguage{german}{...}? Если там будет одно-два
> слова, то, очевидно, второе, а если целый абзац, то первое. Но
> откуда же программе знать, чтО будет дальше, если текст только
> еще вводится? 

А зачем ей знать, что будет _дальше_? Достаточно держать в памяти
буфер с абзац размером и форматировать его по завершении. С т.з.
программирования совершенно типовое решение. Кстати, поскольку
для LaTeX базовой единицей форматирования является абзац (по
словам --- это уже низкий уровень, как ассемблер в
программировании), без этого всё равно не обойтись.


> По тому же алгоритму можно было бы делать выбор между командами
> форматирования типа \textbf{...} и декларациями типа \textbf
> (хотя в действительности вот этой разницы LyX не понимает). В
> общем, стоит задача *упростить* разметку, сделав ее
> однозначной. А Вы, наоборот, предлагаете всё усложнить путем
> введения каких-то специфических команд, подключаемых через
> \include.

Да. Усложнить. Понятно, что программа станет сложнее. Зато
использовать её будет проще и удобнее. Ничего кардинально нового
для этого добавлять не пришлось бы, ведь модули импорта-экспорта
LaTeX уже есть, пусть и не идеальные, они делают практически то
же самое, только в пакетном режиме.

> Да и почему Вам непременно надо, чтобы файл мог обрабатываться
> непосредственно?

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

> Я бы не противопоставлял одно другому. Да, без OOo прожить
> практически нереально. Но есть случаи, когда LyX удобнее.

Я не противопоставляю. Я просто говорю о том, что в последнее
время таких случаев не вижу. Мож, не попадаются :-)

> Для себя -- да, конечно. А еще можно поставить gvim или emacs
> -- с ними под винду работать так приятно, что потом на linux
> возвращаться не захочется :-) Но не обязаны же все хорошие
> юниксовые программы иметь виндовые версии.

Никто никому ничего не обязан. Я ж просто объясняю, почему
_у_меня_ именно такие предпочтения. Не более того. Чисто
субъективно. Просто лично для меня LyX в своё время стал таким
своеобразным <<мостом в LaTeX>>: начав с него, я быстро втянулся,
разобрался с LaTeX'ом до того уровня, когда уже можно было что-то
делать, после чего обнаружил, что в моём наборе потребностей
потребность собственно в LyX пропала. Остался ОО для мелочей и
LaTeX для того, что ими не является. Только и всего.


-----------------------------------------------
DM: dead underscore m at list point ru

Re[2]: [Comm] LyX

[Sergey A. Kolesnitchenko]

AK> On Tuesday 09 September 2003 00:28, DM wrote:
>> Hello, Alexej!
>>
>> Вот сейчас поставил LyX-qt и проверил. lyx-qt-1.3.1-alt2

AK> Текущая версия 1.3.2.

>> Результаты:
>>
>> 1. Меню: <<Помощь/Введение>>. Выводится текст явно в koi-8 (у меня
>> 1251).
>>
>> 2. Открываю свой старый текст в lyx. Текст в 1251, поле
>> inputencoding в документе заполнено как auto. Текст
>> воспринимается в koi-8. Руками меняю имя кодировки в файле на
>> cp1251 --- никакого эффекта. В то же время новый файл создаётся

AK> Да без толку ее менять. Я же говорю, что данное поле влияет
AK> только на запись опций пакета inputenc, больше ни на что.

>> LyX с нормальными настройками. Видимо, глюк из-за совокупного
>> влияния разных версий LyX и настроек. 

AK> В совокупное влияние различных версий я не очень верю.
AK> Пользовательский файл preferences всего один, и он 
AK> перезаписывается после каждого захода в окно настроек.

>> Прямо перекодировал файл в
>> koi8, после этого он всё-таки открылся правильно. Но вот
>> почему-то подписи на рисунках (технические, которые выводит LyX
>> для указания интервалов) оказались явно не в той кодировке
>> (только при просмотре в LyX, в PS-выводе всё нормально). Кнопка
>> <<Оглавление>> имеет надпись в koi8, само оглавление в окне
>> выводится в той же самой koi8 (хотя в PS, опять-таки, всё
>> правильно). Кнопки <<Сноска>>, разбросанные по тексту, также
>> имеют надписи в koi8.

AK> Все эти фокусы оттого, что qt стремится вывести текст в локальной
AK> кодировке, а LyX настроен на koi8. Потому что Вы, судя по всему,
AK> файл languages так и не поправили. Вот и поправьте. Строка,
AK> относящаяся к русскому, должна принять следующий вид:

AK> russian     russian     "Russian"       false  cp1251     ru     ""

AK> Единственно, русская справка так и будет открываться кракозябрами,
AK> если не перекодировать ее в 1251. Тут уж ничего не поделаешь: 
AK> если мы настроили LyX на cp1251, то только ее он и будет 
AK> использовать для русского. Всё остальное (надписи "сноска" уж
AK> во всяком случае) должно стать читаемым.

>>
>> 3. Создаю новый файл, ввожу в него русский текст. Явно указываю
>> кодировку 1251. Экспортирую его в LaTeX. Результат: в файле явно
>> прописана строка
>>
>> \usepackage[cp125настрое1]{inputenc}
>>
>> но при этом текст почему-то экспортнулся в кодировке koi8-r.

AK> Вот по этому самому, что в файле languages прописана koi8.

>> (Кстати, в предыдущем письме я, видимо, ошибся. Память иногда
>> подводит :-) Ошибка при экспорте состояла именно в том, что
>> _текст_ экспортировался в koi-8, независимо от фактической и
>> прописанной в настройках кодировки).

AK> Ага.

>> > Это, конечно, дело вкуса. Я приведу лишь одно соображение:
>> > возможна ведь ситуация, когда хочешь
>> > сочинить документ, особенно не напрягаясь, но при этом
>> > допускаешь возможность дальнейшей его доработки в чистом LaTeX.
>>
>> А вот эта возможность мне представляется, скорее, теоретической.
>> Маленький текст, который требует специфического (а значит, почти
>> наверняка, визуального, а не структурного) форматирования и при
>> этом впоследствии будет куда-то вставлен? Что это может быть?
>> _Мне_ в голову не приходит. _У меня_ обычно либо достаточно
>> большие тексты в LaTeX, либо повседневные документы в ОО.

AK> Ну, вот сейчас я работаю над памяткой для авторов, которая
AK> вся пронумерована по пунктам и разбита на разделы
AK> (типично логическое форматирование).
AK> Потом, возможно, понадобится сделать из нее брошюру --
AK> тогда буду доделывать в latex. Но пока не надо.
AK> Или можно набирать небольшую статью, если известно, что
AK> весь сборник будет верстаться в LaTeX.

>> Пардон, но кто мешал определить все особенности форматирования в
>> виде команд LaTeX'а, собрать эти команды в стандартный набор и
>> подключать его к каждому документу обыкновенным \include ? Чтобы
>> сам файл оставался всегда правильным LaTeX-исходником и мог
>> обрабатываться непосредственно? Если бы это было так, то я

AK> Для себя -- да, конечно. А еще можно поставить gvim или emacs --
AK> с ними под винду работать так приятно, что потом на linux
AK> возвращаться не захочется :-) Но не обязаны же все хорошие
AK> юниксовые программы иметь виндовые версии.
Вот-вот. А уж про танцы с бубном, для того чтобы кодировку нормальную
прикрутить под виндами и ее менять динамически доки обычно умалчивают.
Кстати, если кто-нибудь знает как прикрутить русский язык под
emacs-win будте добры просвятите меня пожалуйта. Можно в личку.
С уважением,
Сергей

P.s. Я все же больше lyx-ом пользуюсь. Он удобнее для неольших
документов, по крайней мере для меня

Re: Re[2]: [Comm] LyX

[Alexej Kryukov]

> Вот-вот. А уж про танцы с бубном, для того чтобы кодировку нормальную
> прикрутить под виндами и ее менять динамически доки обычно

Хм... А что в данном контексте понимается под нормальной кодировкой?
Лично для меня "нормальная кодировка" под любой OS есть cp1251.
Или уж Юникод.

> умалчивают. Кстати, если кто-нибудь знает как прикрутить русский язык
> под emacs-win будте добры просвятите меня пожалуйта. Можно в личку. С
> уважением,

Какой русский язык? С win-кодировкой? Тут эта тема затрагивалась
некоторое время назад... Я тогда предлагал пакет своего
изготовления.

> Сергей

Re: [Comm] LyX

[Alexej Kryukov]

On Tuesday 09 September 2003 05:28, DM wrote:
> Hello, Alexej!
>
> Ну а что? Если два lyx-файла, в обоих прописано cp1251, в обоих
> текст в этой же кодировке, но один открывается нормально, а
> другой нет?

Это похоже на колдовство, а колдовства не бывает. Возможно,
в одном из файлов не так выставлен язык, или еще что-то.
А какая кодировка там прописана -- повторяю, совершенно
не важно.

> Риторический вопрос: а почему при установке не проверяется хотя
> бы системная локаль? Почему при наличии кучи поддерживаемых
> кодировок не сделано элементарное: настройки кодировки не
> вынесены в отдельные пакеты, из которых нужно поставить один?

Не очень представляю, как это сделать... Файл ведь написан
руками, сам не генерируется и в пользовательские настройки 
не переписывается. А привязать его к локали сложно потому,
что LyX ориентирован на многоязычные документы. То есть
если я помечу какой-то текст как греческий, то входная
кодировка будет динамически переключаться с cp1251 на
iso-8859-7. И точно так же какая-то русская
кодировка должна работать даже при некириллической локали.

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

> Почему, блин, нигде в печатной доке про это не написано?

Да похоже, что это моё ноу-хау.

> В обоих случаях я бы взял LaTeX с самого начала. В первом пункты
> по отдельности не имеют смысла --- они изначально проектируются
> как часть целого. Так целое и надо писать. 

Так целое же и написано. Для меня не составило бы большого
труда сразу взять LaTeX, но тогда пришлось бы вкладывать душу
в этот документ, а он того не стоит :-). Я говорил
о том, что, может быть, придется эти пункты *сверстать*
в форме брошюры -- вот тогда нужна усложненная преамбула,
и потом latex -> dvips -> psnup -> ps2pdf.

А еще, насколько я понимаю, LyX часто используют для
математики. Если человек еще недостаточно освоил LaTeX,
а конечный результат должен быть в нем, то это вполне
подходящий выбор.

> А зачем ей знать, что будет _дальше_? Достаточно держать в памяти
> буфер с абзац размером и форматировать его по завершении. С т.з.

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

> Да. Усложнить. Понятно, что программа станет сложнее. Зато
> использовать её будет проще и удобнее. Ничего кардинально нового
> для этого добавлять не пришлось бы, ведь модули импорта-экспорта
> LaTeX уже есть, пусть и не идеальные, они делают практически то
> же самое, только в пакетном режиме.

Не верю. Программе-то как раз очень просто вместо подлинного
LaTeX оперировать каким-то его сечением, а для части своих
внутренних функций определить новые команды. Видели Вы 
когда-нибудь LaTeX-код, генерируемый TeXmacs?
Вот там точно в преамбуле стоит \include. А в итоге получается
файл, который не откомпилировать без костылей.

Задача же в том, чтобы генерировать код, по возможности неотличимый
от рукотворного. А это сложно. Вообще Всегда, когда
человеко-ориентированный язык выбирают в качестве внутреннего формата
программы, возникает масса проблем. Вот в oodisc как-то обсуждали
вопрос о том, что OOo тратит куда больше времени на сохранение файла в
своем родном формате, чем во вражеский word. А откройте Вы этот родной
формат в текстовом редакторе -- сколько всякого мусора там найдете! И
именно потому, что его старались сделать *правильным* и одновременно
использовать в качестве внутреннего.

Так что, IMHO, решение, найденное создателями LyX -- весьма
изящное. Особенно если учесть, что они располагали куда меньшими
средствами, чем программисты Sun.

> Никто никому ничего не обязан. Я ж просто объясняю, почему
> _у_меня_ именно такие предпочтения. Не более того. Чисто
> субъективно. Просто лично для меня LyX в своё время стал таким
> своеобразным <<мостом в LaTeX>>: начав с него, я быстро втянулся,
> разобрался с LaTeX'ом до того уровня, когда уже можно было что-то
> делать, после чего обнаружил, что в моём наборе потребностей
> потребность собственно в LyX пропала. Остался ОО для мелочей и
> LaTeX для того, что ими не является. Только и всего.

Ну видите, значит LyX хорош уже тем, что может играть эту
роль моста. Собственно, я на него смотрю примерно так же, т. к.
и сам, конечно, основную работу делаю либо в чистом LaTeX,
либо в OOo. Но, значит, по крайней мере новичков нужно
к нему приучать, а то они зациклятся на OOo, и никуда дальше
не пойдут. Хотя, впрочем, знаю и обратное явление: люди
зацикливаются на MikTeX + WinEdt и не идут дальше на Linux.

Re: [Comm] LyX

[DM]

Hello, Alexej!

On Wed, 10 Sep 2003 00:54:08 +0400 You wrote:

> > Риторический вопрос: а почему при установке не проверяется
> > хотя бы системная локаль? Почему при наличии кучи
> > поддерживаемых кодировок не сделано элементарное: настройки
> > кодировки не вынесены в отдельные пакеты, из которых нужно
> > поставить один?
> 
> Не очень представляю, как это сделать... Файл ведь написан
> руками, сам не генерируется и в пользовательские настройки 
> не переписывается. А привязать его к локали сложно потому,
> что LyX ориентирован на многоязычные документы. То есть
> если я помечу какой-то текст как греческий, то входная
> кодировка будет динамически переключаться с cp1251 на
> iso-8859-7. И точно так же какая-то русская
> кодировка должна работать даже при некириллической локали.

LyX в ALTовских дистрибутивах ставится из rpm. У rpm есть пре- и
пост- скрипты. Почему не сделать там динамическую генерацию
_одной_строки_ при установке пакета? Это один вариант. Второй:
почему не сделать отдельные пакеты lyx-ru-1251, lyx-ru-koi8,
таким образом, чтобы их нельзя было установить одновременно и
обязательно требовался один из них? А в этих пакетах хранить
файлы настроек с нужной кодировкой? Почему, наконец, просто не
впихнуть файл ~/lyx/preferences в скелетоны домашних каталогов
пользователя, которые есть в разных кодировках? Не столь уж много
места он занимает. Конечно, если пользователь будет переключать
локали, LyX запутается. Но много ли таких пользователей?

> Кстати, это одно из удобств LyX (хотя и имеющее ограниченное
> применение): ведь в написанном руками документе смешивать
> несколько входных кодировок всё-таки как-то диковато.

Вот то-то и оно :-) 

> > А зачем ей знать, что будет _дальше_? Достаточно держать в
> > памяти буфер с абзац размером и форматировать его по
> > завершении. С т.з.
> 
> Ну а если текст вгоняется в середину абзаца, потом его делят
> на части и т. д.? Всё равно нужен промежуточный формат чтобы
> это фиксировать.

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

> Не верю. Программе-то как раз очень просто вместо подлинного
> LaTeX оперировать каким-то его сечением, а для части своих
> внутренних функций определить новые команды. 

Уточнение: для тех функций, которые не охватываются LaTeX. А их
очень немного :-)

И ещё момент: для представления того, что не охватывается целевым
форматом, в программировании давно есть метод, которым пользуются
разного рода IDE с кодогенерацией. Там дополнительные данные
просто записываются в комментарии. Кто мешает делать это здесь?

> Видели Вы 
> когда-нибудь LaTeX-код, генерируемый TeXmacs?

Не сподобился. У меня с emacs'ом сложные отношения. Не просекаю я
его красоты и привлекательности и стараюсь поэтому не
использовать. 

> Вот там точно в преамбуле стоит \include. А в итоге получается
> файл, который не откомпилировать без костылей.

Костылей в виде файла, который подлючён? Так что ж в этом
страшного? Если мне для компиляции программы кроме gcc
потребуется ещё и glibc, то это более чем естественно.

> Задача же в том, чтобы генерировать код, по возможности
> неотличимый от рукотворного. А это сложно.

Я бы сказал, что это невозможно. Но если действительно стоит
такая цель, то она явно не достигается. Экспортированные из LyX
файлы я, помнится, долгонько дорабатывал напильником. А сам
LyX-формат по читабельности, ИМХО, гораздо хуже не только
рукотворного, но и генерённого LyX'ом LaTeX-кода. Именно в силу
многочисленных переключений, длинных и неудобоваримых ключевых
слов... Например, слово в кавычках превращается в три(!) абзаца
--- открывающиеся кавычки, само слово, закрывающиеся кавычки. Чем
вызвана необходимость этого? Кому мешали "< "> << >>?

> Вообще Всегда, когда
> человеко-ориентированный язык выбирают в качестве внутреннего
> формата программы, возникает масса проблем. Вот в oodisc как-то
> обсуждали вопрос о том, что OOo тратит куда больше времени на
> сохранение файла в своем родном формате, чем во вражеский word.
> А откройте Вы этот родной формат в текстовом редакторе --
> сколько всякого мусора там найдете! И именно потому, что его
> старались сделать *правильным* и одновременно использовать в
> качестве внутреннего.

Немножко не так. Не "старались сделать правильным" а
"использовали общее решение, основанное на технологии,
значительно превосходящей своими возможностями их потребности, а
потому в данном случае неизбежно избыточной". XML и стандартный
упаковщик, то бишь. А лишней информации там нет. Зато: удобно
программировать, удобно поддерживать, возможно максимально полное
аварийное восстановление, а потери времени не столь уж велики.

> Но, значит, по крайней мере новичков нужно
> к нему приучать, а то они зациклятся на OOo, и никуда дальше
> не пойдут. Хотя, впрочем, знаю и обратное явление: люди
> зацикливаются на MikTeX + WinEdt и не идут дальше на Linux.

Может быть :-)

-----------------------------------------------
DM: dead underscore m at list point ru

Re: æÏÒÍÁÔ OO (ÂÙÌÏ - [Comm] LyX)

[Serhii Hlodin]

>>>>> "SL" == Sergey Lizogub writes:

 SL> 	Кстати, а за счет чего получается такая сжатость файлов в
 SL> формате OO? Для эксперимента взял чисто текстовый файл (6,6 мб),
 SL> открыл его в OOWriter-е, сохранил в как .sxw, получилось - 3,3 мб.

 zip.

-- 
With best regards,
                Serhii Hlodin

Re[2]: Формат OO (было- [Comm] LyX)

["DM"]

Hello, Sergey!

-----Original Message-----
From: Sergey Lizogub <linthong@mail.ru>
To: community@altlinux.ru
Date: Fri, 12 Sep 2003 22:49:02 +0400
Subject: Re: Формат OO (было-  [Comm] LyX)

> 	Кстати, а за счет чего получается такая сжатость файлов в
> формате OO? Для эксперимента взял чисто текстовый файл (6,6 мб),
> открыл его в OOWriter-е, сохранил в как .sxw, получилось - 3,3
> мб.

А попробуйте тот же файл пожать gzip'ом :-) 

Формат файла ОО --- это дерево каталогов, сжатое zip'ом. 
Сам текст хранится в XML-файле, вспомогательные файлы 
(картинки, например) лежат отдельно. Всё это пакуется настолько, насколько вообще позволяет упаковщик. Попробуйте сделать:

unzip <oo-file.sxw>

Там всё хорошо видно. 

---------------------------------------
DM: dead underscore m at list point ru
___________________________________________________

Re: Формат OO (было - [Comm] LyX)

[Maxim Britov]

[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]

> > > Вот в oodisc
> > > как-то обсуждали вопрос о том, что OOo тратит куда больше
> > > времени на сохранение файла в своем родном формате, чем во
> > > вражеский word. А откройте Вы этот родной формат в текстовом
> > > редакторе -- сколько всякого мусора там найдете! И именно
> > > потому, что его старались сделать *правильным* и одновременно
> > > использовать в качестве внутреннего.

> > Немножко не так. Не "старались сделать правильным" а
> > "использовали общее решение, основанное на технологии,
> > значительно превосходящей своими возможностями их потребности,
> > а потому в данном случае неизбежно избыточной". XML и
> > стандартный упаковщик, то бишь. А лишней информации там нет.

Не всегда так.
Попробуйте импортировать doc/xls и посмотрите на предмет asian например.
Многим нужно восточное форматирование? А в первых версиях с такими файлами
были проблемы при редактировании. А файлы из Excel зачастую получаются
под 4 мега, хотя содержат маленькую табличку.
Лишнего в формате нет, но запихивать лишнее в файл он ой как любит :(

> > Зато: удобно программировать, удобно поддерживать, возможно
> > максимально полное аварийное восстановление, а потери времени
> > не столь уж велики.

> 	Кстати, а за счет чего получается такая сжатость файлов в
> формате OO? Для эксперимента взял чисто текстовый файл (6,6 мб),
> открыл его в OOWriter-е, сохранил в как .sxw, получилось - 3,3


-- 
MaxBritov

GnuPG KeyID 0x4580A6D66F3DB1FB Keyserver hkp://keyserver.kjsl.com
Fingerprint: 4059 B5C5 8985 5A47 8F5A 8623 4580 A6D6 6F3D B1FB

[-- Attachment #2: Type: application/pgp-signature, Size: 485 bytes --]

Re: Формат OO (было - [Comm] LyX)

[DM]

Hello, Maxim!

On Fri, 12 Sep 2003 11:30:15 +0300 You wrote:

> > > избыточной". XML и стандартный упаковщик, то бишь. А лишней
> > > информации там нет.
> 
> Не всегда так.
> Попробуйте импортировать doc/xls и посмотрите на предмет asian
> например. Многим нужно восточное форматирование? А в первых
> версиях с такими файлами были проблемы при редактировании. А
> файлы из Excel зачастую получаются под 4 мега, хотя содержат
> маленькую табличку. Лишнего в формате нет, но запихивать лишнее
> в файл он ой как любит :(

Но это уже претензия скорее не к ОО, а к мелкомягкому офису.
Потому что мусор появляется при импорте как раз потому, что он
есть в исходных файлах :-) А то, что удалять явно лишнее ОО не
умеет, так и хрен-то с ним. Пусть лучше всё грузит, чем что-то
потеряет.

-----------------------------------------------
DM: dead underscore m at list point ru

Re: Формат OO (было - [Comm] LyX)

[Sergey Lizogub]

Wed, 10 Sep 2003 23:39:29 +0400
DM <dead_m@list.ru> Вы писали:


> > Вот в oodisc
> > как-то обсуждали вопрос о том, что OOo тратит куда больше
> > времени на сохранение файла в своем родном формате, чем во
> > вражеский word. А откройте Вы этот родной формат в текстовом
> > редакторе -- сколько всякого мусора там найдете! И именно
> > потому, что его старались сделать *правильным* и одновременно
> > использовать в качестве внутреннего.
> 
> Немножко не так. Не "старались сделать правильным" а
> "использовали общее решение, основанное на технологии,
> значительно превосходящей своими возможностями их потребности,
> а потому в данном случае неизбежно избыточной". XML и
> стандартный упаковщик, то бишь. А лишней информации там нет.
> Зато: удобно программировать, удобно поддерживать, возможно
> максимально полное аварийное восстановление, а потери времени
> не столь уж велики.
> 

	Кстати, а за счет чего получается такая сжатость файлов в
формате OO? Для эксперимента взял чисто текстовый файл (6,6 мб),
открыл его в OOWriter-е, сохранил в как .sxw, получилось - 3,3
мб.
	С уважением,
	Сергей Лизогуб

Re: Формат OO (было - [Comm] LyX)

[Alexej Kryukov]

On Friday 12 September 2003 22:21, DM wrote:
> Hello, Maxim!
>
> Но это уже претензия скорее не к ОО, а к мелкомягкому офису.
> Потому что мусор появляется при импорте как раз потому, что он
> есть в исходных файлах :-) А то, что удалять явно лишнее ОО не
> умеет, так и хрен-то с ним. Пусть лучше всё грузит, чем что-то
> потеряет.

Не-а. Мелкомягкий офис просто-напросто *не различает* восточное и
западное форматирование. Сама идея иметь отдельные параметры
форматирования для западного и азиатского текста (я не знаток
восточных языков, поэтому не знаю, насколько это осмысленно)
есть отличительная черта OOo. Вот поэтому при импорте файлов
Word ΟΟο перестраховывается и присваивает обоим типам разметки
одни и те же значения. Потом западное форматирование мы можем 
править, а азиатское так и остается в sxw на веки вечные.

Re: [Comm] LyX

[Alexej Kryukov]

On Wednesday 10 September 2003 23:39, DM wrote:
> Hello, Alexej!
>
> LyX в ALTовских дистрибутивах ставится из rpm. У rpm есть пре- и
> пост- скрипты. Почему не сделать там динамическую генерацию
> _одной_строки_ при установке пакета? Это один вариант. Второй:
> почему не сделать отдельные пакеты lyx-ru-1251, lyx-ru-koi8,
> таким образом, чтобы их нельзя было установить одновременно и
> обязательно требовался один из них? А в этих пакетах хранить
> файлы настроек с нужной кодировкой? Почему, наконец, просто не
> впихнуть файл ~/lyx/preferences в скелетоны домашних каталогов
> пользователя, которые есть в разных кодировках? Не столь уж много
> места он занимает. Конечно, если пользователь будет переключать
> локали, LyX запутается. Но много ли таких пользователей?

Не столько preferences, сколько ~/.lyx/languages. Вероятно, так можно
сделать, но это, как я понимаю, уже вопрос к Виталию Липатову.
И это, конечно, потребует включения именно сборки с qt в 
базовый дистрибутив -- на xforms правка файла languages мало что
даст.

> > Не верю. Программе-то как раз очень просто вместо подлинного
> > LaTeX оперировать каким-то его сечением, а для части своих
> > внутренних функций определить новые команды.
>
> Уточнение: для тех функций, которые не охватываются LaTeX. А их
> очень немного :-)

То-то и оно, что их немного. А может возникнуть искушение
определить новые команды просто из-за неумения пользоваться
стандартными пакетами (пример чему как раз TeXmacs, см. ниже). Как
только мы примем курс на создание подключаемого файла, от
такого искушения очень трудно будет удержаться :-)

> И ещё момент: для представления того, что не охватывается целевым
> форматом, в программировании давно есть метод, которым пользуются
> разного рода IDE с кодогенерацией. Там дополнительные данные
> просто записываются в комментарии. Кто мешает делать это здесь?

Не понял. Причем здесь это? Ведь документ всё равно будет 
прогоняться через latex. Специальные комментарии могли бы служить
разве что для управления визуальным отображением документа в 
редакторе.

> > Видели Вы
> > когда-нибудь LaTeX-код, генерируемый TeXmacs?
>
> Не сподобился. У меня с emacs'ом сложные отношения. Не просекаю я
> его красоты и привлекательности и стараюсь поэтому не
> использовать.

Не-е-ет. TeXmacs -- это совершенно особый текстовый процессор, к emacs
отношения не имеющий. Родной формат у него основан на SGML, но есть
возможность экспорта в LaTeX, причем в преамбуле сгенерированных
таким образом файлов загружается специальный пакет TeXmacs.sty.
Вот о нем-то и речь. Там, например, определяется команда
\SelectRussian, которая содержит определения вида

  \defА{\CYRA}\defа{\cyra}%
  \defБ{\CYRB}\defб{\cyrb}%

и т. д. (Все 8-битные символы предварительно сделаны активными --
не правда ли, офигительный способ их преобразования в кириллические
текстовые команды?) Дальше идут определения для стандартных строк:

  \renewcommand{\ProofText}{Доказательство}%
  \renewcommand{\AxiomText}{Аксиома}%

и т. д. Аналогичные команды для других языков -- и всё это, как
видите, исключительно от неумения пользоваться Бабелем и его
командами. Вот это я и называю костылями.

> Костылей в виде файла, который подлючён? Так что ж в этом
> страшного? Если мне для компиляции программы кроме gcc
> потребуется ещё и glibc, то это более чем естественно.

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

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

Это невозможно лишь потому, что у всякого свое представление
о правильности кода. Привести же документ к некоему усредненно-
"правильному" виду вполне осуществимо.

> LyX-формат по читабельности, ИМХО, гораздо хуже не только
> рукотворного, но и генерённого LyX'ом LaTeX-кода. Именно в силу
> многочисленных переключений, длинных и неудобоваримых ключевых
> слов... Например, слово в кавычках превращается в три(!) абзаца

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

> --- открывающиеся кавычки, само слово, закрывающиеся кавычки. Чем
> вызвана необходимость этого? Кому мешали "< "> << >>?

Необходимость вызвана тем, что лигатуры не универсальны, а бабелевские
shorthands введены не от хорошей жизни. Тем, что стиль кавычек может
различаться в зависимости от языка, и потому удобно иметь универсальную
команду, настраиваемую на все случаи жизни. И, наконец, тем, что
символы <> всё равно пришлось бы обрамлять довольно сложными
конструкциями во избежание их интерпретации как \textless{}
\textgreater{}.

> Немножко не так. Не "старались сделать правильным" а
> "использовали общее решение, основанное на технологии,
> значительно превосходящей своими возможностями их потребности, а
> потому в данном случае неизбежно избыточной". XML и стандартный
> упаковщик, то бишь. А лишней информации там нет. Зато: удобно

Ну, если нижеследующий фрагмент не содержит лишней информации,
то я готов съесть свою шляпу :-)

<text:span text:style-name="T4"> П</text:span><text:span
text:style-name="T4">о</text:span><text:span
text:style-name="T4">зд</text:span><text:span
text:style-name="T4">н</text:span><text:span
text:style-name="T4">ее</text:span><text:span
text:style-name="T9">,</text:span><text:span text:style-name="T4">
оз</text:span><text:span text:style-name="T4">н</text:span><text:span
text:style-name="T4">ак</text:span><text:span
text:style-name="T4">о</text:span><text:span
text:style-name="T4">мив</text:span><text:span
text:style-name="T4">ш</text:span><text:span
text:style-name="T4">ись</text:span>

Это результат работы перекодировщика, который менял символы Latin1
на кириллицу и одновременно применял к ним форматирование (Times New
Roman вместо Times New Roman Cyr). Сдается мне, что при этом OOo
ничего ни в каком буфере не держал :-) Но дело даже не в этом, а
в том, что это именно расплата за xml с его открывающими и 
закрывающими тегами. Подобный эффект был бы невозможен в любом формате,
где для переключения форматирования используются команды-декларации.

> программировать, удобно поддерживать, возможно максимально полное
> аварийное восстановление, а потери времени не столь уж велики.

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

Re: [Comm] LyX

[Alexander Bokovoy]

On Sat, Sep 13, 2003 at 10:14:49PM +0400, Alexej Kryukov wrote:
> Не-е-ет. TeXmacs -- это совершенно особый текстовый процессор, к emacs
> отношения не имеющий. Родной формат у него основан на SGML, но есть
> возможность экспорта в LaTeX, причем в преамбуле сгенерированных
> таким образом файлов загружается специальный пакет TeXmacs.sty.
> Вот о нем-то и речь. Там, например, определяется команда
> \SelectRussian, которая содержит определения вида
> 
>   \defА{\CYRA}\defа{\cyra}%
>   \defБ{\CYRB}\defб{\cyrb}%
> 
> и т. д. (Все 8-битные символы предварительно сделаны активными --
> не правда ли, офигительный способ их преобразования в кириллические
> текстовые команды?) Дальше идут определения для стандартных строк:
Что забавно, они уже перед этим активны при использовании inputenc/fontenc
-- а поскольку TeXmacs.sty использует макросы из T2 (\CYRA, etc.), то
двойное переопределение активных символов поражает воображение. :)

> и т. д. Аналогичные команды для других языков -- и всё это, как
> видите, исключительно от неумения пользоваться Бабелем и его
> командами. Вот это я и называю костылями.
Полностью согласен.


-- 
/ Alexander Bokovoy
"Mr. Watson, come here, I want you."   -- Alexander Graham Bell

Re: [Comm] LyX

[Vitaly Lipatov]

On Суббота 06 Сентябрь 2003 13:04, Alexej Kryukov wrote:
> Хм... Сколько я знаю, в версии 3.* проблема только одна, и
> править ее никто даже и не пытался. Однако она возникает,
В ALTLinux мантейнер проверяет LyX в локали ru_RU.KOI8-R, и 
потому не замечает проблем (или не умеет заметить) в других 
локалях.

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [Comm] LyX

[Vitaly Lipatov]

On Среда 10 Сентябрь 2003 23:39, DM wrote:
> LyX в ALTовских дистрибутивах ставится из rpm. У rpm есть пре-
> и пост- скрипты. Почему не сделать там динамическую генерацию
> _одной_строки_ при установке пакета? Это один вариант. Второй:
Там делается "динамическая генерация". Если у вас есть конкретные 
предложения или реализация - добро пожаловать, это облегчит мою 
участь. Я стараюсь сделать удобнее, но, как мне кажется, чтобы 
сделать по-нормальному, нужно много исправлять в LyX.
> почему не сделать отдельные пакеты lyx-ru-1251, lyx-ru-koi8,
В этом нет необходимости. А при установке определяется системная 
локаль и производятся настройки. Я проверю, насколько они 
достаточны.

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [Comm] LyX

[Alexej Kryukov]

On Sunday 14 September 2003 13:31, Vitaly Lipatov wrote:
> On Среда 10 Сентябрь 2003 23:39, DM wrote:
> > LyX в ALTовских дистрибутивах ставится из rpm. У rpm есть пре-
> > и пост- скрипты. Почему не сделать там динамическую генерацию
> > _одной_строки_ при установке пакета? Это один вариант. Второй:
>
> Там делается "динамическая генерация". Если у вас есть конкретные
> предложения или реализация - добро пожаловать, это облегчит мою
> участь. Я стараюсь сделать удобнее, но, как мне кажется, чтобы
> сделать по-нормальному, нужно много исправлять в LyX.

"Конкретное предложение" было уже высказано в этом треде.
Нужно, чтобы файл lyx/languages автоматически копировался
в ~/.lyx и чтобы в нем прописывалась русская кодировка
в зависимости от локали. (Правда, не знаю, как поступать,
если локаль -- ru_RU.UTF-8.) Потому что *фактическая*,
а не титульная кодировка для русского текста определяется 
только установками этого файла.

И, конечно, хорошо бы заменить в следующей версии 
базового дистрибутива сборку LyX с xforms на qt.

Re: [Comm] LyX

[DM]

Hello, Alexej!

On Sat, 13 Sep 2003 22:14:49 +0400 You wrote:

> > Почему, наконец, просто не впихнуть файл ~/lyx/preferences в
> > скелетоны домашних каталогов пользователя, которые есть в
> > разных кодировках? Не столь уж много места он занимает.
> > Конечно, если пользователь будет переключать локали, LyX
> > запутается. Но много ли таких пользователей?
> 
> Не столько preferences, сколько ~/.lyx/languages

Да, именно это и имелось в виду.

> > И ещё момент: для представления того, что не охватывается
> > целевым форматом, в программировании давно есть метод,
> > которым пользуются разного рода IDE с кодогенерацией. Там
> > дополнительные данные просто записываются в комментарии. Кто
> > мешает делать это здесь?
> 
> Не понял. Причем здесь это? Ведь документ всё равно будет 
> прогоняться через latex. Специальные комментарии могли бы
> служить разве что для управления визуальным отображением
> документа в редакторе.

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

> Не-е-ет. TeXmacs -- это совершенно особый текстовый процессор,

Я ж говорю, не сподобился. Даже не смотрел, ответ объясняется
исключительно названием, которое автоматически перевелось у меня
как <<Emacs for TeX>>.

> определяется команда\SelectRussian, которая содержит
> определения вида
> 
>   \defА{\CYRA}\defа{\cyra}%
>   \defБ{\CYRB}\defб{\cyrb}%
> 
> и т. д. (Все 8-битные символы предварительно сделаны активными
> -- не правда ли, офигительный способ их преобразования в
> кириллические текстовые команды?) Дальше идут определения для
> стандартных строк:
> 
>   \renewcommand{\ProofText}{Доказательство}%
>   \renewcommand{\AxiomText}{Аксиома}%
> 
> и т. д. Аналогичные команды для других языков -- и всё это, как
> видите, исключительно от неумения пользоваться Бабелем и его
> командами. Вот это я и называю костылями.

Так ведь приведённые примеры говорят не о ценности самого подхода
к вопросу, а о качестве реализации этого подхода.

> > Костылей в виде файла, который подлючён? Так что ж в этом
> > страшного? Если мне для компиляции программы кроме gcc
> > потребуется ещё и glibc, то это более чем естественно.
> 
> Даже если исключить клинические случаи, подобные
> вышеописанныму, зависимость кода от подключаемых файлов (помимо
> явно заданных пользователем) -- это, IMHO, всегда плохо.
> Ибо если мы будем дорабатывать сгенерированный файл вручную,
> то загрузка "лишних" пакетов, естественно, вызовет наше
> раздражение, и придется тратить время на чистку кода на предмет
> избавления его от ненужных нам зависимостей.

С тем, что такой пакет будет <<лишним>>, я не согласен. 

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

Именно. 


>  Привести же документ к некоему усредненно-
> "правильному" виду вполне осуществимо.

Ну разве что... 

> Я не знаю, почему было так важно обеспечить вставку возврата
> строки после каждой команды, но зато убежден, что это уж точно
> лучше, чем форматирование всего документа в одну длинную строку
> (как в OOo).

А это опять-таки не ОО, это XML. Хотя, в принципе, ничто не
мешает произвести автоформатирование этого XML, причём без потери
его читабельности для ОО. 

> > --- открывающиеся кавычки, само слово, закрывающиеся кавычки.
> > Чем вызвана необходимость этого? Кому мешали "< "> << >>?
> 
> Необходимость вызвана тем, что лигатуры не универсальны, а
> бабелевские shorthands введены не от хорошей жизни. 

Но они есть. Механизм имеется и работает. Вполне подходящим
образом. Зачем придумывать свой, который не лучше? 

> Тем, что
> стиль кавычек может различаться в зависимости от языка, и
> потому удобно иметь универсальную команду, настраиваемую на все
> случаи жизни. 

Кому удобно? Редактору? Да. Пользователю? Не уверен. 

> И, наконец, тем, что символы <> всё равно
> пришлось бы обрамлять довольно сложными конструкциями во
> избежание их интерпретации как \textless{}\textgreater{}.

А вот этого я не понял. Зачем? 

> > Немножко не так. Не "старались сделать правильным" а
> > "использовали общее решение, основанное на технологии,
> > значительно превосходящей своими возможностями их
> > потребности, а потому в данном случае неизбежно избыточной".
> > XML и стандартный упаковщик, то бишь. А лишней информации там
> > нет. Зато: удобно
> 
> Ну, если нижеследующий фрагмент не содержит лишней информации,
> то я готов съесть свою шляпу :-)
> 
> <text:span text:style-name="T4"> П</text:span><text:span
> text:style-name="T4">о</text:span><text:span
> text:style-name="T4">зд</text:span><text:span
> text:style-name="T4">н</text:span><text:span
> text:style-name="T4">ее</text:span><text:span
> text:style-name="T9">,</text:span><text:span
> text:style-name="T4"> оз</text:span><text:span
> text:style-name="T4">н</text:span><text:span
> text:style-name="T4">ак</text:span><text:span
> text:style-name="T4">о</text:span><text:span
> text:style-name="T4">мив</text:span><text:span
> text:style-name="T4">ш</text:span><text:span
> text:style-name="T4">ись</text:span>
> 
> Это результат работы перекодировщика, который менял символы
> Latin1 на кириллицу и одновременно применял к ним
> форматирование (Times New Roman вместо Times New Roman Cyr).
> Сдается мне, что при этом OOo ничего ни в каком буфере не
> держал :-) 

И в этом его ошибка :-)

> Но дело даже не в этом, а в том, что это именно
> расплата за xml с его открывающими и закрывающими тегами.
> Подобный эффект был бы невозможен в любом формате, где для
> переключения форматирования используются команды-декларации.

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

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

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

-----------------------------------------------
DM: dead underscore m at list point ru

Re: Формат OO (было - [Comm] LyX)

[DM]

Hello, Alexej!

On Sat, 13 Sep 2003 20:08:33 +0400 You wrote:

> On Friday 12 September 2003 22:21, DM wrote:
> > Hello, Maxim!
> >
> > Но это уже претензия скорее не к ОО, а к мелкомягкому офису.
> > Потому что мусор появляется при импорте как раз потому, что
> > он есть в исходных файлах :-) А то, что удалять явно лишнее
> > ОО не умеет, так и хрен-то с ним. Пусть лучше всё грузит, чем
> > что-то потеряет.
> 
> Не-а. Мелкомягкий офис просто-напросто *не различает* восточное
> и западное форматирование. Сама идея иметь отдельные параметры
> форматирования для западного и азиатского текста (я не знаток
> восточных языков, поэтому не знаю, насколько это осмысленно)
> есть отличительная черта OOo. Вот поэтому при импорте файлов
> Word ______ перестраховывается и присваивает обоим типам
> разметки одни и те же значения. Потом западное форматирование
> мы можем править, а азиатское так и остается в sxw на веки
> вечные.

Ну и? Всё правильно. Если я не знаю точно, нужно ли восточное
форматирование, я его храню. Знал бы, выкинул бы ненужное. В
вордовском файле про это написано? Нет. И что делать?
Пользователя спрашивать? А если он при слове <<восточное>> решит,
что речь про русский? И вообще, работа с импортированными
документами --- это большая и грустная песня, причём не только
для ОО.

-----------------------------------------------
DM: dead underscore m at list point ru

Re: [Comm] LyX

[Alexej Kryukov]

On Monday 15 September 2003 01:40, DM wrote:
> Hello, Alexej!
>
> Я немножко не про это. А про то, что если в LaTeX чего-то не
> хватает для полноты счастья конкретного редактора, то редактору
> никто не мешает хранить это что-то в комментариях, не создавая
> при этом необходимости в личном формате.

А я именно про это. Как потом добиться появления этого "нечто" 
в печатном документе, если он (печатный документ) всё равно
формируется путем прогона через LaTeX?

> Так ведь приведённые примеры говорят не о ценности самого подхода
> к вопросу, а о качестве реализации этого подхода.

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

> С тем, что такой пакет будет <<лишним>>, я не согласен.

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

> > Я не знаю, почему было так важно обеспечить вставку возврата
> > строки после каждой команды, но зато убежден, что это уж точно
> > лучше, чем форматирование всего документа в одну длинную строку
> > (как в OOo).
>
> А это опять-таки не ОО, это XML. Хотя, в принципе, ничто не
> мешает произвести автоформатирование этого XML, причём без потери
> его читабельности для ОО.

Да, отчасти это еще одна расплата за XML (некоторые процессоры
считают, что пробельные символы между тегами -- это не есть
хорошо). Но в результате-то content.xml получается нечитаемым
не только для человека, но и, например, для vim, который
жутко тормозит на длинных строках. А процессор для автоформатирования
придумать, конечно, можно, только это уже не будет иметь отношения
к замыслу разработчиков OOo.

> > > --- открывающиеся кавычки, само слово, закрывающиеся кавычки.
> > > Чем вызвана необходимость этого? Кому мешали "< "> << >>?
> >
> > Необходимость вызвана тем, что лигатуры не универсальны, а
> > бабелевские shorthands введены не от хорошей жизни.
>
> Но они есть. Механизм имеется и работает. Вполне подходящим
> образом. Зачем придумывать свой, который не лучше?

Лучше, ибо универсальнее.

> > Тем, что
> > стиль кавычек может различаться в зависимости от языка, и
> > потому удобно иметь универсальную команду, настраиваемую на все
> > случаи жизни.
>
> Кому удобно? Редактору? Да. Пользователю? Не уверен.

Видите ли, во всех случаях, когда некая команда имеет две
записи (сокращенную и полную), сокращенная запись предназначена
для ручной вставки, а полная -- для автоматической генерации.
Так вот, "< "> -- это всего лишь сокращенная запись для 
\flqq{}\frqq{}. Которые LyX и вставляет. А мог бы писать
вообще \guillemotleft{}\guillemotright{}.

> > И, наконец, тем, что символы <> всё равно
> > пришлось бы обрамлять довольно сложными конструкциями во
> > избежание их интерпретации как \textless{}\textgreater{}.
>
> А вот этого я не понял. Зачем?

Затем, что, когда мы печатаем в документе просто <>, LyX
их интерпретирует как \textless{}\textgreater{}. И абсолютно
правильно делает, потому что не во всех шрифтах <> фактически
соответствуют угловым скобкам, и уж тем более не во всех лигатуры
<< >> производят французские кавычки. А чтобы интерпретировать
<<>> буквально, пришлось бы оформлять их как вставку LaTeX-кода.

> То есть, опять-таки, вопрос в выборе: Пингвин против Терминатора :-)
> Удобство человека против удобства программирования редактора.
> Я за человека.

Удобство человека в том, чтобы редактор не тормозил на пустячных
операциях. И какая вообще человеку разница, в каком виде
редактор хранит свои данные, если экспорт в какой-л. human
readable формат не составляет проблемы? Что же до удобства
программирования, то в нём -- залог способности небольшой 
группы программистов в приемлемые сроки отладить небольшую
по объему программу и сделать ее пригодной для использования.
Опять-таки, если уж создатели OOo до сих пор не смогли
добиться безукоризненной работы с xml, то каково пришлось
бы разработчикам LyX при том, что ресурсы их ограничены,
а LaTeX много сложнее в интерпретации, чем xml?

> Чрезвычайно небольшой, думается. Введут мой любимый буфер :-), и
> всё. Задачка сия давно решена в оптимизирующих компиляторах,
> только применить.

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

Re: Формат OO (было - [Comm] LyX)

[Alexej Kryukov]

On Monday 15 September 2003 01:49, DM wrote:
> Hello, Alexej!
>
> Ну и? Всё правильно. Если я не знаю точно, нужно ли восточное
> форматирование, я его храню. Знал бы, выкинул бы ненужное. В
> вордовском файле про это написано? Нет. И что делать?
> Пользователя спрашивать? А если он при слове <<восточное>> решит,
> что речь про русский? И вообще, работа с импортированными
> документами --- это большая и грустная песня, причём не только
> для ОО.

Да ведь масса есть способов это узнать. Во-первых, просто проверить 
текст на наличие CJK юникодов. Во-вторых, если у человека
*снят* флажок "Asian languages support", то на кой ему ляд,
спрашивается, эта самая азиатская разметка?

Re: Формат OO (было - [Comm] LyX)

[Maxim Britov]

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

> > > Но это уже претензия скорее не к ОО, а к мелкомягкому офису.
> > > Потому что мусор появляется при импорте как раз потому, что
> > > он есть в исходных файлах :-) А то, что удалять явно лишнее
> > > ОО не умеет, так и хрен-то с ним. Пусть лучше всё грузит, чем
> > > что-то потеряет.
> > 
> > Не-а. Мелкомягкий офис просто-напросто *не различает* восточное
> > и западное форматирование. Сама идея иметь отдельные параметры
> > форматирования для западного и азиатского текста (я не знаток
> > восточных языков, поэтому не знаю, насколько это осмысленно)
> > есть отличительная черта OOo. Вот поэтому при импорте файлов
> > Word ______ перестраховывается и присваивает обоим типам
> > разметки одни и те же значения. Потом западное форматирование
> > мы можем править, а азиатское так и остается в sxw на веки
> > вечные.
> 
> Ну и? Всё правильно. Если я не знаю точно, нужно ли восточное
> форматирование, я его храню. Знал бы, выкинул бы ненужное. В
> вордовском файле про это написано? Нет. И что делать?
> Пользователя спрашивать? А если он при слове <<восточное>> решит,
> что речь про русский? И вообще, работа с импортированными
> документами --- это большая и грустная песня, причём не только
> для ОО.

Asian это азиатское, а не восточное.
В большинстве случаев оно отключено. И если оно отключено,
то не должно и появляться, а работа с ним проблема пользователя.
Работаешь с азией - включай и получай поддержку, а нет - не получай
ненужный мусор в файлах. Они это кажется как расширение приняли.
Вот issue не помню.

-- 
MaxBritov

GnuPG KeyID 0x4580A6D66F3DB1FB Keyserver hkp://keyserver.kjsl.com
Fingerprint: 4059 B5C5 8985 5A47 8F5A 8623 4580 A6D6 6F3D B1FB

[-- Attachment #2: Type: application/pgp-signature, Size: 485 bytes --]

Re: Формат OO (было - [Comm] LyX)

[DM]

Hello, Alexej!

On Mon, 15 Sep 2003 12:29:10 +0400 You wrote:

> Да ведь масса есть способов это узнать. Во-первых, просто
> проверить текст на наличие CJK юникодов. Во-вторых, если у
> человека*снят* флажок "Asian languages support", то на кой ему
> ляд, спрашивается, эта самая азиатская разметка?

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

Обсуждение LyX у нас как-то плавно перетекло в спор на тему <<чей 
внутренний формат лучше --- ОО или LyX>>

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

В общем, этот спор мне представляется бессмысленным, так что я
его прекращаю. :-)

-----------------------------------------------
DM: dead underscore m at list point ru

Re: [Comm] LyX

[DM]

Hello, Alexej!

On Mon, 15 Sep 2003 12:25:12 +0400 You wrote:

> > Я немножко не про это. А про то, что если в LaTeX чего-то не
> > хватает для полноты счастья конкретного редактора, то
> > редактору никто не мешает хранить это что-то в комментариях,
> > не создавая при этом необходимости в личном формате.
> 
> А я именно про это. Как потом добиться появления этого "нечто" 
> в печатном документе, если он (печатный документ) всё равно
> формируется путем прогона через LaTeX?

Вставкой кода в чистом LaTeXе, вестимо, как же ещё. Просто можно
ориентироваться на собственные метки, чтобы не заморачиваться с
полнометражным разбором LaTeX'а на лету

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

Ну, это уже напоминает высказывание
программиста-структурника-фанатика: <<Я буду писать на Модуле-2,
в ней GOTO нет. А вот C никогда не воспользуюсь --- в нём GOTO
есть, и меня непременно потянет его где-нибудь использовать, а
оператор-то некошерный!>> (И это, кстати, при том, что в C даже
больше конструкций, позволяющих удобно обходиться без GOTO, чем в
Модуле) 

> > С тем, что такой пакет будет <<лишним>>, я не согласен.
> 
> Но ведь Вы же не будете его подключать, когда пишете
> файл изначально вручную. А на сгенерированных файлах,
> значит, навсегда останется родимое пятно в виде еще одного
> \include либо \usepackage?

Если я пишу файл изначально вручную, я пользуюсь средствами
LaTeX, а не командами редактора. Если в какой-то момент
(возможно, сразу) я начал использовать редактор, он добавит мне в
код этот самый \include или \usepackage, как только я
воспользуюсь первой нестандартной возможностью, реализованной в
его пакете команд. И с этого момента он, действительно, останется
с файлом навечно. Да.

> Удобство человека в том, чтобы редактор не тормозил на
> пустячных операциях. И какая вообще человеку разница, в каком
> виде редактор хранит свои данные, если экспорт в какой-л. human
> readable формат не составляет проблемы? Что же до удобства
> программирования, то в нём -- залог способности небольшой 
> группы программистов в приемлемые сроки отладить небольшую
> по объему программу и сделать ее пригодной для использования.
> Опять-таки, если уж создатели OOo до сих пор не смогли
> добиться безукоризненной работы с xml, то каково пришлось
> бы разработчикам LyX при том, что ресурсы их ограничены,
> а LaTeX много сложнее в интерпретации, чем xml?
> 
> > Чрезвычайно небольшой, думается. Введут мой любимый буфер
> > :-), и всё. Задачка сия давно решена в оптимизирующих
> > компиляторах, только применить.
> 
> Потом еще полгода будут вылавливать вызванные этим утечки
> памяти :-) А когда всё это отладят, мы получим дополнительные
> тормоза при работе, с которыми, конечно, придется смириться.

:-))

В общем, мы друг друга поняли и не согласились. На этом предлагаю
закруглиться.

-----------------------------------------------
DM: dead underscore m at list point ru

Re: [Comm] LyX

[Alexej Kryukov]

On Monday 15 September 2003 23:25, DM wrote:
> Hello, Alexej!
>
> В общем, мы друг друга поняли и не согласились. На этом предлагаю
> закруглиться.


Согласен. Хотя и жалко :-), т. к. дискуссия была содержательная.

Re: [Comm] LyX

[Andriy Dobrovol's'kii]

Alexej Kryukov wrote:
> 
> 
> Все эти фокусы оттого, что qt стремится вывести текст в локальной
> кодировке, а LyX настроен на koi8. Потому что Вы, судя по всему,
> файл languages так и не поправили. Вот и поправьте. Строка,
> относящаяся к русскому, должна принять следующий вид:
> 
> russian     russian	"Russian"	false  cp1251     ru	 ""
> 
> Единственно, русская справка так и будет открываться кракозябрами,
> если не перекодировать ее в 1251. Тут уж ничего не поделаешь: 
> если мы настроили LyX на cp1251, то только ее он и будет 
> использовать для русского. Всё остальное (надписи "сноска" уж
> во всяком случае) должно стать читаемым.
> 
> 
С украинским, Lyx по прежнему не рабочий в 1251. Не имеет значения, 
что прописать в файл languages. Ввод идет бпней.
Из коробки, там есть запись только для кои8. Может в ней он и 
рабочий. Вобщем, пришлось отправить его на свалку... Хоть и жаль 
курилку.
-- 
Rgrds,
Andriy
*********************************************************************
email: dobr at iop dot kiev dot ua            Kyiv, Ukraine
Phone: (380-44)   265-7824            Department of Gas Electronics
Fax:   (380-44)   265-2329             Institute of Physics of NASU
*********************************************************************

Re: [Comm] LyX

[Andriy Dobrovol's'kii]

Andriy Dobrovol's'kii wrote:
> Alexej Kryukov wrote:
> 
>>
>>
>> Все эти фокусы оттого, что qt стремится вывести текст в локальной
>> кодировке, а LyX настроен на koi8. Потому что Вы, судя по всему,
>> файл languages так и не поправили. Вот и поправьте. Строка,
>> относящаяся к русскому, должна принять следующий вид:
>>
>> russian     russian    "Russian"    false  cp1251     ru     ""
>>
>> Единственно, русская справка так и будет открываться кракозябрами,
>> если не перекодировать ее в 1251. Тут уж ничего не поделаешь: если мы 
>> настроили LyX на cp1251, то только ее он и будет использовать для 
>> русского. Всё остальное (надписи "сноска" уж
>> во всяком случае) должно стать читаемым.
>>
>>
> С украинским, Lyx по прежнему не рабочий в 1251. Не имеет значения, что 
> прописать в файл languages. Ввод идет бпней.
> Из коробки, там есть запись только для кои8. Может в ней он и рабочий. 
> Вобщем, пришлось отправить его на свалку... Хоть и жаль курилку.
Забираю слова назад. Qt вариант заработал. :) Для меня, Ликс 
вернулся. :))
Да, ещё забыл написать, что строку не обязательно менять. Можно 
просто дополнить оный файл указаной строчкой заменив ru на, скажем, 
ru_RU и изменить название, слово в кавычках. Появится выбор кодировки.

-- 
Rgrds,
Andriy
*********************************************************************
email: dobr at iop dot kiev dot ua            Kyiv, Ukraine
Phone: (380-44)   265-7824            Department of Gas Electronics
Fax:   (380-44)   265-2329             Institute of Physics of NASU
*********************************************************************