За что я ненавижу XML

Наконец-то я смог сформулировать, за что я ненавижу XML. В применении к книгам, очевидно - прочие использования этого незаконнорождённого отпрыска пьяной макаки и запаршивевшего верблюда меня волнуют мало, хотя встречаться с конфигами, где ради одного значения надо написать четыре вложенных тега по полсотни символов тоже удовольствия мало. Да и типичный вебсайт по сути своей от книги мало отличается, а чисто флэшевые поделки лично мне не интересны.
Так вот.
Книга - это текст.
Текст в книге главное.
Есть ещё всякие рющечки, шрифты и прочие выделения, ссылки, сноски, заголовки и прочее. Я прекрасно это всё знаю, ценю и использую. Но всё-таки текст важнее разметки. Если испортится разметка - книга остаётся всё той же книгой, её можно будет читать, пусть чуть менее удобнее. Мысль автора не исказится. Если же испорчен текст ценой сохранения правильности разметки - книга испорчена.
Ещё раз. Книга это текст c разметкой, причём текст первичен. Кажется, простая и очевидная мысль. Но не для всех. Во всяком случае не для придумщиков XML, чтоб им побыстрее переродиться престарелыми червями.
В XML считается, что главное - разметка. Если среди мегабайта текста попадётся отдельно стоящий &, или там <, любой парсер сочтёт это куском тэга. Хотя на тэг это ни разу не похоже. И текст будет испорчен.
Это абсолютно бредовый подход. За разметку можно принимать только то, что точно разметка. Встретили <p> - ну ладно, сочтём за тэг. Хотя сама по себе идея метить метаинформацию распространённым символами, да ещё и несколькими, запрещая их использовать Тексту, достойна пожизненной кастрации.

Отв: За что я ненавижу XML

Изображение пользователя elena-hannover.

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

Отв: За что я ненавижу XML

Изображение пользователя larin.

elena-hannover wrote:

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

Не надо в петлю.
Помимо гадкого XML в мире есть масса приятных вещей.

Отв: За что я ненавижу XML

Изображение пользователя Ulenspiegel.

Конечно. Гадкий SGML, например :) По поводу subj - кроме DOMовских парсеров, которые, действительно, пытаются засосать весь текст одним куском и умирают при нарушении структуры, есть еще и SAX2-парсеры. Они позволяют определить пользовательские callback'и при некоторых распространенных ошибках (непарный тег, например). Как бонус- менее ресурсоемки. Как штраф - внутренней организацией разобранного текста приходится заниматься самому.

Отв: За что я ненавижу XML

Изображение пользователя larin.

Ulenspiegel wrote:

Конечно. Гадкий SGML, например :) По поводу subj - кроме DOMовских парсеров, которые, действительно, пытаются засосать весь текст одним куском и умирают при нарушении структуры, есть еще и SAX2-парсеры. Они позволяют определить пользовательские callback'и при некоторых распространенных ошибках (непарный тег, например). Как бонус- менее ресурсоемки. Как штраф - внутренней организацией разобранного текста приходится заниматься самому.

Это счастье можно прикрутить к пыху, и если да - то как?
Я бы парсер переписал.

Отв: За что я ненавижу XML

Изображение пользователя Ulenspiegel.

Простым образом - нет. Поскольку PHP - интерпретатор, и передать в .so-шку адрес-функции-которую-надо-позвать - проблематично. Есть метода написания на C/C++ расширений для PHP, которая гарантированно позволяет манипулировать переменными, определенными внутри PHP. Позволяет ли она позвать PHP-процедуру - ответить не готов. Если описать требования к такому расширению (например, на входе - имя XML-файла, реакция на незакрытый тег выбирается по содержимому переменной UnclosedTag_Bold, результаты парсинга выводятся в file stream) - готов заняться, но не с очень высоким быстродействием :(

Отв: За что я ненавижу XML

Ulenspiegel wrote:

Если описать требования к такому расширению (например, на входе - имя XML-файла, реакция на незакрытый тег выбирается по содержимому переменной UnclosedTag_Bold, результаты парсинга выводятся в file stream) - готов заняться, но не с очень высоким быстродействием :(

С той же оговоркой готов присоединиться.

ЗЫ: По тем же причинам не люблю fb2 (как разновидность xml).
Source в LaTeX с последующей генераций pdf (размер шрифта по вкусу) рулит (для просмотра можно генерить html)! :)

Отв: За что я ненавижу XML

Изображение пользователя Малолетний Д..

larin wrote:
Ulenspiegel wrote:

Конечно. Гадкий SGML, например :) По поводу subj - кроме DOMовских парсеров, которые, действительно, пытаются засосать весь текст одним куском и умирают при нарушении структуры, есть еще и SAX2-парсеры. Они позволяют определить пользовательские callback'и при некоторых распространенных ошибках (непарный тег, например). Как бонус- менее ресурсоемки. Как штраф - внутренней организацией разобранного текста приходится заниматься самому.

Это счастье можно прикрутить к пыху, и если да - то как?
Я бы парсер переписал.
В parser.inc разве не SAX?

Отв: За что я ненавижу XML

Изображение пользователя Ulenspiegel.

Малолетний Д. wrote:

В parser.inc разве не SAX?

Х.З. Либо не видел, либо не помню. Ссылка есть ?

Отв: За что я ненавижу XML

Изображение пользователя Малолетний Д..

Ulenspiegel wrote:
Малолетний Д. wrote:

В parser.inc разве не SAX?

Х.З. Либо не видел, либо не помню. Ссылка есть ?

http://github.com/larin/librusec/blob/master/parser.inc

Отв: За что я ненавижу XML

Изображение пользователя Ulenspiegel.

Угу. Он самый. Хорошая новость - адреса PHP-callback'ов передавать в расширение можно. Плохая - в используемом расширении (обертка expat для PHP, James'а Clark) callback'ов для обработчиков ошибок не обнаружено.
Утверждается, что в 5м PHP встроено расширение для работы с XML, написанное именно вокруг libxml2, с дивной производительностью/надежностью. Проверить сейчас не могу, при хорошем раскладе - завтра утром. Если руки у кого доберутся раньше - отпишитесь, плиз.

2Larin:
1) на сервере какая версия PHP ?
2) кроме плохого самочуствия при невалидном документе, какие ещё недостатки у парсера ?

Отв: За что я ненавижу XML

Изображение пользователя larin.

Ulenspiegel wrote:

1) на сервере какая версия PHP ?
2) кроме плохого самочуствия при невалидном документе, какие ещё недостатки у парсера ?

1. 5.2.11
2. Это главное.

Отв: За что я ненавижу XML

Изображение пользователя Ulenspiegel.

Понял. Ссылку на невалидный документ, на котором падает, можно попросить ?

Отв: За что я ненавижу XML

А если собственно текст положить в
<![CDATA[...]]>
будет все спец. символы игнорировать с остальным согласен.

Отв: За что я ненавижу XML

Изображение пользователя BorisR.

Иногда думается, что... помимо гадкого XML в мире есть масса ещё более гадких вещей.

Отв: За что я ненавижу XML

Изображение пользователя СерыйМыш.

МОТОРОЛЛЕР НЕ МОЙ! Я ПРОСТО РАЗМЕСТИЛ ОБЪЯВУ!

Отв: За что я ненавижу XML

Изображение пользователя BorisR.

Иногда думается, что... помимо гадкого XML в мире есть масса ещё более гадких вещей.

