Вышел LyX 1.5.0 RC1

> Но работа с таблицами в латехе к числу замечательно реализованных вещей явно не относится.

O'k я вашу точку зрения воспринял. Хотелось бы понять где с Вашей точки зрения с таблицами работать удобно?

Я пока к таким инструментам могу отнести только СУБД :), да и то только в том случае, если структара базы заложена разумно.

У вас таблицы размеров СУБД попадают в документы? Сурово их читать, наверное! :) Любой инструмент, где видишь таблицу и что с ней творится, удобнее того безобразия, что существует в латехе. Например, тот же excel&Co. СУБД не для документооборота, а для больших расчётов по таблицам, тех же статистических, существуют свои инструменты. Но эти таблицы в документы не вставляют.

> У вас таблицы размеров СУБД попадают в документы?

Очевидно нет - я делаю из них картинки :), а вот они уже попадают в документы. Кроме того в СУБД можно делать и небольшие выборки данных - не зачем читать всё подряд.

> СУБД не для документооборота, а для больших расчётов по таблицам, тех же статистических, существуют свои инструменты.

Да ну. Их создавали именно для упрощения документооборота, чтобы все данные сводить в одно место. Под формирование отчётов там много чего приспособлено - хотя бы то, что результат всегда таблица (имеются в виду реляционные СУБД).

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

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

А по поводу СУБД такое ощущение, что у Вас это ассоциируется с суперкомпьютерами. Нормальная реляционная СУБД типа PostgreSQL на каждом компьютере и в каждом телефоне не такая уж на сегодня и фантастика. IMHO, это просто дополнительная возможность.

> Например, тот же excel&Co.

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

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

Они наглядны, удобны, просты в управлении и даже умеют считать по формулам. Если считать ничего не нужно, то можно и в OO writer с таким же успехом таблицу быстро набросать. Большего для документооборота и не нужно.

>Кроме того в СУБД можно делать и небольшие выборки данных - не зачем читать всё подряд.

Это работа с данными и ничего общего не имеет с задачами составления и форматирования таблиц. Собственно, к латеху это вообще никакого отношения не имеет, ибо он с данными в таблицах вообще никак работать не умеет.

>Цель таблицы - что-то показать.

Цель таблицы - представить данные в систематизированном и поэтому легко читаемом виде. Работа с данными в виде таблиц - это совсем другая задача и для совсем других инструментов. Естественно, что инструменты для документооборота должны быть вменяемыми - требовать от человека учить запросы к базам данных для того, чтобы сляпать таблицу для документа - явный признак неизлечимого красноглазия :)

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

> Они наглядны, удобны, просты в управлении и даже умеют считать по формулам. Если считать ничего не нужно, то можно и в OO writer с таким же успехом таблицу быстро набросать. Большего для документооборота и не нужно.

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

>>Кроме того в СУБД можно делать и небольшие выборки данных - не зачем читать всё подряд.

> Это работа с данными и ничего общего не имеет с задачами составления и форматирования таблиц.

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

> Собственно, к латеху это вообще никакого отношения не имеет, ибо он с данными в таблицах вообще никак работать не умеет.

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

>> Цель таблицы - что-то показать.

> Цель таблицы - представить данные в систематизированном и поэтому легко читаемом виде. Работа с данными в виде таблиц - это совсем другая задача и для совсем других инструментов. Естественно, что инструменты для документооборота должны быть вменяемыми - требовать от человека учить запросы к базам данных для того, чтобы сляпать таблицу для документа - явный признак неизлечимого красноглазия :)

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

>Формирование таблицы для максимально хорошего восприятие требует времени.

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

>Ну, вообще-то, как мне казалось я уже упоминал, что вывод на SQL-запрос и есть таблица, причём вполне себе отформатированная.

Ага, только данные как-то должны туда попасть. Заводить SQL таблицу, заносить в неё данные и учить что такое SQL-запросы и с чем их едят, только для того, чтобы получить вывод в виде таблицы - это ядрёно. Зачем просто, когда можно сложно? :)

>Данные перед представлением необходимо подготовить, а не править во время оформления.

