Формат раздельного хранения plain-text и форматирования?

В Haiku такой формат применяется в программе StyledEdit.

Для чего это может быть нужно? Ведь редактировать отдельно текст нельзя будет, т.к. при редактировании текста с отдельным фалом стиля аля «с x по y - Ж, x-b - К» вся разметка поедет, тегов то нет.

Не очень понятно, зачем это надо.

В html/css у тебя же тоже не отдельно форматирование, а в html семантика, в css — внешний вид. Так же работает, например MarkDown — форматируется семантически (это — заголовок, вот это — список, а вот тут — ссылка), а внешний вид настраивается в читалке, либо отдельным CSS-файлом, используемом при перегонке в html для чтения в браузере.

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

Так что тут как всегда, если хочется очень странного — колхозь свой велосипед (благо это совсем не сложно). Только прежде чем делать, рекомендую десять раз подумать, точно ли оно тебе надо, и нельзя ли обойтись более вменяемым сочетанием MarkDown+CSS.

Посмотри, как в телеге сделано. Там именно такой подход:

{
    "text": "...",
    "entities": [
        {
            "offset": 87,
            "length": 9,
            "type": "textEntityTypeUnderline"
        },
        ...
     ]
}

Roff или Nroff, если они ещё живы.

Там именно такой подход

Это же что-то типа json, а топикстартер хочет файл стиля для plain text.

В смысле?

Готового общепринятого формата нет, по крайней мере я такого не знаю.

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

В какой форме это реализовано через json или ещё как - вообще без разницы, потому что в подходе - это именно то, что озвучено в ОП.

Може ты и прав и это действительно то, что он хочет. Но по сути это уже отдельный формат (json), а не MIME type text/plain + "?".

Спасибо. Действительно, то что нужно. Жаль нет возможности посмотреть серверную часть.

Есть неявный момент с юникодом (как считать смещение позиции в тексте при наличии юникода, смайлов и т.п.), вот так это в телеге решается - https://core.telegram.org/api/entities

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

Да уж ~4600 строк. Смотрю потихонечку ….

Я когда-то немного читал документацию на юникод…

Там же есть куча сюрпризов…

U+202E – разворот

U+0301 – ударение

각 – это один символ, которые задается тремя кодами юникода, а может быть и шесть…

…

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

man вроде работает - как думаешь жывы?

Хотя давно пора закопать и сделать норм формат док-и по умолчанию.

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

Провозился с регулярками, но получилось.

LaTeX. Особенности форматирования задаются классом/стилями.