Отв: За что я ненавижу XML

Изображение пользователя СерыйМыш.

МОТОРОЛЛЕР НЕ МОЙ! Я ПРОСТО РАЗМЕСТИЛ ОБЪЯВУ!

Отв: За что я ненавижу XML

Изображение пользователя polarman.

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

Отв: За что я ненавижу XML

Изображение пользователя larin.

polarman wrote:

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

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

Отв: За что я ненавижу XML

Изображение пользователя polarman.

Так что, нужна отдельная кодировка? Я не программёр, с XML знакомился "в плане общего развития", но, как я понимаю, создать дополнительный набор символов не такая уж большая проблема - не было в изначальной винде русской кодировки, теперь есть. А в ранешние времена, помнится, русификаторы писались... может и здесь некое подобие "русификатора" надо?
Или сама концепция разметки длинной цепочкой вложенных тэгов не меньше раздражает? Тогда, наверное, вопрос к лингвистам, к тем, кто структурами языков занимается...
В таком разрезе проблема-то получается значительно шире, нежели использование XML при создании fb2... ИМХО.
Все это, конечно, рассуждения дилетанта... :)

Отв: За что я ненавижу XML

Изображение пользователя larin.

polarman wrote:

Так что, нужна отдельная кодировка? Я не программёр, с XML знакомился "в плане общего развития", но, как я понимаю, создать дополнительный набор символов не такая уж большая проблема - не было в изначальной винде русской кодировки, теперь есть. А в ранешние времена, помнится, русификаторы писались... может и здесь некое подобие "русификатора" надо?
Или сама концепция разметки длинной цепочкой вложенных тэгов не меньше раздражает? Тогда, наверное, вопрос к лингвистам, к тем, кто структурами языков занимается...
В таком разрезе проблема-то получается значительно шире, нежели использование XML при создании fb2... ИМХО.
Все это, конечно, рассуждения дилетанта... :)

Нужно думать головой при создании стандартов. К сожалению, в компьютерной индустрии это не принято.
Я, к примеру, не могу понять, почему у обычного ПК вместо двух видов подключения прочих устройств, проводного с питанием и беспроводного, грубо говоря USB и WIFI, используется больше десятка - PS2, LPT, COM, USB, FireWare, VGA, DVI, WIFI, BlueTooth, infrared, ... - да что там, каждый может пересчитать самостоятельно. И все убогие.

Казалось бы, возьми ты в качестве спецсимвола нечто, что в человеческих текстах не встречается, или встречается крайне редко. Да хоть [[, или там {[{, если не хватает мозгов на какой-нибудь спецсимвол.
Нет, надо забанить несколько нужных знаков. А потом доблестно их эскейпить туда-сюда.

Отв: За что я ненавижу XML

Изображение пользователя BRMAIL.

Цитата:

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

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

Отв: За что я ненавижу XML

Изображение пользователя larin.

BRMAIL wrote:
Цитата:

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

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

Какая шкала времени, ты о чём?
Специально залез под стол посчитать.
На обычном десктопе, с которого я сейчас пишу, на задней стенке 15 разъёмов. Из них 6 USB, взамозаменяемых, все остальные разные. Каждое устройство можно пихнуть только в специальный разъём. Это только проводных, с беспроводными тот же бардак. Да и внутри ещё шесть, SATA+ATA+floppy, три пары разных разъёмов для одной и той же функции.
А должно быть несколько одинаковых, с парой медных контактов для питания + оптика для данных, в один из которых воткнут монитор, и на мониторе ещё несколько таких же, куда вотнута всякая периферия, которая ближе к монитору, чем к CPU. И это не телепортация, это всё уже давно изобретено и работает. Ещё c прошолого тысячелетия.
Пароход, самолёт и автомобиль выполняют разные функции и не взамозаменяемые.
А PS2, ATA, SATA, FireWare, USB и т.п - одну и ту же.

Отв: За что я ненавижу XML

Изображение пользователя BRMAIL.

я не знаю что у вас стоит под столом и какие разьемы сзади на корпусе компьютера, но могу предположить что там принтерный порт, пару СОМ портов, порт PS2 для мыши и клавы, возможно еше fireware и esta
А теперь проделайте домашнюю работу - пойдите на гугл, и убедитесь, что компорт и lpt порт появились задолго до usb , то же самое касается и PS2 для мыши и клавы - не было еше ЮСБ в те времена когда появился этот стандарт. И теперь пока он окончательно не вымрет сам по себе - его будут продолжать ставить на матери, чтоб не потерять покупателей которые взяли бы такой продукт будь у него этот разьем.
Та же картина с IDE /SATA - ничего такого что было бы револьюционно новым и приятным для пользователя (обычного пользователя лаптопа или десктопа) в новом SATA нету. Однако у меня в сервере счас 6 винтов по 250 гиг IDE. Ну какой смысл их выбрасывать если они вполне себе работают и не думают даже ломаться, а половина из них еще на гарантии (были времена с 5-ти летней гарантией) поэтому два года назад пересобирая сервер я взял в него мать которая умеет оба.
Так что пока телепорт не изобрели - будете ездить на параходах и автомащинах. А когда изобретут - будете продолжать ездить на них, пока телепорт не вытеснит эти пережитки прошлого

Отв: За что я ненавижу XML

В современных материнках уже практически не бывает LPT. А жаль.

Отв: За что я ненавижу XML

polarman wrote:

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

Не совсем так. Убираются только группы из пустых строк, если была одна пустая строка, то она так и останется, а вот если было 2 или более пустых строк, то FBE после скрипта "Генеральная уборка" оставит только 1 пустую строку.
IMHO, совершенно правильно, не к чему плодить много лишних <empty-line/>
на понимание текста не повлияет, одна там пустая строка или две, лишь бы была.

Отв: За что я ненавижу XML

Изображение пользователя polarman.

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

Отв: За что я ненавижу XML

polarman wrote:

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

ну дык... то ведь конвертер
виноват, а я-то про редактор.
FBE не конвертит, а редактирует.
Если в редакторе конвертили, то может это был БукДизайнер или ФикшенБукДизайнер но не ФикшенБукЭдитор.

Отв: За что я ненавижу XML

Изображение пользователя Рыжий Тигра.

Zadd > FBE не конвертит, а редактирует.
"А вот тут-то мы вас и попгавим!" (L) :)
FBE2 принимает копипаст (по крайней мере, из браузеров и WordViewer'а) с сохранением жирностей/курсивностей. Очень удобно, сам только таким способом и конвертирую. Правда, пустые строки тоже теряет - приходится дорабатывать руками. :(

Отв: За что я ненавижу XML

Изображение пользователя larin.

Zadd wrote:

IMHO, совершенно правильно, не к чему плодить много лишних <empty-line/>
на понимание текста не повлияет, одна там пустая строка или две, лишь бы была.

IMHO, заменить привычный, общеупотребительный двухбуквенный тег BR на десятибуквенный empty-line с ровно тем же функционалом, бессмысленно и беспощадно ухудшив тем совместимость с html, мог только психически альтернативный разработчик.

Отв: За что я ненавижу XML

Изображение пользователя Рыжий Тигра.

larin wrote:

заменить привычный, общеупотребительный двухбуквенный тег BR на десятибуквенный empty-line с ровно тем же функционалом, бессмысленно и беспощадно ухудшив тем совместимость с html,

А при чём тут совместимость? BR несовместим с XML уже тем, что не является самозакрывающим, т.е. что его "совместимость" с "empty-line/", что с "br/" - однофигственно. Зато, что важно для тех, кто html'а не знает, empty-line, strong, emphasis, subtitle и т.д. хорошо читаются глазами (т.е. в качестве форматтера может выступать собственное воображение :) ) - я, например, первые три дня читал fb2-книги именно так... :)

Отв: За что я ненавижу XML

Изображение пользователя СерыйМыш.

ога! вот оно как! (*радостно прыгает на одной ноге)
не одного меня тошнит от xml.
какой хороший стимул возобновить занятия с форматом nfb.
(*ушел обдумывать план конвертации всех книг в простой текстовый формат)

Отв: За что я ненавижу XML

Изображение пользователя Рыжий Тигра.

СерыйМыш wrote:

хороший стимул возобновить занятия с форматом nfb.

+65537! (факториал то бишь) :)

Отв: За что я ненавижу XML

Изображение пользователя oldvagrant.

Вначале было Слово. И Слово было - 2 байта...
И это нам аукается аномально долго.

Отв: За что я ненавижу XML

oldvagrant wrote:

Вначале было Слово. И Слово было - 2 байта...
И это нам аукается аномально долго.

Вообще-то слово было 4 байта, а 2 байта называлось halfword т.е. полуслово. Потом пришла эра персональных компьютеров, сначала 8-битных(у них слово было байтом 8 бит), потом персоналки c 16-битным словом(2 байта), потом стали понимать 32-разрядные(4 байта), а потом 64-разрядные (8 байтов), но что сейчас называется словом, не в курсе, наверно, так и осталось 2 байта, чтобы сохранить совместимость со старыми программами(проще ввести новые термины DWORD, QWORD и т.д., чем менять ассемблер)

Отв: За что я ненавижу XML

в начале байтом называлась группа бит от 5 до 9, у Кнута виртуальная машина с байтом в 6 бит.
16-битные машины появились до персоналок - PDP-11 (она же СМ-4), например. И именно на них и появилось слово = 16 бит.

Отв: За что я ненавижу XML

mihsan wrote:

в начале байтом называлась группа бит от 5 до 9, у Кнута виртуальная машина с байтом в 6 бит.
16-битные машины появились до персоналок - PDP-11 (она же СМ-4), например. И именно на них и появилось слово = 16 бит.

про процессоры с не 8битным байтом знаю, также еще был процессор CYBER, у которого байт=слово=60 бит.
Кроме того, есть еще НЕбитовые процессоры, у которых 1разряд не двоичный, а троичный (принимает 3 значения: -1/0/1, очень удобно для параллельных вычислений на суперкомпьютерах(не в курсе, чем именно это удобнее, но читал, что для параллельных вычислений на многопроцессорных суперкомпьютерах это удобнее, чем двоичный бит))
А слово из 4 байт применялось на компьютерах IBM, с которых у нас скоммуниздили серию компьютеров ЕС.

Отв: За что я ненавижу XML

Изображение пользователя СерыйМыш.

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

Отв: За что я ненавижу XML

Изображение пользователя larin.

СерыйМыш wrote:

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

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

Отв: За что я ненавижу XML

Илья, это подсознание бунтует. :)
Ларин ненавидит xml, xml=fb2, fb2=Грибов, Грибов - копираст, ненавидит Либрусек и Ларина.
Ларин ненавидит xml... :)

Отв: За что я ненавижу XML

Изображение пользователя larin.

skiv wrote:

Илья, это подсознание бунтует. :)
Ларин ненавидит xml, xml=fb2, fb2=Грибов, Грибов - копираст, ненавидит Либрусек и Ларина.
Ларин ненавидит xml... :)

