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

Опубликовано вс, 08/11/2009 - 20:32 пользователем larin

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

Комментарии

Опубликовано ср, 11/11/2009 - 01:28 пользователем Anarchist

pkn написал:
Нахуй иди, думатель.

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

Опубликовано чт, 12/11/2009 - 02:36 пользователем СерыйМыш

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

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


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

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

Опубликовано пн, 09/11/2009 - 02:29 пользователем ew

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

Опубликовано пн, 09/11/2009 - 03:24 пользователем larin

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

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

Опубликовано пн, 09/11/2009 - 03:47 пользователем ew

larin написал:
В основном в порядке вопля.

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

Опубликовано пн, 09/11/2009 - 03:14 пользователем thirteen

larin написал:

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

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

Опубликовано пн, 09/11/2009 - 03:51 пользователем СерыйМыш

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

Опубликовано пн, 09/11/2009 - 04:53 пользователем thirteen

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

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

Опубликовано пн, 09/11/2009 - 03:57 пользователем BRMAIL

thirteen написал:
larin написал:

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

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

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

Опубликовано пн, 09/11/2009 - 05:10 пользователем thirteen

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

Опубликовано ср, 11/11/2009 - 01:02 пользователем BRMAIL

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

Опубликовано ср, 11/11/2009 - 12:52 пользователем kemko

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

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

Опубликовано пн, 09/11/2009 - 04:16 пользователем Ян Злобин

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

Опубликовано пн, 09/11/2009 - 05:31 пользователем Doc 2

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

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

Опубликовано пн, 09/11/2009 - 05:09 пользователем Doc 2

larin пишет:

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

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

Опубликовано пн, 09/11/2009 - 05:28 пользователем Tenno Seremel

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

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

Опубликовано пн, 09/11/2009 - 06:16 пользователем СерыйМыш

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

Опубликовано пн, 09/11/2009 - 06:21 пользователем Tenno Seremel

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

Опубликовано пн, 09/11/2009 - 07:42 пользователем Anarchist

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

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

Опубликовано вт, 10/11/2009 - 07:04 пользователем Tenno Seremel

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

Опубликовано пн, 09/11/2009 - 07:17 пользователем ew

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

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

Опубликовано пн, 09/11/2009 - 13:02 пользователем polarman

дубль

Опубликовано пн, 09/11/2009 - 13:01 пользователем polarman

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

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

Аватар пользователя s_Sergius

Опубликовано пн, 09/11/2009 - 13:16 пользователем s_Sergius

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

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

Опубликовано пн, 09/11/2009 - 18:25 пользователем oldvagrant

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

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

Опубликовано пн, 09/11/2009 - 11:26 пользователем p2004r

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

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

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

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

Опубликовано вт, 10/11/2009 - 19:55 пользователем kelle

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

Смеялсо.

Опубликовано ср, 11/11/2009 - 01:20 пользователем BRMAIL

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

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

Опубликовано ср, 11/11/2009 - 06:03 пользователем p2004r

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

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

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

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

Опубликовано чт, 12/11/2009 - 07:02 пользователем Рыжий Тигра

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

Опубликовано чт, 12/11/2009 - 10:39 пользователем p2004r

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

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

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

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

Опубликовано чт, 12/11/2009 - 11:23 пользователем Рыжий Тигра

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

Опубликовано чт, 12/11/2009 - 17:23 пользователем p2004r

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

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

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

Опубликовано пт, 13/11/2009 - 15:39 пользователем Рыжий Тигра

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

Опубликовано пн, 09/11/2009 - 18:28 пользователем arteume

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

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

Опубликовано пн, 09/11/2009 - 18:37 пользователем oldvagrant

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

Опубликовано пн, 09/11/2009 - 18:51 пользователем maslm

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

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

Опубликовано пн, 09/11/2009 - 19:01 пользователем oldvagrant

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

Опубликовано пн, 09/11/2009 - 18:56 пользователем larin

oldvagrant написал:
Кто-ж возразит против djvu?

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

Опубликовано пн, 09/11/2009 - 19:06 пользователем oldvagrant

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

Опубликовано пн, 09/11/2009 - 19:20 пользователем larin

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

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

Опубликовано пн, 09/11/2009 - 19:26 пользователем oldvagrant

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

Опубликовано пн, 09/11/2009 - 20:22 пользователем larin

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

костыль.

Опубликовано вт, 10/11/2009 - 04:45 пользователем p2004r

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.

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

Опубликовано вт, 10/11/2009 - 04:54 пользователем vladk

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

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

Опубликовано вт, 10/11/2009 - 06:16 пользователем p2004r

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

Опубликовано чт, 12/11/2009 - 10:41 пользователем p2004r

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

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

Опубликовано чт, 12/11/2009 - 17:20 пользователем oldvagrant

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

Опубликовано вт, 10/11/2009 - 02:07 пользователем Anarchist

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

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

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

Опубликовано чт, 12/11/2009 - 10:44 пользователем p2004r

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

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

Страницы
X