Как вы считаете, надо ли все приложения тянуть в WWW?

почему браузер говно, а локальный почтовый клиент не говно? не улавливаю логики. Кроме того, не верно говорить что почтовый клиент где-то «запущен». Гугл предоставляет браузеру доступ к почте по запросам, а сам почтовый клиент запущен прямо в браузере, на javascript.

> почему браузер говно, а локальный почтовый клиент не говно? не улавливаю логики.

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

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

> Программ-то и нету

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

Кроме того, я не совсем понимаю технологию.

Читай доки. Никто за тебя это не сделает.

тут можно ставить точку - ты не адекват. Из того что человеку нравится X не может следовать что человек мерзавец.

Вы же предлагаете план9 для использования широким кругом пользователей, не я. У линукса есть реальные претензии на массовость - для линукс есть программы. Для план9 их надо сначала написать. Нет, я не хочу писать все программы которые использую. Также я не хочу сам выращивать себе еду, изготавливать компьютеры и бытовую технику и строить дом.

> Из того что человеку нравится X не может следовать что человек мерзавец.

А если я скажу, что мне нравится Холокост?

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

Не предлагаю. Я ничего не говорил про «широкий круг пользователей».

Значит, ты фашист и антисемит :)

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

> Значит, ты фашист и антисемит :)

Так вот, следует ли из этого, что я мерзавец?

Холокост - явление больше мифологическое, чем историческое, в то время как Web 2.0 - отвратительная реальность.

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

И?

Очевидно не следует. Web 2.0 - тоже мифология :) точнее это сборник идей, как и холокост

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

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

У меня регулярно бывает задача подрезать-поресайзить фотку и убрать красные глаза. Какие графические редакторы есть для Plan9?

tweak, crop

Сам не пользовался.

Авторы tweak похоже не поняли шутки про графический редактор и hex редактор.

val(hex) The value used to modify pixels within magnified images. The value must be in hexadecimal, optionally preceded by a tilde for bitwise negation.

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

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

Да задолбал уже, никому не надо заменять чей-то там функционал. Надо решать конкретные задачи.

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

> Так графические редакторы и решают конкретные задачи.

Я просил тебя сформулировать эти задачи, но ты не ответил.

Я и сформулировал

гистограммы, фильтры, возможность рисования, слои

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

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

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

Не, ну честно, мне совершенно неясно, какую задачу ты подразумевал под «гистограммами».

Вот это действительно формулировка: http://www.linux.org.ru/forum/games/3952792#comment-3952855

Под гистограммой в контексте графики понимают ровно одно. http://www.colorpilot.ru/theory.html

Я привел примеры задач.

Обычно это обработка фотографий, рисование и создание коллажей.

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

Даже этот редактор http://pixlr.com/editor/ покрывает большую часть моих потребностей.

Отлично, уже хоть что-то ясно. Теперь детализируй.

Я и детализировал. Процесс обработки изображения такой - поправил, посмотрел, поправил. Причем чем короче итерация тем лучше. По этому современные граф.редакторы которые ты так ненавидишь wisywig. Т.е. двигаешь ползунки фильтра, и видишь результирующее изображение. Разобрать фильтры на отдельные процессы не получится, потому что гонять через сокеты 100 метров туда-сюда очень накладно. Перед пользователем в любом случае должен быть интерфейс, где он меняет настройки и _сразу_ видит результат. Опиши мне как этого достигнуть придерживаясь тех идеалов простоты которые ты отстаиваешь.

Где это я писал, что ненавижу современные графические редакторы? Я про них вообще ничего не знаю. И я не вижу в твоем примере противоречия «идеалам простоты». Я не предлагаю всегда бездумно использовать пайпы - в отличие от тебя, я предлагаю думать перед тем, как что-то использовать. Сколько у тебя этих фильтров и чего там у тебя еще? 10? 100? Организовать библиотечку для этих операций (или несколько), пусть редактор ее юзает и предоставляет файловый интерфейс доступа к ним. А вот для разовых нестандартных вещей пайпы будут очень кстати: не надо изобретать никаких велосипедов, просто вызвал программу для выделенной области и получил результат. И ты уверен, что гонять 100 метров так уж накладно? Ты измерял?

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