Ларин сомневается в xml уже третий год - http://rusec.livejournal.com/11740.html
Грибов тогда про Либрусек и не знал, какая уж там ненависть.
Да и не он XML придумывал, он портил с уже готовой базы.

Отв: За что я ненавижу XML

Портил - это метко сказано.

Отв: За что я ненавижу XML

Изображение пользователя Lord KiRon.

Бедный Грибов, как его, простите "обосрали", и кто вечно молчащий Ларин... это война ! :)

Отв: За что я ненавижу XML

Изображение пользователя larin.

Lord KiRon wrote:

Бедный Грибов, как его, простите "обосрали", и кто вечно молчащий Ларин... это война ! :)

Грибов создал хоть какой-то стандарт.
Остальные не сделали вообще ничего. В том числе я.
У меня были разработки для личного пользования, но мне даже в голову не пришло довести их до публичного релиза.
А жаль. Оно было заметно удобнее.
Но винить-то некого, ССЗБ.

Отв: За что я ненавижу XML

Изображение пользователя polarman.

larin wrote:

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

А что, поезд ушел?
PS Я не даром спрашиваю - у меня сканы трех книг на вычитке, не все ж за меня конвертить будут?

Отв: За что я ненавижу XML

Изображение пользователя СерыйМыш.

larin wrote:

[
У меня были разработки для личного пользования, но мне даже в голову не пришло довести их до публичного релиза.
А жаль. Оно было заметно удобнее.
Но винить-то некого, ССЗБ.

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

Отв: За что я ненавижу XML

Изображение пользователя thirteen.

...нормальный жизнеспособный формат.

Вот объясните мне, пожалуйста, чем плох ХТМЛ как формат для электронных книг?

Отв: За что я ненавижу XML

thirteen wrote:

...нормальный жизнеспособный формат.
Вот объясните мне, пожалуйста, чем плох ХТМЛ как формат для электронных книг?

Я этот вопрос второй год задаю. Ответ и ныне там.

Отв: За что я ненавижу XML

pkn wrote:
thirteen wrote:

...нормальный жизнеспособный формат.
Вот объясните мне, пожалуйста, чем плох ХТМЛ как формат для электронных книг?

Я этот вопрос второй год задаю. Ответ и ныне там.

Самостоятельно подумать конечно лен. Диалектика вышла из моды...

Например:
Вас не затруднит привести цитатку из спецификации формата HTML, в которой раскрыта тема классического книжного отображения сносок.

Отв: За что я ненавижу XML

Anarchist wrote:

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

После Вас: приведите такую цитатку из спецификации формата XML.

Anarchist wrote:

Самостоятельно подумать конечно лен.

Нахуй иди, думатель.

Отв: За что я ненавижу XML

pkn wrote:

Нахуй иди, думатель.

Вот ты, думатель, и пиздуй.
Для начала учить определение транскрипции.

Отв: За что я ненавижу XML

Изображение пользователя СерыйМыш.

thirteen wrote:

...нормальный жизнеспособный формат.

Вот объясните мне, пожалуйста, чем плох ХТМЛ как формат для электронных книг?
1. нет возможности явно задать структуру текста - деление на части, главы, разделы и т.д.
2. нет возможности непосредственно обрабатывать сноски.
3. нет возможности задать разные варианты форматирования стихов.
4. нет возможности без дополнительных выкрутасов задать метаинформацию о книге - автор/название/серия/жанр/аннотация/обложка/etc.
5. нет возможности задать особый формат структуры текста - например пьесы, билингвальные книги.
6. ...
7. PROFIT

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

Отв: За что я ненавижу XML

Изображение пользователя ew.

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

Отв: За что я ненавижу XML

Изображение пользователя larin.

ew wrote:

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

В основном в порядке вопля.

Отв: За что я ненавижу XML

Изображение пользователя ew.

larin wrote:

В основном в порядке вопля.

Ну и слава богу, значит, живем пока в fb2 :)

