Re: [Comm] LyX

[DM <dead_m@list.ru>]

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