И так мне никто не объяснит, что же это за мистичная "подготовка" данных. Когда данные нужно сначала обработать, там прогнать миллион данных статистического опроса и получить график - это я понимаю. Этим, правда, занимаются люди, которые знают свои инструменты. А вот зачем вбивать данные из эксперимента по росту бактерий в базу данных, если их можно вбить в тот же excel/oo calc, тут же провести два нехитрых расчёта и сделать график, да всё это перетащить в ворд/oo writer? А если графика не надо, то и сразу в oo writer можно создать эту таблицу и вбить туда данные. Чем здесь оправдано существование лишних сущностей в виде базы данных? Зачем забивать дома гвозди кувалдой?

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

Ну вот и я о том же - я лучше буду над таблицей и докладом думать ,а не над сложностями форматирования таблиц в латехе, SQL-запросами и скриптовыми языками. Я лучше 2 поля маркирую, ткну "объединить ячейки" - а об остальном пусть компьютер думает, он железный, с него не убудет. А мне такой чушью голову забивать не хочется.

> Зачем забивать дома гвозди кувалдой?

Согласен, что то, что рост бактерий лучше записывать в бумадном журнале, а считать такие объёмы можно и в уме. А вот к чему-нибудь чуть более сложному необходимы специализированные кувалды, к категории которых exel-подобные инструменты увы не относятся - это скорее детские совочки.

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

Проблема в том, что "не думать" Вы так будете над _каждой_ встреченной таблицей. И каждый раз будет как в первый класс ручное оформление.

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

Интересно, а миллиард данных Вы понимаете? Миллион это как-то мелко.

Отлично понимаю. Только ничего общего с таблицами в документообороте это не имеет. Это вы понимаете, надеюсь?

>роблема в том, что "не думать" Вы так будете над _каждой_ встреченной таблицей. И каждый раз будет как в первый класс ручное оформление

В еxcel вписал нужную цифру в таблицу с готовыми формулами - и копируй. И без всяких баз данных. Вот и вся автоматизация.

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

К чему-то нужны, да только их в латехе в таблицы не записывают.

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

> К чему-то нужны, да только их в латехе в таблицы не записывают.

Ощущение такое, что имеет место некоторое недопонимание. Ну что Вы всё рвётесь смешать процессы обработки данные и оформления? Это замечательно делается снаружи LaTeX специализированными средствами коим упоминаемые Вам exel-подобные программы никак не относятся.

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

> Отличный проект. Давно использую бета версию 1.5, т.к. не хватало поддержки юникода

Не, знаю, как там юникод, а мне нужен был UTF-8. И таки да - таки есть!

PS. Люди, ну когда уже вы научитесь разделять юникод и утф, а? Кодировки "юникод" _не_существует_в_природе_ блин! Юникод - это стандарт, а не кодировка!

> ИМХО фтопку!

> Чем он отличается от Word'а? Тем что документы хранятся в TeX-формате, а не в rtf или odf? Так, это не меняет его гнилой сути: а именно, то что все директивы форматирования скрыты от глаз пользователя.

IMHO, без вендозятнегов мир стал бы скучен... Вы заметили, что вендозятнеги стали в последнее время такие же агрессивные, как линуксятники X, а то и Y лет назад?.. Знает кошко, чьё сало съело... ;-)

> Проблема в том, что "не думать" Вы так будете над _каждой_ встреченной таблицей. И каждый раз будет как в первый класс ручное оформление.

Ну и в (La)TeX тоже каждый раз заново ручное оформление. Только вместо ткнуть "объединить ячейки" приходится писать что-то вроде \multicolumn{2}{c}{\raisebox{-2pt}[0pt]{\scriptsize\strut организация}}

Для вертикального объединения вообще адекватной конструкции нет

причем все эти "-2pt" приходится отлаживать почти методом подгона (что-то вписал, гляну в xdvi, подправил, снова глянул...)

А когда много однородных таблиц, так и в Excel VB+ADO тоже скрипт для автозаполнения за 10 минут пишется...

>Помоему это была проблемма не с QT а с ДНК.

LyX 1.4.4 b и более ранние использовали GTK1. QT-морда это лишь опция для сборки.