Отв: За что я ненавижу XML

Изображение пользователя thirteen.

larin wrote:

Книга - это текст.
Текст в книге главное.

О чём я и говорил.
Радостное совпадение наших убеждений.

Отв: За что я ненавижу XML

Изображение пользователя СерыйМыш.

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

Отв: За что я ненавижу XML

Изображение пользователя thirteen.

Larin: Книга это текст c разметкой, причём текст первичен. = СерыйМыш: не только текст. но и структура текста.

Именно. Я не совсем точно выразился.

Отв: За что я ненавижу XML

Изображение пользователя BRMAIL.

thirteen wrote:
larin wrote:

Книга - это текст.
Текст в книге главное.

О чём я и говорил.
Радостное совпадение наших убеждений.

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

Отв: За что я ненавижу XML

Изображение пользователя thirteen.

Ну, к примеру, в плэйнтекстовых файлах само собой сложилось выделять сноски квадратными или фигурными скобками, оставляя их прямо в тексте вслед за указателем. Если я не ошибаюсь.
И потом, я прекрасно понимаю, что текст без структуры есть трудночитаемая каша. Но на этом можно было бы остановиться. Так нет, изготовители екниг настаивают навязывать шрифты, их размер и цвет (если хтмл), разбивают книгу на отдельные файлы по главам (епаб и адоб)... я уж не говорю об извращениях, вносимых ретивыми конвертерами. Так что фб2 -- это имхо еще малое и принимаемое зло. Хотя ХТМЛ хватило бы, а для особых случаев есть текс, но это к худлиту вообще не относится, это профессиональная литература.

Отв: За что я ненавижу XML

Изображение пользователя BRMAIL.

ну опять же есди подумать о причинах у того же адоба (сам не люблю эту кампанию, и их pdf формат , но что поделаешь) поступать именно так как они поступают - то уверяю тебя, причины найдутся и очень серьезные, в основе того же pdf лежит язык (формат) разметки документа для печати, и причины при создании формата делать его именно так как было сделано - несомненно были.
Другой разговор, что в настоящий момент я бы не концентрировался на универсальности языка. Скажем возможность встраивать фонты есть и в pdf и в html, но это не мешает вебу эту возможность фактически везде игнорировать. есть стандартные группы фонтов, ими все и верстают и выходит неплохо.
Для формата документа для чтения нужно создавать свой, заточенный под это стандарт. Что и было проделано с fb2 . Да он не идеален, но принимать его надо как данность.

Отв: За что я ненавижу XML

Цитата:

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

Так что же это, как не еще один вариант разметки? Такой же топорный, правда, как и сам plain text :)

Отв: За что я ненавижу XML

Изображение пользователя Ян Злобин.

Что-то много эмоций, а в сухом остатке противопоставление XML и первичности текста. Это как сравнить теплое с мягким. IMHO.

Отв: За что я ненавижу XML

Изображение пользователя Doc 2.

Цитата:

Что-то много эмоций, а в сухом остатке противопоставление XML и первичности текста. Это как сравнить теплое с мягким. IMHO.

Теоретически верно.. а, на практике Ларин прав ИМХО.

Отв: За что я ненавижу XML

Изображение пользователя Doc 2.

larin пишет:

Цитата:

Ещё раз. Книга это текст c разметкой, причём текст первичен. Кажется, простая и очевидная мысль. Но не для всех. Во всяком случае не для придумщиков XML, чтоб им побыстрее переродиться престарелыми червями.

Хорошо как .. красиво и точно...

Отв: За что я ненавижу XML

>Если среди мегабайта текста попадётся отдельно стоящий [...]

Откуда он там взялся? Экранировать надо.

Отв: За что я ненавижу XML

Изображение пользователя СерыйМыш.

никто в здравом уме не станет писать в обычном тексте знаки "<",">" и "&" как &gt, &lt, &amp
ну ни к чему это обычному человеку.
а вот редактор при импорте подобной ереси должен обязательно конвертировать символы и сочетания, которые совпадают со служебными конструкциями, и потенциально могут вызвать проблемы.
при обратной конвертации, соответственно "вернуть взад".
опять "вышли на Дерибасовскую": срыв форматирования - это проблема не столько кривого формата xml, сколько кривых редакторов и валидаторов.

Отв: За что я ненавижу XML

Либо обычный человек™ не должен писать raw код. Либо у редактора должна быть опция «вставить с экранированием». Тогда и проблем не будет. А уж экранировать и обратно проблем у программ быть не должно.

Отв: За что я ненавижу XML

Tenno Seremel wrote:

Либо обычный человек™ не должен писать raw код.

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

Отв: За что я ненавижу XML

(см.выше) Вставлять с экранированием.

Отв: За что я ненавижу XML

Изображение пользователя ew.

СерыйМыш wrote:

...опять "вышли на Дерибасовскую": срыв форматирования - это проблема не столько кривого формата xml, сколько кривых редакторов и валидаторов.

Ага, и я хотел сказать - но постеснялся: мало ли чего не понимаю.
Вообще-то обычное дело: Распознаешь текст, и в нем полно угловых скобок. Почему any2fb2 их не убирает, а что-то там такое химичит, что FBE и читалки потом вовсе вырубаются? Загадка... Приходится вручную выискивать "теги" вроде <.> и вычищать. А виноват почему-то XML...

Отв: За что я ненавижу XML

Изображение пользователя polarman.

дубль

Отв: За что я ненавижу XML

Изображение пользователя polarman.

СерыйМыш писал:
никто в здравом уме не станет писать в обычном тексте знаки "<",">" и "&" как &gt, &lt, &amp/quote]

Прям сейчас вычитываю сканы Долинин "История, одетая в роман" (биография Вальтера Скотта). На каждой странице <...>
Что будет с текстом при конвертации?

Отв: За что я ненавижу XML

Изображение пользователя s_Sergius.

polarman wrote:

Прям сейчас вычитываю сканы Долинин "История, одетая в роман" (биография Вальтера Скотта). На каждой странице <...>
Что будет с текстом при конвертации?

Смотря чем конвертировать. Не надо использовать Any2fb2.
А вот Doc2fb (wml2fb.xsl) или ExportXML.dot сделают всё корректно. Ну я имею в виду угловые скобочки. Description-то никто сам не заполнит.

Отв: За что я ненавижу XML

Изображение пользователя oldvagrant.

СерыйМыш wrote:

... срыв форматирования - это проблема не столько кривого формата xml, сколько кривых редакторов и валидаторов.

Это можно сказать про любой, сколь угодно кривой формат. И при любом кривом формате можно сделать, пусть жутко сложный, редактор, который станет работать корректно. Только зачем делать формат, который требует сложных редакторов?

И я бы тоже хотел пристрелить человека, из-за которого приходится писать <emphasis>и</emphasis> .

Отв: За что я ненавижу XML

Единственный нормальный исходный вид _книг_ любого содержания, это LaTeX. Он более всего похож на руками написанный текст. (и никакого SGML не надо, все тоже самое, для стандартности можно наобъявлять средствами самого LaTeX)

Для рефлов-представления конвертируется в HTML. Для читалок/распечатки генерится PDF под заказанный размер листа, читалок немного на самом деле (вернее немного экранов :).

