Движок openSpace: разработка и доработка
Пожелания и предложения по развитию программной платформы openSpace следует публиковать в параграф Идеи (если она будет принята в план разработки, то её перенесут в параграф Сделать).
Убедительная просьба вносить сообщения обо всех обнаруженных ошибках в работе сайта, багах и недоработках непосредственно в текст страницы (параграф Исправить), но не в комментарии документа!
Основой платформы сайта служит движок openSpace, представляющий собой сильно модифицированную wiki-систему WackoWiki. Выбор пал на нее из-за простоты устройства, модульности, позволяющей легко изменять систему и подгонять под специфические нужды, наконец, субъективная характеристика — код написан на PHP, и для хранения данных используется БД, а не файловая система.
Поскольку сайт не является wiki в обычном смысле, движок подлежит ряду доработок. В частности, от поддержки ВикиИмен оказалось больше вреда, чем блага, поскольку большинство страниц раскиданы по кластерам, а не размещены в корне сайта, и экранировать все встречающиеся слова со смешанным регистром не слишком удобно. Есть и другие изменения, внесенные в оригинальный движок: основные из них перечислены ниже.
Сделать
- Элементы страницы для работы с сетью доверия
- Компонент динамического управления рабочими группами
- Компонент администрирования пользовательских профилей
- Дополнительный флаг для прав доступа: изменение свойств и правка документа должны быть подтверждены подписью PGP
- Усиление защиты аккаунтов:
- привязка (salt) в пользовательских паролях (защиты от тривиальных и идентичных паролей, rainbow-атак)
- хранить в базе данных H(H(pwd)), в cookie — H(pwd) (защита при компрометации БД), снимаю шляпу перед Стивом Мёрдоком
Переход к бета-стадии (v0.9b)
- Инсталлятор
- Права доступа на участие в опросах (и просмотр определённых опросов?).
Также указывать ID опросов для упрощения ссылок на них.Возможность комментирования опросов. (Перенести опросы в адресное поле документов, но использовать специфический хэндлер?) - Соответствие XHTML 1.0 Transitional
- Универсальная (многоязычная) адресация страниц. Требуется: 1) заглавная страница для каждого языка, 2) уникальный ключ на поля { lang, tag(?), supertag }.
- Вывод страниц в кодировке UTF-8
- Полный рефакторинг кода:
- хэндлеры, действия и административные модули переписать в классы вместо inline-php
- вынести lang-strings действий и хэндлеров в самостоятельные динамически подгружаемые lang-файлы
Исправить
- Поправка: более детальное тестирование показало, что в определённых случаях проблема сохранилась. Однако, стало возможным отключение части функций типографики (в частности, обработки кавычек) без ущерба для остальной функциональности. Окончательное решение пока не найдено.
- Несколько подряд вызываемых редакций одного и того же комментария имеют один и тот же урл, что приводит к невозможности редактировать несколько раз подряд один и тот же комментарий в браузерах с активным использованием хэша (links, elinks и другие).
- Примечание: в связи с технической сложностью и нехваткой времени решение этой проблемы отложено на будущее.
- При использовании BBCode-разметки если использовать цитирование в списке, сообщение выводится некорректно (большая часть не выводится вообще), не говоря уже о корректном форматировании.
- Обход: использовать только wiki-разметку в указанном случае.
-
Нет связи с главным ключём при подписывании материалов, т.е. при смене подключа для подписи выдаёт: "неопределенная ЭЦП ключом 0x12345678, не зарегистрированным на сайте".Чтобы избежать такой ошибки, нужно либо вручную обновить ключ на сайте (удалить и загрузить по-новой), либо отправить на сервер ключей и дождаться, пока сайт в плановом порядке обновит его сам. - В броузере Opera не отображается панель Wiki разметки, что делает неудобным оформление постов. Прошу обязательно исправить.
- Код панели разметки несовместим с Оперой. Он целиком заимствован из WackoWiki. Если разработчики решат его исправить, исправление будет принято и в oS. Либо исправьте сами и пришлите патч.
- Поиск: если в поле "Автор" указать "Гость", то поиск не срабатывает. Контрпример: поиск слов "pgpru" или pgpru* возвращает "Результатов не найдено", хотя есть (один из примеров) /comment43978.
- При вставке ссылки, содержащей кириллические символы, копированием из firefox (например, из русской википедии), бьётся кодировка, и ссылка становится нерабочей (сайт не делает преобразование "URL-encoded → UTF-8").
- Обходной путь: перенабирать кириллические символы в ссылках руками при вставке в вики-документы.
Идеи
- Возможность загрузить в профиль электронную визитку (vCard ver. 3.0) и её подпись.
- Автоматическое получение метки времени на каждую редакцию документа.
- Замена RSS 2.0 на Atom 1.0 (RFC 4287), как на свободный и более современный формат.
- Добавить тэг [offtopic] (можно сокращённо [off]), чтоб по умолчанию (без клика) показывал бы только одну строку, в начале которой он стоит, а по клику веcь блок до закрывающего тега [/off]. Или даже сделать тег [subtopic имя_подтемы], при клике на котором будут раскрыты все субтопики с этой подтемой.
- Было бы не плохо сделать древовидными комментарии: ответ на комментарий дается под конкретным постом, а не просто в общей ветви. Так же полезно добавить возможность отображения комментариев как с первой записи, так и с последней (новые записи в начало)
- Надпись "Комментарий добавлен" лучше сделать зелёной.
- Поиск
попросту не работает, use-case нулевой, я в шоке!(пункты 2 и 3 — крайняя необходимость, 1, 4, 5 и 6 — можно отложить на потом):- Так называемый
стандартный поисковый синтаксис: знаки "плюс", "минус", "звездочка", скобки и т.д
должен быть описан, либо дана ссылка на его описание. Мне, например, совершенно неочевидно есть ли отличие "слово1 + слово2" от "слово1+слово2". Так же, не ясно как использовать скобки. Выводить каждому эти правила эмпирически — не лучший подход. - Очень существенная часть полезной информации размещена как комментарии к каким-то, зачастую слабо связанным с темой самого комментария, темам. Найти эти комментарии очень трудно. Ввиду этого наличие переключателя "Не искать в комментариях страниц" при отсутвии переключателя "Искать только в комментариях страниц" — форменное издевательство. Предлагается реализовать. Да, и лучше писать "в комментариях к станицам", а не "комментариях страниц" (страницы сами комментируют?) — так точней и звучит лучше.
- В выводе результатов поиска вместо того, чтобы (как и делают поисковики типа гугла) показывать кусок текста, содержащий искомое слово или их комбинацию, всегда выводится начало комментария. Не трудно догадаться, что если искомое слово (предложение, цитата) — где-то в середине "простыни", часто посвящённой ответу на несколько слабо связанных между собой вопросов, то догадаться, где же оное среди десятков безликих шапок комментариев, практически невозможно. Это ключевой момент, который полностью обесценивает наличие поиска на сайте. Если трудно сейчас реализовать вывод контекста, путь хотя бы найденные комментарии выводятся полностью, целиком.
- В выводе результатов поиска, в порядке очень странного и необъяснимого исключения, показывается сам вики-сорс со всей текстовой разметкой вместо того, чтобы показывать собственно результат её действия. Это улучшает восприятие? Кроме того, это существенный privacy leak: одно и то же "на печати" можно получить разными способами и используя разные форматы (BB, вики-разметку и т.д.), и в самих комментариях этого не будет видно, зато отлично видно в поиске: кто, и как в точности использует эту разметку и какие именно из её элементов.
- В поле "Автор" логично было бы включить поддержку списка пользователей (не забывайте, что Гость — тоже пользователь!). Т.е. если указано "SATtva, unknown", это бы значило "все документы/комментарии, опубликованные либо SATtva'ой, либо unknown'ом".
- Было бы очень кстати реализовать поиск по документам/комментариям, появившимся за последние n месяцев (или m лет, если им больше года), добавив соответствующее поле/параметр. Часто хорошо помнится, когда примерно было опубликовано то или иное, но вот поисковику на сайте это не объяснить.
- Так называемый
- Разрешить при создании темы вводить ограничения для комментаторов. Например, запрещать им писать под гостем, чтобы псевдоним в теме был обязателен. Или, если более общо, можно разрешить вводить допусимую (для создателя темы) долю таких комментариев (на каждой странице или во всей теме)
- Выделение цитат <[цитата]> неудобно по двум причинам: нужно переходить в латинский регистр и символы разные. А ведь это одно из наиболее часто используемых форматирований! Ну и поскольку в первую очередь оптимизировать надо самое частое, то хорошо бы добавить возможность выделять цитаты на русском регистре и повтором символа, например ;;цитата;;. Или лучше \\цитата\\ – даже на шифт не надо нажимать.
- При использовании сносок (разметка наподобие ((*1)) и ((#1))) оные относятся ко всей странице, а не к комментарию, где они нужны (т.е. если в одном комментарии уже есть первая сноска, то первую сноску во втором комментарии необходимо нумеровать как минимум с двух). Лучше, когда каждый комментарий — "корнем" для собственных сносок. При желании сослаться на объект в других комментариях или на объект в самом топике можно воспользоваться другими элементами wiki.
- Появление нового опроса не отображается в "последних изменениях". Почему бы не добавить? Сайт проще всего отслеживать по странице последних изменений и последних комментариев — там должны быть отражены все изменения, произошедшие на сайте. К тому же, было бы намного удобней иметь не 2 страницы ("комментариев" и "изменений"), а одну, где все изменения отражены.
- Подобно черновикам в wiki удобно было бы иметь поддержку «черновых комментариев»: возможность к каждому треду обсуждений писать и сохранять черновик комментария, который не будет никак отображаться в треде до тех пор, пока не будет официально отправлен. Мотивация: длинные комментарии, дорабатываемые втечение длительного времени, пишутся долго и при этом нигде не сохраняются, кроме как во временном буфере сообщений, потому падение браузера приводит к потере всего комментария. Можно подумать над тем, как такую опцию сделать непротиворечащей анонимности (иметь черновики комментариев так же для гостей).
- Сделать поддержку тегов для форумных веток и новостей. Теги могут придумываться/назначаться пользователями и меняться постфактум. Это позволило бы объединять набор новостей на определённую тему (к примеру, cold boot атаки) в одну виртуальную тематическую подшивку, а также упростило бы поиск.
- Подобно тому, как это сделано для самих тредов и новостей, хотелось бы иметь возможность просматривать referrers для каждого комментария на сайте (список тем и комментариев, которые на него ссылаются). Цель — упрощение тематического поиска.
- Ряд обёрток (box, wacko) не закрывают контекст в конце комментария, из-за чего конец комментария не является реально концом, и один комментарий начинает обтекать другой при неаккуратном форматировании. В итоге, из-за ошибок в разметке одного гостя портится форматирование и последующих постов от других гостей. Исправить.
- Имеется проблема с двойным минусом при его использовании в комментировании wiki-сорса. PoC: %%(comments) тест -- тест%%
- Подстроку вида Гость (24/05/2013 13:02) автоматически превращать в ссылку, если она встречается в тексте.
-
10 – 50 – 100 – 500 комментариев на страницу. 20 листов комменариев, невозможно читать, а так развернул одной страницей, полистал, и задача поиска пропадает, F3.Можно открыть страницу в режиме печати (ссылка в правом верхнем углу). - Большинство форумов и, например, livejournal поддерживают стандартный обычный html. Почему бы не сделать так, чтобы разметку можно было прямо в комментариях оформлять, да и плюс с поддержкой стилей? Было бы здорово и очень просто.
-
SatVa, запили, что бы можно было youtube ролики вставлять в ветвь обсуждения?Нафиг. -
SatVa, верни картикни? Например, всякие блок-схемы тех же шифров, иногда, лучше 1 раз увидеть, чем пять листов прочитать.Локальные изображения работают. Поддержка удалённых неприемлема из-за HTTPS mixed content. - Сделать тэг, чтобы можно было что-то убрать под кат (например исходник LaTeX-формулы, которая вставлена картинкой).
- На данный момент может быть убрано в html-комментарий: %%(comment) текст %%
комментариев: 11558 документов: 1036 редакций: 4118
злые полицаидобрые полицейские и говорят: "Мы подозреваем, что через Ваш сайт переписываютсяроссийские оппозиционерыарабские террористы. Дайте нам их послушать, ни тобольно будетустроят теракт, погибнут люди". Тогда доброму SATtva'е придётся стать злым и изменить код веб-клиента, чтобы он встраивал сеансовые ключи в передаваемые сообщения, которые потом перехватит СОРМ. А учитывая, что js-код каждый раз скачивается с сервера заново, коппозиционерамтеррористам вскореприедет чёрный воронокприлетит крылатая ракета. Теперь фирштейн?комментариев: 1079 документов: 58 редакций: 59
Стадия первая:
Стадия вторая:
Вывод:
Публика PGPru тоже проходила эти стадии кулхацкерства, так что вы не подумайте чего такого...
Правила местной разметки для кретинов
которым похрен на всё, и которые не собираются читать документацию wiki.На печати оно будет выглядеть так:
продолжение текста на следующей строке
продолжение ещё на одной строке с добавкой нового перевода строки
продолжение цитаты
текст ответа
Более ранние цитирования аналогично помечаются через два знака, «>>», ещё более ранние — через три, и т.д. Но тут есть косяк: начиная с трёх, надо делать квотирование перед третьим символом, т.к. разметка глючит:
Напоминаю, что разметка — не часть слова и не знак препинания. Не пишите её вплотную к тексту, ставьте пробел:
>Неправильно
Если в цитате нужно написать мелкий шрифт (см. пукнт 8), то ставьте переключатель на него после знака «>»:
Перед такой цитатой (внутри текста, естественно) нужна одна пустая строка, после неё — ни одной. Переносы и абзацы охватываются такой цитатой искоробки. Если в цитате используются строки, начинающиеся с пробелов, это будет интерпретировано, как простановка отступов или формирование списков — в этом случае закрытие знака цитирования «]>» должно быть на следующей строке, иначе текст перекорёжит.
%%(hl css)# pkill -9 cretins%%
Или:
%%(hl javascript)# pkill -9 cretins%%
Или:
%%(hl diff)# pkill -9 cretins%%.
Полный список — в документации вики, смотрим на хайлайтеры. Не ставьте хайлайтеры для кода с длинными строками в нём — автоперенос для них не работает, страницу разнесёт. В отличие от кода, нужные отступы строк вокруг хайлайтеров проставляются автоматически, поэтому их нужно писать слитно с текстом:
«текст%%(hl css)my code%%продолжение текста».
Стандарта на цитирование здесь нет, но есть простые правила:
https://www.pgpru.com/proekt/poljzovateli?profile=ressa
но вместо неё можно просто написать ((username:ressa ressa)) и получить на печати ressa.
Другой пример:
Ещё пример:
Как не трудно догадаться, это разметка:
- **((/comment75896 Ш))**ифрпанк
- ##**((/comment75896 Ш))**##ифрпанк
- ##**((https://ru.wikipedia.org/wiki/Криптография к))**##риптография
Писать первую букву фигурным образом было принято в старых текстах, но как элемент красоты это правило сохраняется не печати и сейчас во многих современных изданиях, включая статьи при криптографии (смотрим стилевой LaTeX-файл IEEE).Фигасе как у разметка-кун бомбануло.
ему простительно
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Поскольку адаптация вики-разметки для форума по некоторым пунктам всё-равно носит рекомендательно-соглашательный (конвенциональный) характер, то могут быть варианты разночтения и (не)понимания.
Цитата собеседника очевидно ставится через ">", как принято в рассылках, да и здесь логично подсвечивается. Но длинная цитата, а иногда бывает нужно сделать разумный оверквотинг, IMHO в таком виде выглядит не очень. Даже если аккуратно расставить все межстрочные переносы и абзацы. В таком случае удобнее и визуально нагляднее всё равно через <[ ]>, также как и для внешних цитат, но при этом, разумеется, указать ссылку на цитируемый пост.
Недаром же был приведён пример:
Т.е., ">" и вложенные ">>" — это хорошо для коротких цитат собеседника, а для длинных — всё равно <[ … ]>. Не настаиваю на обязательности, просто это неочевидный вариант, по которому могут быть разные аргументы «за» и «против». Опять же, варианты указать ссылку на пост, с которого взята цитата, могут быть разные. Однозначно сказать, что один лучше другого, не во всех случаях возможно. Например, когда в одном посте идут ответы на разные коменты и разным собеседникам, можно сделать ссылку вида SATtva (17/01/2014 12:20):, далее ">"текст цитаты, затем ответ, затем Гость (20/04/2014 00:12): и ответ на его цитату. Чтобы была связь между комментариями не только по наведении курсора на ссылки, но и визуально можно было запомнить, кому, что и на что отвечают.
Другое не(до)понимание вызывают сноски. Понятно, что они кликабельны и удобны для больших документов. Но именно для отдельно размещённых документов. Для форумных постов, IMHO, ссылки вообще не предназначены. Другое дело, что некоторые посты претендуют по объёму на массивный и исчерпывающий документ, с возможностью на его основе создать постоянную страницу, или даже его переноса в отдельный раздел с документацией. Может быть в форуме опубликован в ходе обсуждения и черновик чего-либо, со сложной структурой, оглавлением, ссылками. Но это опять же дискуссионный вопрос, как это всё лучше делать. Я теперь лучше понимаю, почему некоторым хотелось рассылку. Там это органичнее, каждый пост — это отдельное письмо, которое можно рассматривать как отдельный документ (особенно когда в рассылках шлют черновик документации проекта). И связь между постами не такая сильная. Насколько это органично для форума — вопрос дискуссионный. Можно предположить, что в форуме идут слабоструктурированные обсуждения, часто на скорую руку. Вместо чёткого структурирования и ссылок могут быть пометки и разъяснения прямо в тексте. Как только из этого вызревает претендент на законченный документ, который есть желание развивать, то это следует делать на отдельной вики-странице. Да, анонимный постинг тогда не получится, только псевдонимный.
Могут быть и ещё какие-то соображения, когда вопросы разметки выходят за рамки элементарной аккуратности оформления и пересекаются с вопросами соответствия оформления и содержания.
Ещё раз: рекомендации безусловно полезны, но часть правил в них никак не относится к кретинам, а наоборот к любителям публиковать сложные и содержательные посты (или с претензией на таковые), которые в смысловой формат форума (как движка, платформы для обсуждений) еле влезают, но оформить их как-то поприличнее надо.
Пожалуйста. На самом деле, это собрание костылей, где костыли на костылях сидят и костылями погоняют, но другого пока нет. Там далеко не обо всех секретах сказано, упомянул только о том, чем пользуюсь чаще всего. В более сложных случаях приходится часто приходится экспериментировать, благо предпросмотр всегда работает (но и он не всегда даёт ту картину, какая будет после сохранения). Например, дополнительные отсутпы вокруг пунктов в списках вложенности два и более достигаются костылём
Ещё есть вопрос, что будет со всем этим хозяйством при переезде на новый движок. Будет ли реинтерпретирована существующая разметка, что приведёт к полному
испохабливаниюизменению внешнего вида ранних документов wiki? Переезд 2006-го года был как раз примерно таким. Хотелось бы, чтоб новые правила разметки применялись только к новым постам, иначе будет тотальный бардак.Даже если абзац всего один, т.е. не содержит дополнительных строк, вы всё равно используете <[]>, что я никогда не понимал. Внешний вид — отдельная тема, мне тоже не всё нравится, но я скорее склонен принести его в жертву в пользу чёткости разметки.
Хочу подчеркнуть, чтобы не было недопонимания, что внешние цитаты — это не только все цитаты с других сайтов, но и цитаты из поста/постов выше, которые вы хотите процитировать в своём ответе, т.к. они являются частью вашего ответа (т.е. могли бы быть заключены в кавычки, если б это был текст книге), но не тем, на что вы отвечаете в своём сообщении. Вот пример:
Как же так? Вы же сами про себя пишете:
что, мягко говоря, не вяжется с недостатком интеллека.
Всем сейчас понятно, что не все «внутренние» цитаты должны идти через «>»?
В общем, я «против». Во всяком случае, в TBB я уже привык к тому, что как выглядит. Больших претензий к внешнему виду теперь нет, хотя в других браузерах при других шрифтах те же элементы могут выглядеть как лучше, так и хуже.
Раньше, когда большинство постов на сайте было негостевым, это было распространённой практикой, но потом ушло.
«Не дружит с анонимностью». Вы продолжаете разговаривать с людьми и личностями, а не с аргументами. Вам важнее, кто сказал, чем то, что было сказано? Если кто-то не подписывается, то метка времени в цитировании добавляет практически ноль информации, т.к. у разных постов одного и того же Гостя она будет разной. Можно разве что собрать все посты, которые похожи на то, что написаны одним анонимом, а потом прикрепить к этому имени идентификатор, и уже его указывать в цитировании. ☺ Но это будет уже совсем агрессивно.
ссылкисноски вообще не предназначеныЯ не согласен. Сноска — это возможность не писать длинное пояснение в скобках, препятствующее его чтению/парсингу. Считается, что в скобках надо писать только то, что строго необходимо для понимания текста при первом его чтении, всё остальное идёт в сноски, пояснения, аппендиксы, приложения и пр. Если нечто нельзя понять правильно без конкретного пояснения, я его оставляю в том месте текста, где оно нужно. Всё остальное выносится в сноски или пояснения в конце текста. Это делает основной текст короче, яснее, лаконичней, доходчивей.
Когда нормальный человек постит и видит, что вышла хрень, он извиняется, просит исправить, пытается найти причину ошибки и учесть её на будущее. Все следующие посты он проверяет в предпросмотре и исправляет проблемы. Когда пишет кретин, он видит, что получается чушь, но с упорством, достойного лучшего применения, он не шевелит даже пальцем, чтобы что-то исправить. Он считает, что исправлять текст и его форматирование в предпросмотре — ниже его достоинства. Ему всё равно, что и как пишут/оформляют другие, всё равно, какие правила на ресурсе, он их не уважает, не встраивается в систему, он делает то, к чему привык. Привык гадить на имиджбордах если, то приходит и здесь пишет так же. Привык не ставить заглавные в чатах — и здесь ведёт себя так же. Это игра на проверку прочности SATtva'ы. Лично я бы сносил за небрежную грамматику и оформление. Сделал замечание, и если не исправился — добро пожаловать в удалённые. Вы все прекрасно знаете примеры такого поведения здесь.
А для «любителей публиковать сложные и содержательные посты» можно было бы написать ещё один похожий пост не меньшего размера с обсуждением уже «продвинутых» тонкостей:
А вы умеете так писать?
Наверняка ведь нет...комментариев: 11558 документов: 1036 редакций: 4118
Очень странно, принудительная нумерация пунктов (2.#2) всегда работала, но теперь действительно даёт неверный результат ниже первого уровня. Подозреваю, что-то сломалось с обновлением PHP.
Часто об этом думаю. При написании парсера я в первую очередь буду руководствоваться стандартными правилами разметки, чтобы прежде всего стандартная разметка отображалась так, как должна (без всяких этих "на одном уровне вложенности так, а на другом эдак").
Во вторую очередь хочу привести некоторые правила к единообразию (вот какого фига ++ работает в пределах абзаца, а !! — на произвольном блоке текста? почему при одном типе цитирования надо расставлять пустые строки так, а при другом — иначе, и почему пользователь вообще должен задумываться, как их расставлять?), но только если удастся сохранить обратную совместимость либо чисто конвертировать старый формат в новый при переносе базы данных на новый движок.
Что же касается хаков типа последнего в Вашем посте, под них я подстраиваться не буду, и их в итоге скорее всего перекорёжит. You have been warned.
Боюсь, я не осилю написать настолько баг-совместимый код, чтобы в исходном виде перенести нынешний парсер.
Как я уже говорил, внешний вид — штука непостоянная и легко изменяемая через CSS.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
Но я не про принудительную нумерацию, я про отступы вокруг. Показываю пример без отступов:
Теперь оно же с отступами:
- Строка первая
- Строка первая-1
- Строка первая-2
Просто иногда пункты в глубокой вложенности — полноценные абзацы, поэтому, раз мы ставим отступы между абзацами в обычном тексте, логично их поставить и там, не говоря уже про многоабзацный текст внутри подпункта. Вот как выглядит хак:Вот напишете вы движок, всё будет ОК, а потом
PHPпитон обновится, и начнутся пляски по новой. ☺Я бы предпочёл вообще не завязываться на старый синтаксис и правила, а вместо этого продумать и внедрить новый синтаксис, у которого будет свойство полноты, т.е. который покрывает собой все возможности по форматированию, какие могут понадобиться. Например, можно было бы сделать LaTeX-совместимый (хотя бы в каких-то пределах) синтаксис. Вроде есть сайты и движки, которых кормишь LaTeX-разметкой, а они возвращают ей соответствующий pdf-текст (или картинку), отформатированный по всем правилам. Даже писать ничего не надо — достаточно внедрить. LaTeX, конечно, — ещё тот костыль, но по факту это всеминый стандарт для печати, и такого кретинизма, как у web-разметки, у него нет.
Для тех, кто не интересовался: полноценных конвертеров LaTeX↔Web нет. И задача «вот у меня текст в LaTeX, и я хочу сделать так, чтобы оно так же смотрелось в html» почти нерешаемая для сложно сформатированных документов. И, вообще, в web-вёрстке, говорят, есть множество багов, на которые верстальщики попросту молятся, т.к. никто кроме них не знает всех этих костылей, позволяющих причесать текст, чтобы он смотрелся, как надо.
Если забыть про все эти проблемы, то есть же print-формат (кнопка «Печать» на страницах сверху справа). Может быть, как-то можно зафиксировать итоговый вид в печатном виде, а сорс кода-разметки выкинуть? При запросе старых страниц будет выводиться что-то типа print-формата. Ещё лучше — это умение распознавать print-формат обратно в текст с разметкой, но это, наверно, слишком сложная будет задача (хотя распознавалки картинок в текст существуют, и ничего).
Я против принудительного насилия со стороны движка в плане расстановок отступов и прочего, но пусть будет единообразный адекватный стандарт и возможность, когда надо, его принудительно обойти (тот же LaTeX тоже всё расставляет автоматически, но если мне что-то не нравится, я всегда могу опуститься на уровень ниже, применить хак и пофиксить тот элемент, который вызывает проблему).
Вот они как раз не должны. Это практически стандарт, многие движки умеют выводить символы по их UTF-коду, тут сложно что-то сломать. Проблемы могут быть, максимум, там, где это наслаивается на wiki-разметку (всякие индексы, наклонные шрифты и пр.).
комментариев: 11558 документов: 1036 редакций: 4118
Это нереальная задача. Для таких случаев проще и логичнее использовать inline html.