И пришли мы к бинарным плагинам и большой монолитной программе. т.е. как минимум не все и не всегда можно реализовать в идеологии план9.

На самом деле именно профессиональный софт работающий с огромными объемами данных в первую очередь плохо разделяется на отдельные программы-компоненты.

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

Писать плагин явно медленнее, чем использовать существующую программу. Спорить будешь?

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

Спасибо, кэп. Не всё и не всегда можно реализовать в любой идеологии. И о какой «идеологии план9» ты говоришь? Фундаментальный принцип Плана 9 - программа, предоставляющая вовне ресурсы, предоставляет их в виде абстракции файлов, работая как файловый сервер, по файловому протоколу. Это просто более высокий уровень декомпозиции системы по сравнению с декомпозицией на основе подпрограмм и стека вызовов. Ясно, что если мы для эффективности хотим работать на низком уровне, с общей памятью, то о файлах речь вообще не идет - работает старый добрый стек. Так же как картинки мы декодируем, кодируем и обрабатываем на Си, а не жабе или питоне, а флаш кэша процессора делаем на ассемблере, а не на Си.

И пришли мы к бинарным плагинам и большой монолитной программе.

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

На самом деле именно профессиональный софт работающий с огромными объемами данных в первую очередь плохо разделяется на отдельные программы-компоненты.

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

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

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

Почему ты считаешь, что сама программа при этом непременно должна быть большой и монолитной?

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

Собственно ты пишешь

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

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

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

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

И я ни разу не видел вордовский документ из многих тысяч страниц. Что, кто-то уже монографии в ворде пишет? Куда мир катится.

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

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

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

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

Опять же - совершенно беспредметно. Что значит «максимально эффективно»? Надо измерять. В одних случаях для эффективности переписывают кусок кода на ассемблере под несколько архитектур, в других случаях всё делает шелл-скрипт, и никто его не стремится переписать его на Си, всё шустро работает, поскольку узкие места - не в шелле, не в форках и не в пайпах. Давай примеры. Ты привел только растровую графику и говноворд, в ненужности которого я убежден.

По поводу ненужности ворда. В очередной раз требую выкатить замену ворду, и описать чем именно она будет лучше.

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

Про небольшие объемы я ответил: большинство профессиональных программ работают с большими объемами: чертеж корабля/самолета, 3д модель чего-угодно, тысячестраничная монография, двухчасовой фильм, рекламный постер 10 на 10 метров, проект из миллиона строк кода.

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

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

Замену для чего? Мне он либо опенофис нужен лишь когда приходится иметь дело с вордовскими документами. Т.е. ворд создает проблему (мне создает, сволочь), а не решает.

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

Бедняжка.

Про небольшие объемы я ответил: большинство профессиональных программ работают с большими объемами

Про небольшие объемы я тебя не спрашивал. Не знаю, кому ты отвечал, и умеешь ли ты вообще читать и воспринимать прочитанное.

Я спрашивал: 1. почему программа, расширяемая с помощью бинарных модулей, обязана быть очень сложной. 2. примеры приложений, для которых целесообразен механизм расширения с помощью бинарных модулей (с обоснованием целесообразности).

Модульность на уровне ОС нужна уже на уровне конечного пользователя, чтобы он мог быстро поменять небольшую часть поведения программы.

Каждый раз вручную, да?

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

Почему?

> Замену для чего? Мне он либо опенофис нужен лишь когда приходится иметь дело с вордовскими документами. Т.е. ворд создает проблему (мне создает, сволочь), а не решает.

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

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

Вот где про небольшие объемы.

1. почему программа, расширяемая с помощью бинарных модулей, обязана быть очень сложной.

Очевидно потому, что простые программы существуют только в головах олдскульщиков. Потому что задачи перед программами стоят сложные. Посмотрим тот же фотошоп. Он поддерживает рисование мышкой, и рисование с дигитайзера (с поддержкой нажима и прочего), поддерживает обработку многогигабайных изображений (своя подсистема «виртуальной памяти»), поддерживает десятки цветовых пространств с разной битностью, умеет растровое и векторное редактирование. Или тотже ворд. Макросы, стили, шаблоны, библиография, встраивание объектов предоставляемых другими программами. Простым тут не обойдешься. Можно сказать по-другому. Профессиональный софт должен хорошо решать _сложные_ задачи, по этому сам он сложный.