Попытка написать свой язык разметки закончится написанием своего TeX. :)

Различные журналы и чертежи это djvu.

Отв: За что я ненавижу XML

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

Смеялсо.

Отв: За что я ненавижу XML

Изображение пользователя BRMAIL.

p2004r wrote:

Для рефлов-представления конвертируется в HTML. Для читалок/распечатки генерится PDF под заказанный размер листа, читалок немного на самом деле (вернее немного экранов :)

PDF для читалок это страшное зло. Как и специальная конвертация перед залитием куда то в портативный девайс. И того и другого надо избегать как черт ладана. Причины первого "избегания" - нет ничего такого что позволяло бы автору документа навязывать читателю размер шрифта, стиль оформления итд. PDF делает это безусловно (жри гад читатель что дано, ну можешь масштаб увеличить, но если по ширине не лезет - сам дурак)
Конвертация ПЕРЕД заливкой - опять таки древний анохронизм чистой воды. Опомнитесь, 2010 год уже на носу. В обычной читалке стоит процессор, аналог которому по производительности 10 лет назад можно было не в каждом дескотопе найти. Все это должно делаться на автомате в момент заливки, а еше лучше вообще не делаться. Процесс парсинга документа для современных аппаратных средств - плевое дело, и то что не может быть выполнено сходу ( скажем, чтоб понять сколько страниц должно быть показано у документа он должен быть весь распарсан, а документ может быть очень большой - возврашаемся к причинам почему другие форматы "любят" разбитые на части-главы документы) должно быть выполнено в фоне. Вопрос грамотного составления формата - это просто вопрос времени. Если кто то этим будет заниматься. И за fb2 Грибову мы все должны сказать спасибо - какой никакой но формат и стандарт дефакто

Отв: За что я ненавижу XML

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

Читатель может выбрать с каким стилем ему собрать pdf из LaTeX исходника. Если выставлены нормальные пенальти, то никакого вмешательства в верстку книги "в стиле и возможностям" fb2 уж точно нет.

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

Если надо иметь именно моментально перемасштабируемый формат, то для этого есть конвертатор в HTML. Смена стиля вообще не вопрос. Движки есть готовые и свободные.
Поскольку книга при этом "реадонли", то и нужен исходник в LaTeX.

Отв: За что я ненавижу XML

Изображение пользователя Рыжий Тигра.

p2004r wrote:

Нет проблем из библиотеки забрать версию для своего размера экрана.

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

Отв: За что я ненавижу XML

что собственно понимается под словом _сверстать_ pdf для читалки?

Пользоваться LaTeX точно приходилось? Художественную книгу в руках держал?

Сколько разметки в книге будет точно представляешь?

А то у меня одни вопросы понимаешь.

Отв: За что я ненавижу XML

Изображение пользователя Рыжий Тигра.

p2004r wrote:

что собственно понимается под словом _сверстать_ pdf для читалки?

Нуу, насколько я помню, процесс размещения текста на странице называется "вёрстка". Для каждой комбинации гарнитура-кегль-межстрочное эту операцию надо проделывать заново.

p2004r wrote:

Пользоваться LaTeX точно приходилось?

Ни разу.

Отв: За что я ненавижу XML

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

Или будем считать сколько пустых страниц будет в файле для показа на экране ? :)

Движок ТеХ все равно самое аккуратное и мощное что есть.

Отв: За что я ненавижу XML

Изображение пользователя Рыжий Тигра.

p2004r wrote:

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

Не уловил: один .pdf, "самонастраивающийся" под конкретный экран и желаемый кегль/гарнитуру, с автоматическим подавлением "туннелей". "@лядских строк", матюкоподобных переносов и прочих некузявостей? Классно! Можешь показать на примере? На чём-ньдь сравнительно небольшом - рассказик этак на пару десяток кил текста, ОК?
А, кстати, какой софт эти фишки при показе поддерживает? Хотелось бы, чтобы его можно было запустить на LBook V3, но под него всё надо дорабатывать напильником, т.е. опен-сорс предпочтительнее.

Отв: За что я ненавижу XML

Изображение пользователя arteume.

Запасаюсь попкорном;)

В свою очередь, подброшу в огонь свои 5 копеек.
Книга - не только текст, но и иллюстрации, это касается как специальной литературы так и художки. Тут недавно кто-то выложил книгу по сценическому фехтованию в тхт. Книга неплохая, но без иллюстраций она врядли представляет большую ценность.
С другой стороны есть формат джвю, который, ИМХО, намного лучше например пдф (ожидаю большую порцию джвю-срача в комментах). И лично мне этот формат импонирует намного больше фб2 или док/ртф. Он сохраняет и иллюстрации и позволяет прочитать текст (даже без окр-слоя).

Отв: За что я ненавижу XML

Изображение пользователя oldvagrant.

arteume wrote:

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

Кто-ж возразит против djvu? Другое дело, что в последнее время, к сожалению, все чаще встречаются pdf и djvu с распознанным слоем. Народ тупо запускает распознавание даже в книгах с формулами и изысками текста, и в многоязычных книгах. В результате получаются напрочь загубленные файлы. :(

Отв: За что я ненавижу XML

oldvagrant wrote:

Кто-ж возразит против djvu? Другое дело, что в последнее время, к сожалению, все чаще встречаются pdf и djvu с распознанным слоем. Народ тупо запускает распознавание даже в книгах с формулами и изысками текста, и в многоязычных книгах. В результате получаются напрочь загубленные файлы. :(

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

Отв: За что я ненавижу XML

Изображение пользователя oldvagrant.

maslm wrote:

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

Просто для этого нужно сделать явное распознавание скана. А это большое дело. (подумав) Для книжки, для которой актуален pdf, особенно большое дело. Но зато есть функция в Adobe Acrobat, которая делает распознание рисуночного pdf-файла автоматом, не отягощая юзера раздумьями. Да и в FR можно такую же фигню сделать умеючи-то.:)

Отв: За что я ненавижу XML

Изображение пользователя larin.

oldvagrant wrote:

Кто-ж возразит против djvu?

Я возражу.
Формат, в котором не предусмотрена информация об авторах, переводчиках, сериалах и т.п, для библиотеки непригоден.

Отв: За что я ненавижу XML

Изображение пользователя oldvagrant.

larin wrote:

Формат, в котором не предусмотрена информация об авторах, переводчиках, сериалах и т.п, для библиотеки непригоден.

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

Отв: За что я ненавижу XML

Изображение пользователя larin.

oldvagrant wrote:

А информации об "авторах, переводчиках, сериалах и т.п" в djvu-файле ровно столько-же, сколько в бумажной книге.

С точки зрения скрипта - никакой там информации нет и как ёё получить непонятно.
Fb2 потому и любим библиотекарями, что там это всё легкодоступно.

Отв: За что я ненавижу XML

Изображение пользователя oldvagrant.

larin wrote:

Fb2 потому и любим библиотекарями, что там это всё легкодоступно.

Ах это, братцы, о другом.:)
Любим библиотекарями. Хм. Это эвфемизм? Типа: яростно любим. :)
Так вы ж вроде преодолели недостаток путем добавки файла описания?

Отв: За что я ненавижу XML

Изображение пользователя larin.

oldvagrant wrote:

Так вы ж вроде преодолели недостаток путем добавки файла описания?

костыль.