>Ощущение такое, что имеет место некоторое недопонимание. Ну что Вы всё рвётесь смешать процессы обработки данные и оформления? Это замечательно делается снаружи LaTeX специализированными средствами коим упоминаемые Вам exel-подобные программы никак не относятся.

По-моему вы до сих пор не поняли, что не всем нужно вообще обрабатывать данные. Некоторым хватает и возможности их записать. Без геморроя, разумеется. И нигде ничего тогда прогонять внезапно не нужно, и гвозди кувалдой забивать не приходится. Я вам по секрету скажу - миллиардов данных в биологии вообще почти никогда не бывает. И живут с екселем - не горюют. Знаете, что такое инструмент, отвечающий задачам? Это не только когда на миллиарды данных парки машин сооружают, а ещё когда не сооружают парки машин для вычислений типа 2+2. Разделение задач для простеньких расчётов не нужно, если результат достижим куда проще и эффективнее. Идеологию фанатикам оставляют, а людей больше их исследования интересуют, чем мнение компьютерщиков о том, правильно ли использовать excel, или нет.

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

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

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

Я не спорю - можно копаться и совочком, но тогда нет никаких шансов выкопать котлован.

> Люди, ну когда уже вы научитесь разделять юникод и утф, а? Кодировки "юникод" _не_существует_в_природе_ блин!

Кодировка с двухбайтовым представлением каждого символа -- это что? Не юникод разве?

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

Вот как раз составить таблицу в любом wysiwig-редакторе куда быстрее и в разы удобнее, чем в латехе, а если ещё нужно пару клеток объединить, то начинается веселье.

>Я не спорю - можно копаться и совочком, но тогда нет никаких шансов выкопать котлован.

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

> Кодировка с двухбайтовым представлением каждого символа -- это что?

ХЗ что это.

Единственная кодировка для Юникода с кодированием непеременной длины это UTF-32/UCS-4 (32 бита на символ).

з.ы. Длина символов в UTF-8 может быть от 1 до 4 байт.

> Для вертикального объединения вообще адекватной конструкции нет

Например, пакет multirow - подробности в README. Что такое адекватная конструкция не понимаю.

> А когда много однородных таблиц, так и в Excel VB+ADO тоже скрипт для автозаполнения за 10 минут пишется...

Вот беда под GNU/Linux это не работает :) Так что этот метод имеет серьёзный минус и он не капли не лучше, чем то же с использованием LaTeX.

>> Я не спорю - можно копаться и совочком, но тогда нет никаких шансов выкопать котлован.

> Вы когда картошку копаете, экскаватор подгоняете?

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

Итого, что же я пытаюсь донести:

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

б) автоматизация в связке с LaTeX проще организуется

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

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

>а) Создание таблиц везде является нетривиальной процедурой и везде занимает примерно одинаковое время.

Неверно. Создание таблицы в wysiwyg процедура, с которой справится любой. Она наглядна, позволяет сразу увидеть результат и ошибки(двигать колонки, строки, ячейки, вставлять новые) и позволяет действовать пошагово. Создание же таблиц в латехе заставляет ломать голову над "какой же мне параметр взять и как он сработает?" и постоянно пробно компилировать. Можно, конечно, сидеть и тренироваться, пока не набьёшь руку, но быстрее, чем в wysiwyg всё-равно не выйдет и это именно "мартышкина работа". Так же наглядно и очевидно, как рисовать графики напрямую на языке postscript.

>б) автоматизация в связке с LaTeX проще организуется

Не всем она нужна и не везде применима.

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

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

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

С другой стороны, делаем вывод, что если таблицы у вас автоматом не создаются и они будут сложнее чем 2х2 ячейки - обходите латех стороной, если вам дороги ваши нервы. Я так и делаю. Котлеты отдельно, мухи отдельно. И все счастливы.

> Например, пакет multirow - подробности в README. Что такое адекватная конструкция не понимаю.

Не нашёл сразу. Спасибо за ссылку. А то видел конструкции вида ... & наиме- & ... \\ ... & нова- & ... \\ ... & ние & ... \\

ужас! и это в LaTeX, где переносами должен заниматься TeX, а не пользователь