2. примеры приложений, для которых целесообразен механизм расширения с помощью бинарных модулей (с обоснованием целесообразности).

Самый очевидный и массовый вариант - графический редактор.

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

Почему?

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

> Очевидно же, замену для системы подготовки документов для печати. Если тебе присылают документы, значит ты их не создаешь. В чем бы ты создавал подобные документы?

Почему же, создаю. latex, troff.

> Я говорил о разделении адресных пространств и о модульности на уровне ОС в контексте текстового редактора - приложения, осуществляющего операции над небольшими объемами текстовых данных.

Вот где про небольшие объемы.

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

Профессиональный софт должен хорошо решать _сложные_ задачи, по этому сам он сложный.

А у меня очень сильные подозрения, что не поэтому. Обоснуй. Давай, формулируй эти невпупенно сложные задачи.

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

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

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

Самый очевидный и массовый вариант - графический редактор.

Да блин, я просил ЕЩЕ примеры. Растровую графику уже обсосали (впрочем, ты не на все мои вопросы ответил).

О, у тебя еще один коммент, не заметил сразу.

Зачем вообще фоновый спеллчекер? Я бы вызывал его по завершении ввода слова. (Автоматически, естественно.) Один фиг узкое место - собственно лукап словаря. Ну а wysiwig верстка просто ненужна и вредна. Я знаю, ты сейчас будешь негодующе размахивать руками, но это правда. Представь, что ты пишешь с нуля свой wysiwig редактор форматированного текста. Просто для себя. Захотелось вот тебе сделать себе такой инструмент, максимально эффективно удовлетворяющий твоим нуждам по форматированию. Уже на этапе проектирования редактора или ранее, в процессе исследования проблемы, ты обнаружишь, что wysiwig банально не нужен и лишь создает искусственные проблемы, в то время как цикл «правка исходника - генерация документа - просмотр - правка исходника» справляется с задачей на ура.

Я честно пробовал пользоваться LaTeX, но он замедляет работу. Особенно когда начинается вставка/подгонка картинок и графиков, переносы таблиц по госту/не по-госту. Переносимость шаблонов там - адский ад.

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

Wisywig создает проблемы в основном разработчикам редактора, а не пользователям - такое мое имхо. (когда я писал в техе, я использовал тайловый вм и слева открывал код, а справа просмотр - чем не тормзоной визивиг?)

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

> Я честно пробовал пользоваться LaTeX, но он замедляет работу. Особенно когда начинается вставка/подгонка картинок и графиков, переносы таблиц по госту/не по-госту.

Мне самому latex не нравится, он монструозен, но в нем по крайней мере есть смысл. Посмотри еще на troff с друзьями.

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

Переносимость шаблонов там - адский ад.

Эта проблема не имеет отношения к вопросу использования/не использования wysiwig. Можно вообще не использовать шаблоны, тогда не будет проблем с их переносимостью. Ты вот упоминал отчеты по лабам в универе - так я их частенько вообще в HTML делал, было прикольно.

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

Документ без внутренней структуры это plain text. Форматирование означает структуру. Работая wysiwig, ты всё равно создаешь структуру, неявно, не осознавая, что ты делаешь. Крайне дегенеративная методика.

Wisywig создает проблемы в основном разработчикам редактора, а не пользователям - такое мое имхо.

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

> Декомпозиция не всегда возможна, на самом деле. Например распознавание текса/речи натыкается на невозможность декомпозиции: нужно распознать, прогнать через словари, синтаксические и семантические анализаторы, с учетом результатов повторить распознавание и так пока не получится адекватный результат. Так ведет себя человек, когда читает неразборчивый почерк. Эти задачи просто нельзя разделить, они должны работать одновременно, во все стороны и дополнять результаты друг друга.

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

Собственно более близкий пример - алгоритмы из вычислительной математики. Куча переменных (реально куча, почти каждый промежуточный результат заносится в переменную чтобы не считать по 10 раз), даже если выделить функции, списки параметров у них будут о-го-го. Рождаются портянки кода на 5-6 экранов с парой десятков переменных. Можно конечно собрать все эти переменные в структуру и вызывать функции от этой структуры, но решение несколько надуманное, потому что каждая такая функция будет бессмысленной.