Отв: За что я ненавижу XML

Annotations
Every DjVu image optionally includes so-called annotation chunks. The annotation chunk is often used to
define hyper-links to other document pages or to arbitrary web pages. Annotation chunks can also be used
for other purposes such as setting the initial viewing mode of a page, defining highlighted zones, or
storing arbitrary meta-data about the page or the document.

Hidden text
Every DjVu image optionally includes a hidden text layer that associated graphical features with the cor‐
responding text. The hidden text layer is usually generated by running an Optical Character Recognition
software. This textual information provides for indexing DjVu documents and copying/pasting text from
DjVu page images.

djvutoxml(1), djvuxmlparser(1)
Command line tools to edit DjVu metadata as XML files.

Files produced by djvutoxml can then be modified using either a text editor or a XML editor. Program
djvuxmlparser parses the XML file inputxmlfile and modifies the metadata of the DjVu files referenced by
the OBJECT elements.

разве нельзя туда писать все что угодно?

Отв: За что я ненавижу XML

Изображение пользователя vladk.

p2004r wrote:

разве нельзя туда писать все что угодно?

Насколько я разобрался в формате DJVU - нет, "все что угодно" - нельзя. По крайней мере - не положено.

Отв: За что я ненавижу XML

а насколько разобрался я, в METADATA помещают пары ключ-значение. К этой информации имеет доступ просмотрщик (например djview4 "вид->метаданные").

Отв: За что я ненавижу XML

oldvagrant wrote:
arteume wrote:

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

Кто-ж возразит против djvu? Другое дело, что в последнее время, к сожалению, все чаще встречаются pdf и djvu с распознанным слоем. Народ тупо запускает распознавание даже в книгах с формулами и изысками текста, и в многоязычных книгах. В результате получаются напрочь загубленные файлы. :(

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

Отв: За что я ненавижу XML

Изображение пользователя oldvagrant.

p2004r wrote:
oldvagrant wrote:

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

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

Я занесу Ваш ник в белый список святых людей :), если Вы расскажете как это сделать.
Сейчас передо мной лежит 87-ми МБ-байтный pdf-файл книги, в которой формулы "распознаны" и заменены текстом со всякими "г" вместо "r" и "т" вместо "m" и т.п. Как понимаю я, исходный растровый слой в книге в распознанных местах теперь отсутствует. Как это можно исправить?

Отв: За что я ненавижу XML

arteume wrote:

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

О да :)))
Для начала вспомню, что 2007-й охфис... хреновато читает старые rtf-файлы.
Про doc следовало бы сказать, что надо сразу отстреливать, но я приведу другой пример: видел я распечатанный из doc'а набор инструкций по менеджменту ка[к]чества... В оригинале там должно было быть достаточно много картинок. В распечатанном экземпляре иллюстраций адекватного качестве на было.
Это к приспособленности формата doc для отображения графики.

ЗЫ: Читайте классиков!
Говорят, живёт на свете Дональд Кнут
Доктор Кнут, поверьте дети, страшно крут...

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

Отв: За что я ненавижу XML

перевод иллюстрации в векторный формат позволяет ее автоматом упаковывать в размер страницы вывода.

Трассировщиков просто куча и весть секрет качественного перевода сначала "раздуть" изображение.

Отв: За что я ненавижу XML

Изображение пользователя Рыжий Тигра.

p2004r wrote:

перевод иллюстрации в векторный формат