>> ...так и в Excel VB+ADO... > Вот беда под GNU/Linux это не работает :) Так что этот метод имеет серьёзный минус и он не капли не лучше, чем то же с использованием LaTeX.

Согласен. В случае Linux каждый раз приходится мучительно выбирать между LaTeX и HTML+CSS. Особенно когда в тексте есть и немного формул и немного таблиц :-(((

Кстати в OpenOffice.org вроде тоже доступ к БД есть.

>> а) Создание таблиц везде является нетривиальной процедурой и везде занимает примерно одинаковое время.

> Неверно. Создание таблицы в wysiwyg процедура, с которой справится любой.

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

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

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

> С другой стороны, делаем вывод, что если таблицы у вас автоматом не создаются и они будут сложнее чем 2х2 ячейки - обходите латех стороной, если вам дороги ваши нервы. Я так и делаю. Котлеты отдельно, мухи отдельно. И все счастливы.

У Вас похоже в тексте одни таблицы. Очень слабо в это верится. А про 2x2 это Вы загнули, причём очень сильно.

В общим - топики выводов остаются.

> Кстати в OpenOffice.org вроде тоже доступ к БД есть.

Есть, причём он сделан IMHO более грамотно чем в альтернативной системе. Там изнально ориентация была на внешнюю БД. Я думаю в ближайшую пару лет запущенная в фоне БД станет нормой и многие программыбудут там хранить свои данные.

Но, опять же IMHO, для работы с текстом это не тот инструмент, который удобен.

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

А чем он лучше HTML+CSS?

а) Таблицы в HTML делаются проще. Оформление таблиц через CSS делается проще. Для аналога простых вещей вида { border-bottom: 1px dotted red; padding: 1em; } в LaTeX приходится искать пару нестандартных пакетов или писать почти программу на TeX.

б) Вывод в LaTeX или в HTML одинаково прост (и то и другое -- текст)

в) в HTML нет только формул (точнее они есть, но сильно извращенно, примерно как таблицы в TeX) и нет нормального алгоритма переноса по слогам. Для печати можно использовать TeX'овские шрифты в PostScript'е. Логическая разметка есть, гиперссылки и стили тем более.