У меня не было проблем с вордом и таблицами. Нормально переносит, нормально повторяет заголовок.

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

HTML вообще не пригоден для верстки текста. Где форматирование по ширине, переносы, колонтитулы?

Документ без внутренней структуры это plain text.

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

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

>Холокост - явление больше мифологическое, чем историческое

ты это скажи всей семье моего деда, которых сожгли/расстреляли в польше, мудила нацисткая

> Собственно более близкий пример - алгоритмы из вычислительной математики. Куча переменных (реально куча, почти каждый промежуточный результат заносится в переменную чтобы не считать по 10 раз), даже если выделить функции, списки параметров у них будут о-го-го. Рождаются портянки кода на 5-6 экранов с парой десятков переменных. Можно конечно собрать все эти переменные в структуру и вызывать функции от этой структуры, но решение несколько надуманное, потому что каждая такая функция будет бессмысленной.

Давай пример.

Открой исходники alglib http://alglib.sources.ru/translator/re/alglib-3.4.0.cpp.zip, и найди там длинные функции с реализацией алгоритмов. (там есть обертки в 10 строк, и длинные функции, которые выполняют всю работу). Учти еще, что это библиотека классических универсальных алгоритмов. В конкретных задачах бывает намного хуже.

> У меня не было проблем с вордом и таблицами.

А у меня были. Не аргумент.

Сверстать документ по гост(или еще как-то) настолько нетривиально, что в интернете гуляет куча шаблонов для титульников, таблиц, вставки картинок(!).

Это проблемы латекса, а не шаблонов как подхода.

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

Проблема надумана. Как выглядит сама картинка - это и так видно, а как она выглядит в документе - это не должно требовать просмотра более 1-2 раз.

HTML вообще не пригоден для верстки текста. Где форматирование по ширине, переносы, колонтитулы?

Да он вообще ни для чего особо не пригоден. Просто писать его в редакторе было приятнее, чем использовать говноворд.

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

Не вижу причин, по которым это трудно сделать без wysiwig.

Это проблемы латекса, а не шаблонов как подхода.

Проблемы латекса сводятся к повышению рождаемости и/или абортов. А в латехе проблема - в меняющихся ГОСТах.

> >Холокост - явление больше мифологическое, чем историческое

ты это скажи всей семье моего деда, которых сожгли/расстреляли в польше, мудила нацисткая

А моих предков мамонты затоптали. Я указал на то, что Холокост - прежде всего явление массового сознания. Из чего следует, что я нацист? Не давай эмоциям взять верх над разумом.

> Проблемы латекса сводятся к повышению рождаемости и/или абортов.

Разве не к понижению? )

А в латехе проблема - в меняющихся ГОСТах.

И это тоже.

Ну как же: дырявый латекс - лишний ребенок. А у некоторых и денег на аборт нет, так появляется новый бомж.

> Это проблемы латекса, а не шаблонов как подхода.

Это проблемы именно шаблонного подхода. Гост описан в визуальных терминах. Считать сколько там должно быть пунктов - задача не для человеков.

Проблема надумана. Как выглядит сама картинка - это и так видно, а как она выглядит в документе - это не должно требовать просмотра более 1-2 раз.

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

Не вижу причин, по которым это трудно сделать без wysiwig.

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

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

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

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

Это проблемы именно шаблонного подхода. Гост описан в визуальных терминах. Считать сколько там должно быть пунктов - задача не для человеков.

ГОСТ шаблонизируется элементарно. Я, когда диссер верстал, не сильно-то много изменил в стандартных стилях, чтобы соответствовать ГОСТам на тот момент.

Для этого в ворде я мышкой подгоняю размер и положение картинок, а в латехе это сделать не тривиально.

Вот только в латехе при изменении текста с картинками (если вы, конечно, верстаете по правилам типографской верстки) ничего не случается. А в «ворде» или не менее дебильном OO/LO все «расплывается».

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

Это будет так до первой правки. А иногда даже открывание в «ворде» другой версии убивает верстку напрочь.

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

Ага, а получается все одно - УГ.