Опять же, делись подробностями! Очень надо! А то я занимаюсь сканом всего пару месяцев, но уже задолбался чуть ли не для каждой картинки вручную подбирать минимально изгаживающие её параметры ресайза. :(

Отв: За что я ненавижу XML

Сдается мне - это скорее недостатки редакторов FB2, чем формата xml или fb2.

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

Понимать, что тег тут может быть или не может должен не парсер, а редактор. А вот, то что на практике проще всего в обычном редакторе копипастить в структуру fb2 - вот это уже и есть недостатки работы с fb2, но при чем тут сам xml.

Отв: За что я ненавижу XML

Как-бы, безосновательный треп. XML - штука ценная и очень удобная, с помощью которой можно легко описывать любые объекты, причем делая это в удобочитаемом виде. Можно, конечно, битовые флаги выставлять напрямую и вообще забыть про всякие w_char, UTF и прочие удобства. Каждому своё.

Проблема данная сугубо в парсере приложения находится. По спецификации на XML служебные символы должны быть экранированы, если используются, как данные. Использование блока CDATA для каждого чиха не есть хорошо, но вот обрамлять служебные символы банально специальным тегом и написать правило интерпретации для парсера, суть правильно. Получится что-то вроде & и целый один маленький handler для обработки этого тега, который надо будет потом всего-лишь зарегистрировать у парсера. Интерфейсная часть у всех реализаций должна быть унифицирована, так что проблем с этим я не вижу.

Отв: За что я ненавижу XML

Изображение пользователя larin.

Ame wrote:

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

Хорошо теоретикам - они проблем не видят.

Отв: За что я ненавижу XML

larin wrote:
Ame wrote:

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

Хорошо теоретикам - они проблем не видят.

Нет никакой проблемы. Вы просто подняли шум на ровном месте, как мне кажется из-за обычной лени. Напишите handler для парсера или переопределите методы парсера, который Вы используете, или, если ООП для Вас суть лес темный, сделайте пре и пост обработки текста для экранирования/разъэкранирования служебных символов. Вариантов явно больше одного ^_^

Может за Вас написать, если Вы такой немощный?

Отв: За что я ненавижу XML

Ame wrote:

Может за Вас написать, если Вы такой немощный?

А напишите. Во всех читалках, парсерах, редакторах и конвертерах. Коли Вы такой мощный.

Отв: За что я ненавижу XML

Изображение пользователя larin.

Ame wrote:

Может за Вас написать, если Вы такой немощный?

Напишите, буду рад.
Или поправьте имеющийся - http://github.com/larin/librusec/blob/master/parser.inc.

Отв: За что я ненавижу XML

Изображение пользователя Stiver.

larin wrote:

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

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

Отв: За что я ненавижу XML

А попробуйте поменяйте наугад выбранный байт в PDF или DOC файле. Результат почти наверняка будет тот же - не загрузится. Причем в отличие от XML, вручную такой файл уже не починишь.

То есть единственный формат, который БОЛЕЕ помехоустойчив, чем XML - это plain text. Все остальные гораздо, гораздо хуже. А при этом XML абсолютно неограниченно расширяем по семантике, легко читается и пишется на любом языке. Ценой за все это - необходимость escap'ить всего ДВА символа, угловую скобку и амперсанд. С ТеХом или Постскриптом никакого сравнения - вот там действительно черт ногу сломит, любой символ может значить что угодно в зависимости от контекста. А XML создавался как идеальный компромисс простоты и богатства возможностей - и этого идела он достиг. (За исключением DTD - вот за них действительно стоит надавать создателям по ушам; но причины тут больше исторические, слишком резкий разрыв с SGML тогда бы не прокатил.)

Я помню, каким был мир текста до появления XML и Unicode. Я бы не хотел туда возвращаться, спасибо.

Отв: За что я ненавижу XML

Изображение пользователя larin.

kelle wrote:

Я помню, каким был мир текста до появления XML и Unicode. Я бы не хотел туда возвращаться, спасибо.

Не надо никуда возвращаться.
Надо двигаться дальше.

Отв: За что я ненавижу XML

Изображение пользователя SeNS.

larin wrote:

Не надо никуда возвращаться.
Надо двигаться дальше.

А вот куда? Поделись идеями.
На счет XML-я вообще и fb2 в частности я с тобой не согласен. Грибов с Мацневым сделали, для своего времени, достаточно революционную штуку (правда, как водится, революция произошла в одной, отдельно взятой стране). Достоинства схемы fb2 с головой перевешивают все ее недостатки. Количество книг в fb2 и электронных библиотек, базирующихся на fb2, подтверждают это фактически.
Мне не понятно, как и куда двигаться дальше без XML. Понятное дело, схему нужно (и давно нужно) модифицировать и развивать, возможно, файл декомпозировать (как в epub и драфте fb3, хотя там есть свои минусы), но вот что делать без структурной и логической разметки? В лучшем случае, у тебя получится самопальный недо-XML, в худшем - гмм...
Кроме того, любой, самый распрекрасный, в теории, формат, без читалок (софтовых и железных), редакторов, библиотек, каталогизаторов - nothing.

Отв: За что я ненавижу XML

Изображение пользователя Рыжий Тигра.

SeNS wrote:
larin wrote:

Не надо никуда возвращаться.
Надо двигаться дальше.

Мне не понятно, как и куда двигаться дальше без XML. Понятное дело, схему нужно (и давно нужно) модифицировать и развивать, возможно, файл декомпозировать (как в epub и драфте fb3, хотя там есть свои минусы), но вот что делать без структурной и логической разметки? [...] Кроме того, любой, самый распрекрасный, в теории, формат, без читалок (софтовых и железных), редакторов, библиотек, каталогизаторов - nothing.

Посмотри в сторону NFB (про который СерыйМыш упоминал): исходник более "естественный" для глаза, смотрелка весом 50 кил, конвертер из FB2... и это всё было ещё в первой пре-альфе!

Отв: За что я ненавижу XML

Рыжий Тигра wrote:

Посмотри в сторону NFB (про который СерыйМыш упоминал): исходник более "естественный" для глаза, смотрелка весом 50 кил, конвертер из FB2... и это всё было ещё в первой пре-альфе!

Поддерживаю, отличный вроде бы формат.

Но почему то никто здесь (включая автора nfb) не хочет про него вспоминать. Заговор какой-то.

На всякий случай дам ссылочку:

http://lib.rus.ec/node/121665#comment-32133

Отв: За что я ненавижу XML

Изображение пользователя СерыйМыш.

1_абрам wrote:
Рыжий Тигра wrote:

Посмотри в сторону NFB (про который СерыйМыш упоминал): исходник более "естественный" для глаза, смотрелка весом 50 кил, конвертер из FB2... и это всё было ещё в первой пре-альфе!

Поддерживаю, отличный вроде бы формат.
Но почему то никто здесь (включая автора nfb) не хочет про него вспоминать. Заговор какой-то.
никакого заговора нет. есть банальная человеческая лень.
как заметил выше Илья, каждый буратино сам себе враг. вот и я, после года активных и не очень изысканий, дописал спецификацию, начал писать редактор, после чего был благополучно задавлен бытовухой (ремонт в доме), и дебильной работой (1С - зло).

уговариваю себя возобновить работу над nfb, но пока безрезультатно :(

Отв: За что я ненавижу XML

Изображение пользователя СерыйМыш.

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

всего делов-то взяться, и сделать...

Отв: За что я ненавижу XML

kelle wrote:

С ТеХом или Постскриптом никакого сравнения - вот там действительно черт ногу сломит, любой символ может значить что угодно в зависимости от контекста.

Вызывающе неверная информация.
ТеХ прост и логичен, с точки зрения поиска ошибок однозначно приятнее XML.

kelle wrote:

Я помню, каким был мир текста до появления XML и Unicode. Я бы не хотел туда возвращаться, спасибо.

Явление временное.
Только до тех пор, пока лично не придётся ручками поковыряться в [хотя бы средне-сложном] конфиге, написанном для простоты парсинга на XML.

Отв: За что я ненавижу XML

Видите ли, в чем дело...

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

Знаю, что говорю.

Но чем рвать рубашку на груди, приведу один только фактик. Лучшие умы ТеХовского мира много-много лет назад начали работу над LaTeX 3. Результата нет до сих пор и, очевидно, уже не будет. Почему? Да потому что трудно. Слишком замороченная вещь этот ТеХ, чтобы писать на нем нормальный софт. Создание безумного гения, невероятно крутое для своего времени (конец 70-х), но сейчас вся эта его крутота, хитрозаверченность и оптимизированность уже как кость в горле. Все меньше желающих биться головой об стену и решать задачи уровня всесоюзной олимпиады по программированию только для того, чтобы добавить какой-нибудь несчастный счетчик. И интерес постепенно угас. Лучшие умы разбрелись кто куда. Ушел и я, как только появилась возможность более-менее нормально верстать книги в XML.

LaTeX 2e - это последняя остановка, дальше поезд идет в депо. Использоваться в почти неизменном виде он будет еще очень долго, конечно; будут и живые побеги появляться. Но в целом - это труп. Увы.

Что же касается конфигов в XML - так это же просто мечта, если руки из правильного места растут. Не нужно писать свой парсер со своими багами, а нужные значения ищутся одной строчкой на правильном языке XPath. Причем ищутся как угодно - хоть по разделам, хоть по уникальным ID, хоть еще как. Есть, конечно, мазозисты - XPath не знают, бродят по дереву ножками, спотыкаясь и матерясь на каждом шагу, да еще и "парсер" свой собтственный норовят изобрести. Ну так что с такими поделаешь? Просто нужно подождать, пока естественный отбор нас от них избавит.

Отв: За что я ненавижу XML

Изображение пользователя larin.

kelle wrote:

Что же касается конфигов в XML - так это же просто мечта, если руки из правильного места растут. Не нужно писать свой парсер со своими багами, а нужные значения ищутся одной строчкой на правильном языке XPath. Причем ищутся как угодно - хоть по разделам, хоть по уникальным ID, хоть еще как. Есть, конечно, мазозисты - XPath не знают, бродят по дереву ножками, спотыкаясь и матерясь на каждом шагу, да еще и "парсер" свой собтственный норовят изобрести. Ну так что с такими поделаешь? Просто нужно подождать, пока естественный отбор нас от них избавит.

Мечта программиста, пишущего софт. Думать не надо, всё сделает парсер.
И страшный сон пользователя, оный софт конфигурируещего. Продираться через этот весь бред. Текстовым редактором, xml редакторы не завезли.
Если пользователей у программы меньше, чем разработчиков модуля чтения конфигов - прекрасно. Для таких программ XML cамое то. Ваш случай?
А если больше - то как-то без XML лучше. Вот, к примеру, nginx обходится своим форматом, намного более удобным. И мускул обходится. И много кто ешё.

Отв: За что я ненавижу XML

nginx, говорите?

Нус, нагуглил первое попавшееся:

http://brainspl.at/nginx.conf.txt

Вот уж бред так бред! Представляю, сколько надо мануала читать, чтобы это все в подкорку въелось, сколько попыток и матерщины. Конфиг файл - с точками с запятой! со скобками фигурными! с ифами и брейками!!!

Нет уж, спасибо, XML как-то попроще будет, знаете. Даже если я ничего не знаю о программе, по ее XML-конфигу хотя бы ясно, что там есть и что чему подчинено. И исправить его я смогу, _с гарантией_ не поломав, потому что правила синтаксиса XML можно пересчитать по пальцам одной руки. Конфиг нгинкса, наоборот, я при первой попытке исправить почти с гарантией поломаю.

Отв: За что я ненавижу XML

Изображение пользователя larin.

kelle wrote:

Нет уж, спасибо, XML как-то попроще будет, знаете. Даже если я ничего не знаю о программе, по ее XML-конфигу хотя бы ясно, что там есть и что чему подчинено. И исправить его я смогу, _с гарантией_ не поломав, потому что правила синтаксиса XML можно пересчитать по пальцам одной руки. Конфиг нгинкса, наоборот, я при первой попытке исправить почти с гарантией поломаю.

У нас разное представление о простоте.
По мне
server {
  server_name lib.rus.ec;
  location / {
    root /www;
  }
}

выглядит заметно аккуратнее и удобнее, чем

<SERVER>
  <SERVER-NAME>lib.rus.ec</SERVER-NAME>
  <LOCATION mask="/">
    <ROOT>/www</ROOT>
  </LOCATION>
</SERVER>

Сама идея именовать закрывающие скобки, удваивая практически объём текста, который надо читать, достойна всяческого осуждения. Как и паталогическая любовь к лишним кавычкам.
Чем меньше букв надо прочитать - тем быстрее читается и понимается конфиг, тем проще в нём ориентироваться. Даже странно что такие простейшие вещи приходится разжёвывать.
Если для разметки текста XML неудобен в силу некоторых ошибок реализации не слишком удобен, то для конфигов он непригоден категорически. К счастью, большинство серьёзных программистов это понимают и XML-конфиги встречаются нечасто.

Отв: За что я ненавижу XML

Изображение пользователя Рыжий Тигра.

larin wrote:

Сама идея именовать закрывающие скобки, удваивая практически объём текста, который надо читать, достойна всяческого осуждения.

Т.е. основной неприятный момент - отсутствие универсального закрывающего тэга "</>"? Хм... согласен, без него неудобно.

Отв: За что я ненавижу XML

Изображение пользователя larin.

Рыжий Тигра wrote:
larin wrote:

Сама идея именовать закрывающие скобки, удваивая практически объём текста, который надо читать, достойна всяческого осуждения.

Т.е. основной неприятный момент - отсутствие универсального закрывающего тэга "</>"? Хм... согласен, без него неудобно.

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

Отв: За что я ненавижу XML

чушь какая, во первых определитесь: Вы действительно в "голом" TeX верстаете? Или все таки используете LaTeX? Что в нем неудобного то?

Язык TeX и его компилятор _официально_ заморожены. LaTeX развивается, что конкретно в нем не устраивает не прозвучало... я так полагаю не осилили написание стилевых файлов? Ну так не Вы один не осилили.

(La)TeX с стилем "fb2" лучший fb2 :) Ну зачем реализовать все то что уже реализовано? Конвертацией даже некую совместимость можно обеспечить со старыми читалками. Например в графику засовывать все новые изыски которые старые версии формата не поддерживают.

Отв: За что я ненавижу XML

Ха.

Я еще раз повторяю: я верстал ЧУЖИЕ файлы. И там был полный зоопарк: и все виды латехов, и плейн, и АМС, и черт в ступе. Все это заставлять не просто верстаться, а приводить к общему стилю - врагу не пожелаешь. Стилевик у нас свой был, разумеется, но это не спасает, потому что в ТеХе в принципе нет никакой валидации или инкапсуляции, и никто не может помешать автору написать \documentclass и сразу после начать извращаться с голыми регистрами и низкоуровневыми шрифтами. Что большинство из них и делало.

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

Отв: За что я ненавижу XML

Надо было отдавать пользователям свой стилевой файл с примером скелетона статьи в сборник.

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

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

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

Отв: За что я ненавижу XML

Изображение пользователя oldvagrant.

kelle wrote:

То есть единственный формат, который БОЛЕЕ помехоустойчив, чем XML - это plain text. Все остальные гораздо, гораздо хуже.

Вы ломитесь в открытую дверь.

Отв: За что я ненавижу XML

http://www.jrapublish.com/help/Appendices/Embedding_Metadata.htm

Appendix F - Embedding Metadata in DjVu Files

Introduction

JRAPublish™ introduces a standard architecture for embedding metadata in DjVu files.

Metadata is information about documents, stored in individual data fields. These fields define, classify and categorize the documents. Historically these data fields have resided in databases, apart from the documents themselves. JRAPublish™ allows you to embed the data fields directly into DjVu documents, making them portable. In other words, they "take their metadata with them".

Each document format has its own structure for storing embedded metadata. For example, HTML has Metatags and PDF has the DocInfo field dictionary. The DjVu file format lacks a formal metadata structure, but the open architecture of the DjVu format permits us to create our own standard for metadata storage "inside" DjVu files.

The purpose and benefit of storing metadata in the DjVu file structure is that it will not be lost (left behind) during INDIRECT <-> BUNDLED conversions, as well as when downloading a DjVu file with the DjVu web browser plug-in. Because metadata is an integrated part of the DjVu file, the DjVu file is portable, as it "carries" its metadata with it at all times. As a result, for example, a DjVu file can be downloaded from the web and re-indexed on the desktop or on CD and the metadata will still be present. We call this form of metadata storage "Embedded Metadata".

In our standard architecture, metadata fields are stored with tag delimiters. For example, this document in the DjVu format has title, author and date fields that are expressed and stored as:

teg title teg Metadata Storage for DjVu files teg слешь title teg

teg author teg John Smith teg слешь author teg

teg date teg 20011204 teg слешь date teg

Metadata is stored in our standard architecture at three levels: document-level, shared-page-level and page-level.

Отв: За что я ненавижу XML

Изображение пользователя larin.

Ты не умничай, ты пальцем покажи - где мне в при создании djvu жанр вписать?

Отв: За что я ненавижу XML

ну как то так:

djvutoxml файл.djvu > out.xml

в OBJECT первой странице
METADATA value="xxxxxxx" name="xxx"

djvuxmlparser ./out.xml

теперь если запросить djvutoxml файл.djvu в выводе доступны поля заданные нами в первой странице.

Отв: За что я ненавижу XML

есть тонкость (авторы похоже на эти конкретно утилиты забили откровенно :))) )

работает djvused ./djvu_with_xmp_final.djvu -e ' print-meta'
для того что бы увидеть ключи из коммандной строки
Author "Phil Harvey"
Title "DjVu Metadata Sample"
Subject "ExifTool DjVu test image"
Creator "ExifTool"
CreationDate "2008-09-23T12:31:34-04:00"
ModDate "2008-11-11T09:17:10-05:00"
Keywords "ExifTool, Test, DjVu, XMP"
Producer "djvused"
note "Must escape double quotes (\") and backslashes (\\)"
Trapped "Unknown"
annote "Did you get this?"
url "http://owl.phy.queensu.ca/~phil/exiftool/"

а что бы поставить меняют на -e ' set-meta ./metafile' -s

в metafile

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

то есть допустима строчка в ./metafile:
janre tabляция "Детектив"

Отв: За что я ненавижу XML

Изображение пользователя Ulenspiegel.

Где используется ?

Отв: За что я ненавижу XML

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

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".
X
Loading