[Comm] LyX
DM
=?iso-8859-1?q?dead=5Fm_=CE=C1_list=2Eru?=
Вт Сен 9 05:28:46 MSD 2003
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
Подробная информация о списке рассылки community