> Согласен. В случае Linux каждый раз приходится мучительно выбирать между LaTeX и HTML+CSS. Особенно когда в тексте есть и немного формул и немного таблиц :-(((

Если и то, и то более-менее не сложное, то IMHO настроенная MediaWiki+WikiTeX это выход. Там ещё и другие плюсы есть.

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

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

>У Вас похоже в тексте одни таблицы. Очень слабо в это верится. А про 2x2 это Вы загнули, причём очень сильно.

Я вам уже привёл пример с таблицей по генетике, из-за которой после 3-х часов ковыряний в книгах латех пришлось выбросить в печку и взять OO_writer. Так что выводы, действительно, остаются.

> А чем он лучше HTML+CSS?

Разные цели. Когда мониторы встанут по 300 dpi нехватка выразительности в HTML встанет в полный рост. Простые вещи и там и там делаются просто. А сложные вещи, к которым справедливо относят формулы, в HTML просто отсутвуют (MathML просьба не упоминать).

Кроме формул есть ещё куча разных вещей, как-то форматирование алгоритмов и кода, формирование библиографии и указателя, автоматическая нумерация разделов, формул и создание гиперссылок между ними. Кроме перечисленного есть ещё просто море специализированных решений начиная от шахмат, коначая тибетских табличек с пожеланием счастья. TeX - это язык программирования знание которого облегчается массой готовых решений (CPAN пошёл от CTAN), где код идёт вместе с текстом, что позволяет решить под час весьма нетривиальные задачи. Хотя в большинстве случаев достаточно стандартных конструкций.

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

> Спасибо, но мир как-нибудь без лоровского техноснобизма обойдётся.

Безусловно, как и мириады мух выбирающих сами знаете что.

То, что у Вас конкретно что-то не получилось - вовсе не показатель плохости инструмента. У меня сильное подозрение, что гораздо вероятнее, то, что в Вашем случае этот инструмент неправильно применялся. И причина этого попытки применить старые навыки в новом окружении.

Разные цели. Когда мониторы встанут по 300 dpi нехватка выразительности в HTML встанет в полный рост. Простые вещи и там и там делаются просто. А сложные вещи, к которым справедливо относят формулы, в HTML просто отсутвуют (MathML просьба не упоминать).

Формулы и греческие символы в HTML как правило делают картинками. Если эти картинки делать векторными (SVG), то проблем с масштабированием тоже нет.

Проблем у HTML4 + CSS2 при 300dpy если честно, не вижу. Мне банковская электронная система выдает печатные формы документов в HTML и ни разу оформление не плыло. Единственная проблема: нет нормальных переносов, но это опять же при жёсткой необходимости лечится при генерации HTML (делается что-то типа TeX, но с выводом не в PS, а в HTML и переносы ставятся жёстко, для печатной копии реальный вариант). Ну и шрифты в TeX мне больше нравятся.

Насчет сложных вещей для LaTeX: как сделать фон-картинку для заданнй таблицы/ячейки/абзаца. Как сделать в таблице жестко заданную высоту строки в мм (для той же платежки, например)? Скорей всего на эти вопросы есть ответы типы "пакет xxx", но решение вряд ли красивее упомянутого MathML

> Формулы и греческие символы в HTML как правило делают картинками. Если эти картинки делать векторными (SVG), то проблем с масштабированием тоже нет.

Ну и как Вы себе это представляете. Вы хотя бы примерно сможите оценить сколько человеколет потребуется чтобы хоть как-то приблизиться к LaTeX-качеству. Самое простое встроить LaTeX в каждый браузер. Подождём ещё пару лет чтобы кодовая база мозилы разрослась так, чтобы туда можно было незаметно спрятать TeX Live :)

> Проблем у HTML4 + CSS2 при 300dpy если честно, не вижу. Мне банковская электронная система выдает печатные формы документов в HTML и ни разу оформление не плыло. Единственная проблема: нет нормальных переносов, но это опять же при жёсткой необходимости лечится при генерации HTML (делается что-то типа TeX, но с выводом не в PS, а в HTML и переносы ставятся жёстко, для печатной копии реальный вариант). Ну и шрифты в TeX мне больше нравятся.

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

> Насчет сложных вещей для LaTeX: как сделать фон-картинку для заданнй таблицы/ячейки/абзаца.

Я удержусь от вопросов зачем. Что-то было в ncclatex на тему watermaks (так кажется). В сторону полноцветной полиграфии с рюшечками движется ConTeXt - там оно должно более логично решаться.

> Как сделать в таблице жестко заданную высоту строки в мм (для той же платежки, например)?

Подпорка - оно же strut нужной высоты и всё закатать в parbox. Что-то было на эту тему у Ольги Лапко.

> Скорей всего на эти вопросы есть ответы типы "пакет xxx", но решение вряд ли красивее упомянутого MathML

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

>Безусловно, как и мириады мух выбирающих сами знаете что.

Да тут скорее фанатики, узнавшие latex/vim/emacs/консоль и пихающие их в своём фанатизме везде, где нужно и где не нужно. Никаким выбором инструмента по задаче здесь и не пахнет. Техноснобы вне добра, зла и зачастую, увы, рассудка.

> У меня сильное подозрение, что гораздо вероятнее, то, что в Вашем случае этот инструмент неправильно применялся.

Я бы сказал, что думаю конкретно об этих подозрениях, но это будет 5.1 :) Инструмент, который после трёх часов перелопачивания литературы оставляет лишь головную боль вместо результата, в то время как в другом инструменте этот результат минут за 30-40 получаешь, идёт лесом и для подобных задач больше не используется.

С вами всё ясненько - одни эмоции :(.

С вами всё стало ясно ещё раньше :(

Пару лет назад набрал в Lyx диссертацию. Сейчас попробовал 1.5 - набрал имя раздела, вставил рисунок... и рисунок на выходе оказался ДО заголовка документа. Глюк? Вроде в ТеХе заведомо заложена логическая структура.. А тут по умолчанию СОДЕРЖИМОЕ раздела подается раньше НАЧАЛА раздела. Удивляюсь как я диссер смог набрать - видимо времени было много