Електронни книги – митове и заблуди

[Mandor]

Това е лекцията, която трябваше да бъде изнесена на Булгакон 2014. За съжаление късният час на провеждане доста ограничи времето и се наложи да се съкратят много неща. Това тук е пълният текст.

[Mandor]

1. Семантично форматиране

За да разберете някои от особеностите на електронните книги, трябва да правите ясно разграничение между семантично и крайно форматиране. Какво имам предвид?
Нека разгледаме как работи един средностатистически страньор в едно издателство. Да кажем, че му е възложено да форматира три свързани повести в една книга (например поредицата за Джил Ръката на Лари Нивън) с формат 60×90/16. Отваря той файла, задава размера на страницата и започва: „Титулна страница – 20 пункта, центриран, удебелен. «Първа глава» – а, заглавие, значи 16 пункта, центрирано и удебелено. Следващото? Аха, епиграф; тогава – 11 пункта, наклонен, с ляво поле от 7 см. Основен текст – 12 пункта, нормален шрифт, с отстъп на първия ред от 1,5 см. Тук има акцентирана дума – правим я наклонена…“ и т.н., и т.н. до края на книгата.
След година-две издателството решава да издаде отново същия текст, но вече като три отделни книжки във формат 70×100/32 (колкото старата „Галактика“) – цяла поредица! И нашият страньор отново запретва ръкави – отваря файла, задава новия размер на страницата и започва отначало: „Титулна страница – намаляваме на 16 пункта. «Глава първа» – намаляваме на 14 пункта. Епиграф – намаляваме на 9 пункта, а лявото поле го редуцираме до 3-4 см. Основен текст – намаляваме на 10 пункта. Акцентиран текст – оставяме го наклонен…“ и т.н. и т.н. до края на третата книжка.
Но защо ви занимавам с това? Защото искам да забележите какво всъщност прави нашия страньор: той всеки път определя типа на текста („Това е заглавие; това е епиграф; това е основен текст…“) и в зависимост от резултата прилага фиксиран набор от параметри за крайно форматиране (шрифт, размер, начертание, отстъпи и т.н.). И това е важното – именно определянето типа на текста е единствената дейност във форматирането, която не може да се автоматизира, а трябва да се извърши от човек. Всичко останало може да се извърши автоматично по един или друг начин.
Добре, щом е така, не може ли по някакъв начин веднъж да зададем какъв тип е всеки текст в книгата, която форматираме, а после да асоциираме конкретно крайно форматиране с всеки елемент? Може, чрез т.нар. „стилове“. Всяка нетривиална текстообработваща програма поддържа стилово форматиране, включително и тези от офис-пакетите (Microsoft Office, OpenOffice и вариациите му StarOffice, LibreOffice и пр.). Как работи това? Ами просто когато маркирате текст за форматиране, не му задавате крайните характеристики (шрифт, начертание и пр.), а просто натискате бутончето за съответния стил (основен текст, епиграф, заглавие…), а крайните характеристики ги асоциирате със стила, а не със самия текст. И това е всичко! Ако в последствие ви се наложи да преформатирате текста, просто променяте параметрите на използваните стилове, а не обикаляте из целия текст, за да преработвате всеки параграф поотделно.
Изобщо, семантичното (или стиловото) форматиране има толкова много преимущества, че просто недоумявам защо над 95% от занимаващите се професионално с форматиране не го използват. Някъде около 2007-а бях на работна среща в „БАРД“ и за кратко влязохме в стаичка със страньори. Единият от екраните беше обърнат към вратата, а момичето, работещо на тази машина, форматираше точно както нашия хипотетичен страньор, което просто ме стъписа.
Но нека набързо разгледаме какви са преимуществата на семантичното форматиране:
1. Пести време. И то много. Както пряко, така и косвено. Пряко – защото е много по-бързо да натиснете едно бутонче с името на стила, вместо да отваряте контекстните менюта и да задавате крайните параметри един по един, като рискувате да забравите или объркате нещо. Косвено – ами защото почти никога няма текст, който да е форматиран само веднъж; почти винаги се налага връщане и корекция.
2. Па̀зи от грешки. За да използвате стилово форматиране, се налага да зададете такава структура на текста и крайни параметри на стиловете, които автоматично ще ви пазят от много елементарни грешки, като например да забравите някой от крайните параметри. Или да оставите заглавие от разказ в сборник да остане „сираче“ на края на предишната страница, както е в моето копие на „Тринайсетте цвята на дъгата“ (извинявай, Калине – факт!).
3. Дава възможност за последваща автоматизация. Както вече казахме, определянето типа на текста (семантиката) е единственото, което трябва да се извърши от човек; всичко останало може да се автоматизира в една или друга степен. Ето два примера.
Преди време работих с човек, който трябваше да форматира много сборници с разкази. Изискването беше в горния колонтитул да има два текста: вляво – името на сборника, вдясно – името на текущия разказ. Човекът бавно и упорито си форматираше всичко „на ръка“, включително и колонтитула на всяка страница, като на всичкото отгоре подравняваше двата текста чрез интервали, което не винаги даваше желания резултат. И когато се откри липса на два параграфа в един от разказите, всички последващи колонтитули се разместиха и се наложи да ги поправя един по един. Ако беше използвал стилове, задачата му щеше да се сведе до създаването на един-единствен колонтитул, в който да вмъкне две полета – в лявото да зададе „тук сложѝ текста от стила «Титул»“, в дясното – „тук сложѝ текста от стила «Заглавие»“ и да ги раздели с десен табулатор. И всичко щеше да се получи автоматично!
Втори пример – с нещо масово използвано – съдържание! Защо, за бога, трябва да преписвате на ръка всички заглавия на сборниците си и да изчислявате „на ръка“ на коя страница ще се падне съответния разказ, като рискувате да сбъркате и едното, и другото? Както, впрочем, се получи с алманаха „ФантAstika 2012“ (извинявай, Наско – факт!). Ако се използват стилове, генерирането на съдържание се свежда до три натискания с мишката – от менюто: „вмъкни“ -> „съдържание“ -> „от еди-кое-си ниво“. И това е всичко – получавате съдържание с напълно коректни заглавия и номера на страниците, при това – също стилово форматирани и можете да пренастроите крайните параметри на тези стилове както ви харесва.
Накратко – стиловото форматиране ви дава голяма производителност и голяма надеждност при обработка на текстове.

[Mandor]

2. Първа заблуда

Но стига толкова за хартиените издания; все пак темата е за електронните книги. Каква е връзката с всичко казано досега?
Тук (най-после!) стигаме до първата заблуда при електронните книги – че те се форматират също както хартиените. Аз твърдя обратното: каквото и крайно форматиране да приложите в своите електронни книги, винаги ще се намери четец, на който това форматиране да не работи или дори да направи текста нечитаем. Или казано по друг начин: с всяко крайно форматиране, което приложите във вашите електронни книги, вие губите определен кръг читатели. Или клиенти, ако дейността ви е комерсиална.
Защо? Нека за момент да предположим, че вашата текстообработваща програма ви позволява не само да използвате семантично форматиране, но и да избирате дали изобщо да асоциирате някакво крайно форматиране към стиловете. Да видим кой параметър е безопасно да използвате.
Шрифт? Добре, книга изглежда най-добре със серифен шрифт; да четете на голям екран с безсерифен шрифт е все едно разглеждате уеб-страница – ефектът е доста неприятен (казвам го от опит). Само че ако сложите серифен шрифт, на много eInk устройства от среден клас той ще изглежда размазан – само преди две седмици се опитах да чета такава книга; отказах се на третата страница, защото ме заболяха очите. А на устройства с ниска разделителна способност на екраните (PPC и по-стари телефони) дори не може да се говори за шрифт – там буквите едва се побират в матрица 5×7 точки, какво остава да се мисли за серифи!
Размер на шрифта? Нека разгледаме един обикновен 6-инчов четец с електронно мастило (най-разпространените в момента) и три групи читатели. Аз съм късоглед и предпочитам малък шрифт – около 10 пункта. Жена ми е с нормално зрение и този шрифт й е ситен; нейната книга е настроена на около 12 пункта. Моят шеф има леко далекогледство и е настроил книгата си на 15 пункта – той предпочита да прелиства на всеки 5-10 секунди, вместо да намали шрифта. Тоест – какъвто и размер да изберете, винаги ще има хора, за които той не е подходящ.
Какво друго? Ще сложите акцентирания текст да е с наклонен шрифт? Но, както вече казах, на устройства с ниска разделителна способност на екрана шрифтът е малка матрица от точки и всички опити да се имитира наклонено начертание правят от текста нечитаема съвкупност от точки.
Ще сложите ляво поле на епиграфа? Чел съм такива книги – на моя PPC (и на телефона ми) такъв епиграф се извежда като колонка в десния край на екрана, като на всеки ред има по една дума – просто отвратително!
Помислете и за друго – какво бяло поле ще оставите около текста? За големи екрани ви трябва поне сантиметър, та текстът да не изглежда така, сякаш ще се изсипе от прозореца. За средни екрани (eInk, малки таблети) ви трябва малко поле – 2-3 мм, колкото да се осигури „хигиенна“ зона в краищата на екрана. А за малки екрани (PPC, телефони) всяко поле е загуба на място – просто ще повторите грешката на Microsoft, които се опитаха да въведат собствен формат за електронни книги (.LIT), но четецът им за PPC поставяше по един сантиметър бяло поле от всички страни и на екрана просто не оставаше място за текста в страницата.
И т.н., и т.н. – каквото и крайно форматиране да решите да приложите, винаги ще се намери устройство, на което това форматиране ще приведе текста в нечитаем вид. Затова – при всяка възможност използвайте само семантично форматиране!
Нека видим какво ни предлагат масовите формати за тази цел.

[Mandor]

3. Налични формати

3.1. PDF

С този формат са свързани някои от големите заблуди при електронните книги. И първата е, че това е формат за електронни книги. Нищо подобно! PDF е формат за електронно представяне на хартиени книги! За това е замислян, за това е проектиран и реализиран, и изпълнява прекрасно тези си функции вече десетилетия. При него се гарантира, че на каквото и устройство да се извежда, винаги ще се получи един и същи резултат. (Малка вметка: Преди десетина години четох, че го използвали за предаване на вестници към трансокеанските лайнери – издателството изпраща PDF-а, на кораба го разпечатват и пътниците винаги разполагат със „свежи“ вестници.)
Съвсем накратко за структурата му – исторически погледнато, той е наследник на езика PostScript, където всичко се описва с криви. Ако желаете да изпишете буквата „о“, трябва да дефинирате две криви (за вътрешния и външния контур). Ако искате да изпишете буквата „а“, ще трябва да използвате повече криви. PDF-ът все още поддържа този начин на представяне (за обратна съвместимост), въпреки че размерът на крайния файл е просто огромен. Но програмистите сме мързеливо племе, освен това изобщо не обичаме повтарящи се участъци от код или данни, затова някой е решил: „Защо непрекъснато трябва да повтаряме едни и същи криви, когато трябва да изпишем едни и същи букви; хайде да оставим буквата като текст, а по-надолу във файла да сложим речник – коя буква с какви криви се описва“. Тази технология е наречена „вграждане на шрифт“, но чисто технически не е много коректно, защото речникът не съдържа целия шрифт, а само символите, които се използват в PDF-а. Тоест, ако направите PDF с вграден шрифт, в който има само думата „Здрасти!“, в речника му ще има точно осем символа. Самите букви се наричат „текстов слой“ и позволяват копиране. Неизвестно защо, PDF-ът поддържа трета възможност – текстов слой, но без асоцииран речник. Тоест, разчита се на това, че на клиентската машина ще има инсталиран използвания шрифт, което е в пряко противоречие с идеологията на форма̀та.
И така, след като вече имаме представа какво представлява PDF-ът отвътре, можем да разгледаме поредния мит – че може да се конвертира във всичко. Нищо подобно; по отношение на конвертирането PDF-ът е задънена улица. Разполагате ли с PDF, единственият разумен начин да получите форматиран текст е да прекарате PDF-а през програма за разпознаване на текст (OCR), след което внимателно да коригирате резултата. Защо? Хайде да разгледаме двата варианта – с текстов слой и без. При варианта без текстов слой нещата са ясни – няма текст като такъв, буквите са във вид на криви (тоест, картинки) и единственият начин да извадите нещо от там е OCR-а. При наличие на текстов слой има още подварианти. Най-лошият е, когато при генерирането на PDF-а е използван нестандартен шрифт (например популярните в миналото „TmsCyr“, „UniverseCyr“ и подобни), при което копирането от текстовия слой води до някаква абракадабра. Но дори и да успеете да копирате нормален текст от PDF-а, ще се сблъскате със следващия проблем – текстът е твърдо разбит на редове. Събирането на тези редове в параграфи може да се извърши само ръчно. Онези, които вече подгряват клавиатурите си, за да ме контрират с любимия си конвертор „PDF-към-нещо-си“, нека първо помислят: как ще съберете два поредни реда в параграфа – с интервал ли? А какво ще правите с твърдите тирета за пренос? А със съставните думи като „синьо-зелен“, или сравнителните степени (по-, най-), при които тирето се използва и за пренос? Не, пълната автоматизация на този процес е невъзможна; за нормален резултат винаги се налага човешка намеса.
Нека видим и каква е поддръжката на този формат в различните устройства за четене. На устройства с малко памет и слаб процесор (PPC) този формат просто не се отваря. На устройства с добри процесор и памет, но с малък екран (телефони) се отваря, но не може да се чете – представяте ли си непрекъснато да влачите пръст по екрана, за да прочетете един ред? На eInk в повечето случаи се отваря, но ако е форматиран като „нормална“ книга, мащабирането ще направи буквите нечитаеми (изпробвано!), а серифният шрифт допълнително ще влоши положението. На малки таблети (около 7 инча) се отваря и чете без проблем, но ако мащабирате страницата така, че да елиминирате белите полета, ще имате проблем с прелистването. Накратко, PDF се чете без проблеми само на устройства с големи екрани – големи таблети (около 10 инча), лаптопи и настолни машини. И ако си купя електронна книга в PDF формат, за да я прочета след дългия работен ден пред компютъра, ще трябва отново да седна зад компютъра… не, благодаря. PDF-ът е перфектен за архив, за инцидентни справки или дори за демо-версия на книгата (от рода на „прочетете първата глава тук“), но за четене на цяла книга… забравете.

[Mandor]

3.2. HTML

HTML е форматът, чрез който се представят страниците в интернет, които разглеждате в браузера си. Защо тогава се занимаваме с него?
Ами защото още от зората на електронните книги (преди около 20-25 години) всички разпространени формати или са базирани на HTML (негово подмножество), или са създавани чрез генератори, чийто входен формат е бил HTML. Дори и в момента това важи за повечето от масовите формати, два от които ще разгледаме след малко.
И така, какво представлява HTML (знаещите да прескочат този параграф)? Това е чисто текстов формат, тоест на теория можете да го създадете и/или редактирате с произволен текстов редактор от класа на Notepad, а форматирането се задава чрез предварително дефинирани текстови маркери, които ограждат целевия текст. Маркерите са оградени чрез символите „<>“ (по-малко и по-голямо), които съкратено ще наричам „ъглови скоби“. Например ако искате да укажете, че изреченията „Макс умря в сряда. Той винаги умираше в сряда.“ образуват един параграф, трябва да напишете: „<p>Макс умря в сряда. Той винаги умираше в сряда</p>.“ („p“ – от paragraph). Ако искате да форматирате даден ред като заглавие от първо ниво, пишете „<h1>Глава първа</h1>“. Ако искате дадена дума да се изведе с наклонен шрифт, пишете „Той <i>винаги</i> умираше в сряда.“ и т.н.
И така, какви са по-важните характеристики на HTML-а от гледна точка на електронните книги?
Един от проблемите е, че един и същ HTML се показва по различен начин в различните браузери. И това довежда уеб-дизайнерите до тиха лудост. Просто всеки производител си тълкува стандарта по своему, а като добавим и неизбежните грешки в реализацията, положението става трагично.
Положителен факт е, че сравнително бързо се стига до заключението, че има нужда от разделяне на семантиката и форматирането и се появяват т.нар. „стилови“ таблици, чрез които можеш директно да укажеш по какъв начин се извежда даден елемент. Тези стилови таблици (CSS) могат да се „вградят“ в HTML-а, но в по-масовия случай са самостоятелни файлове, което дава възможност да се правят различни CSS-и за един и същ HTML – по един за всеки браузер, например. Или в случая с електронните книги – по един за всеки тип четец, като „базовия“ текст (тоест, HTML-а) остава един и същ.
Друг недостатък на HTML-а е голямото изобилие на маркери и техните атрибути. Те са толкова много, че браузерите за устройства със слаб процесор и малко памет (PPC) реализират само най-масовите, а останалите се извеждат неформатирано.
Голяма бъркотия внася и препоръката в стандарта, според която браузера трябва да направи всичко възможно, за да изобрази дори некоректен HTML. Тоест, въпреки че за всеки отварящ маркер задължително трябва да има съответен затварящ, спокойно можете да напишете поредица от параграфи само с отварящи маркери, а браузерите ще го покажат по абсолютно същия начин, както ако имахте и затварящи маркери. Това намалява обема на файла, а във времената на модемните връзки всяка секунда трансфер е от значение – дали потребителят ще изчака зареждането на страницата. (Между другото, този проблем отново се завръща с масовото навлизане на смартфоните и мобилния интернет.) Накратко, за много малко време се генерира голям обем от текстове в HTML, които на практика са некоректни.
Следващият проблем е наличието както на маркери за семантично форматиране, така и на маркери за крайно форматиране. Наред с чисто семантичните маркери за параграф, заглавия, цитат и др., има маркери за указване на шрифта (вид, размер, начертание, цвят…), за модифициране на начертанието (нормален, наклонен, удебелен…) и т.н. Това води до нееднозначност на представянето на един и същи краен вид. Например, за да изведете дадена дума с наклонен шрифт, има поне пет начина – маркер за наклонен текст, маркер за акцентиран текст, маркер за конкретен стил и т.н., и т.н.
Е, на база всичко казано до момента, да видим доколко HTML е подходящ за електронни книги. Според мен – не особено. Да, на теория разполагате с утвърден и работещ механизъм за семантично форматиране, с който някой специалист може да направи чудеса и да постигне почти перфектни резултати. Но на практика…на практика никой не наема специалист по форматиране, а конверторите и HTML-редакторите си правят каквото си искат – те са ориентирани към запазване на крайния вид (WYSIWYG), а не към семантичното форматиране. Към това да добавим почти несъществуващите възможности за метаданни, липсата на специфични типографски маркери – нека специалистите се замислят как се представя бележка под линия в HTML – и пригодността на HTML-а като формат за електронни книги все повече намалява. Допълнително неудобство е, че една електронна книга в HTML съдържа няколко файла – най-малкото HTML и картинка за корицата, а добрата практика изисква стиловата таблица също да се представя отделно. През годините са правени няколко опита за „пакетиране“ на HTML в един файл – компилиран HTML (CHM), асоцииране чрез средствата на операционната система – но нито един от тях не получава голямо разпространение.

[Mandor]

3.3. Mobi

Mobi е прочутият нов формат на Amazon, основен за не по-малко прочутия им четец Kindle. Откъде се е появил той?
Преди около петнайсет години единствените мобилни устройства бяха PocketPC и Palm. Тогава един от най-масовите формати за електронни книги беше PRC. Това всъщност е универсален контейнерен формат за Palm (PRC означава Palm Resource Code), и затова в началото на всеки файл има заглавна част, в която се описват параметрите му, включително и типа – какво съдържа (в случая с книгите това беше „TEXT“). „Вътрешността“ му представлява подмножество на HTML (около 30-ина маркера), компресирано (по желание) с полустандартен алгоритъм, вариация на Лемпел-Зив.
Когато преди няколко години Amazon започват проекта Kindle, те купиха от MobiPocket правата върху форма̀та и генераторите му, промениха типа от TEXT на MOBI и обявиха резултата за нов формат. Така че – нищо ново под слънцето…
Доколко е подходящ за електронни книги? Като се има предвид написаното за HTML, логично е, че негов наследник, който не добавя нищо, а напротив – ограничава наличните възможности, ще е още по-неподходящ. Отново – липса на специфични маркери, на поне базови метаданни и т.н. Разбира се, форматът има едно преимущество: той е насочен предимно към един четец – Kindle – и затова Amazon могат да си позволят по-голяма свобода във форматирането на електронните си книги. За съжаление, ние не разполагаме с такова предимство.

[Mandor]

3.4. ePub

За мен ePub е едно голямо недоразумение. Кажете ми, за бога, какъв е смисълът да вземеш няколко HTML-файла, заедно със съответните им допълнителни файлове (картинки за корица и илюстрации, стилови таблици и пр.), да му добавиш задължителни метаданни, в които не можеш да включиш елементарни полета като „преводач“, плюс още един-два служебни файла (идентификатор и съдържание), да пакетираш всичко това в стандартен ZIP-архив и да обявиш резултата за революция в електронните книги?
Нямам представа.
Единственото ми по-смислено подозрение е, че така се получава единен файл, в който можеш да сложиш DRM. Да, метаданните му са малко по-развити от базовия HTML, но все още са много недостатъчни. И все още липсват специфични типографски маркери като бележка под линия – едва в ePub3 добавиха атрибут към обикновената препратка, по който да се разпознава като препратка към бележка под линия, но по отношение тялото на бележката нещата са по старому.
При така описаната структура на ePub-а е логично да се досетите, че всеки ePub-четец на практика ще е някой стандартен браузър, допълнен с възможност за директна работа със ZIP-архиви. От което следва, че проблемът на HTML „всеки браузер го показва както си иска“ се наследява с пълна сила и при ePub. Наскоро препрочетох статия за проблемите със съвместимостта на ePub в различните четци; там авторът даваше следния пример: „Опитайте се да направите ePub, съдържащ нещо тривиално – два параграфа, разделени с празен ред, – но така, че да се извежда еднакво на iBooks, ADE, Sony Reader и Nook. Няма да включваме китайските четци, за да направим задачата изпълнима. И дори няма да искаме двустранно подравняване и преноси – просто два параграфа и един празен ред между тях.“
Накратко, ePub-ът наследява почти всички минуси на HTML-а, но с две особености.
Първата от тях е, че за първи път се появява единен масов стандарт за обединяване на всички HTML-файлове в единен пакет. И това е много хубаво. Както казах по-горе, до момента са правени много опити, но нито един от тях не е бил успешен.
Втората особеност е… меко казано, спорна. Макар че съм по-склонен да я причисля към вредните, а не полезните свойства. Става въпрос за възможността за вграждане на шрифт.
От една страна, това е прекрасен инструмент в ръцете на съвестните специалисти. Представете си, че искате да форматирате книга, в която има старобългарски букви (например „Пълноземие“ на Теллалов). Ако работехте с „чист“ HTML, единствената ви възможност е да поставите правилните символи, да опишете в стиловата таблица десетина от най-разпространените шрифтове, в които сте сигурни, че тези символи са реализирани, и да стискате палци да не попаднете на клиент с нестандартен четец. При ePub-а вече е възможно да си подберете шрифт за старобългарските букви, да го вградите в крайния файл и да укажете къде да се използва. И на теория всичко е прекрасно… На практика потребителите сякаш възприемат всяка допълнителна функционалност като възможност за злоупотреби. Така се появяват романи с текст от половин мегабайт и седем мегабайта шрифтове – типичен пример за злоупотреба с функционалност.
Ситуацията се усложнява и от факта, че единственият официален четец на ePub, Adobe Digital Editions (ADE), който на всичкото отгоре е единственият четец, поддържащ DRM (четците в някои eInk-ове са базирани на него), се разпространява с не-Unicode шрифтове. (За неспецалистите – Unicode е международен стандарт за кодиране на символи от цял свят – кирилица, иврит, арабски, математически символи и т.н. Не-Unicode шрифтовете съдържат само фиксирано подмножество от тези символи, например латиница и кирилица, като втората част обикновено е „присадка“ и точната позиция на символите в присадката зависи от съответната подредба; оттук и различните кодировки като Windows-1251, KOI-8 и т.н.) Тоест, ако искате да създадете ePub на кирилица, който да може да се чете в ADE, трябва да вградите шрифтовете вътре. И това подвежда много хора – преди две-три години се опитах да споря с издател, който с пяна на уста настояваше, че „щом не се чете в ADE, значи е некоректен“. Е, този издател беше свалил от Читанка един сборник с поезия (барабар с всичките грешки от разпознаване), беше изтрил споменаването на „Моята библиотека“ и хората, които са сканирали и коригирали електронната версия, беше добавил шрифтове и в пристъп на творчески ентусиазъм беше направил всички заглавия да се извеждат с разредка, като го реализира с обикновени интервали – по един между буквите и по два между думите. Специалистите знаят какво се получава (:-D), а за неспециалистите – ами накрая виждате нещо от сорта на „Л ю л я к ъ т м и з а м и р и с а“. И това „творение“ беше представено като продукт на издателството…
Изобщо, напоследък масово е разпространена практиката пълни профани в дадена област да налагат заблуди заради материални или просто егоистични интереси. Последният фрапиращ случай, който забелязах, беше във форума на интернет-магазин, специализиран в продажбата на четци с eInk-екрани. Там беше зададен въпросът: „Защо със закупения от вас четец модел еди-кой-си не мога да отворя ePub-файловете от Читанка?“. Е, местната „специалистка“ очевидно и бъкел не разбира от ePub и единственият начин да създаде такъв вероятно е да използва конвертор като Calibre (който по подразбиране вгражда шрифтовете). Също така си няма на представа, че съответният модел е изработен за САЩ и не разполага с шрифтове на кирилица, но затова пък поддържа визуализация на вградените шрифтове. И в крайна сметка отговаря (цитирам по памет): „Нашите тестове показаха, че ePub-файлове на кирилица се четат без проблем на посоченото устройство. Очевидно файловете на Читанка са некоректни, но нека не се сърдим на момчетата – те толкова могат :-)“… Оркестърът свири туш, завесата пада, а зрителите стоят с отворени усти и не знаят да се смеят ли, да плачат ли…
Разказвам ви тези подробности, за да разберете, че проблемът с вградените шрифтове в ePub на практика е триизмерен; той има три оси. По първата е дали ePub-а, който отваряте, има вградени шрифтове или не. Втората и третата ос са относно четеца – дали поддържа визуализация на вградени шрифтове и дали се разпространява с Unicode-шрифтове. Няма да разглеждам осемте варианта в подробности; просто имайте предвид тази особеност, когато се сблъскате с проблема „вграден шрифт“.
Нека набързо да прегледаме каква е поддръжката на ePub в четците. При устройства с големи екрани няма проблем – там четците се свеждат до някой стандартен браузер, разширен с възможност да работи директно от ZIP-файл. При eInk-овете нещата са „на кантар“ – в повечето случаи ще получите нещо прилично, но в доста случаи – не; зависи както от ePub-а, така и от конкретния четец. При устройствата с малки екрани нещата са трагични – или форматът изобщо не се поддържа (PPC), или е нечитаем (телефон с ниска разделителна способност на екрана); изключение правят модерните телефони с висока плътност.

[Mandor]

3.5. FictionBook 2

И така стигаме до любимия ми формат – FictionBook 2, или съкратено FB2. За него могат да се кажат доста интересни неща, но да караме подред.
Първо, това не е универсален формат като разглежданите до момента; както показва името му, той е ориентиран главно към художествената литература.
Второто интересна особеност е, че той никога не е замислян като формат за четене, а като формат за съхранение и източник за генериране на други формати. Ето накратко историята му.
Преди около десетина години, в пика на всевъзможни руски интернет-библиотеки, един руснак, Дмитрий Грибов, решава да направи библиотека, в която всяка книга да се представя на потребителите във всички масови (за онзи момент) формати. Както вече казахме, по онова време всички формати са били или базирани на HTML, или се генерирали от него, като всеки имал собствени, специфични изисквания. Така че Грибов бързо стига до концепцията за семантично форматиране и тъй като нямало нищо подходящо за целта, дефинира просто подмножество на XML. (За неспециалистите – XML е текстов формат като HTML, но за разлика от него няма изрична дефиниция на смисъла на маркерите – например в един XML маркерът „<i>“ може да означава наклонен текст, а в друг XML да указва малко име на автор. Което го прави универсално средство за представяне на данни.) Той съдържа десетина блокови маркера като „заглавие“, „епиграф“, „цитат“, „стих“ и т.н., а от вътрешнопараграфните са дефинирани неща като „горен индекс“, „долен индекс“, „препратка към бележка от линия“, „акцентиран текст“ и „силно акцентиран текст“. Забележете – не „наклонен“ и „удебелен“, както погрешно го възприемат много хора, а именно „акцентиран“ и „силно акцентиран“. Към всичко това добавя стандартен метод за кодиране и влагане на картинки, както и много богат набор от метаданни, включващ жанр, данни за оригиналното произведение, данни за хартиеното издание и т.н. и в крайна сметка се получава файл, съдържащ цялата необходима информация за генериране или каталогизиране на книгата. Крайните формати се получавали чрез стандартни трансформиращи файлове (XSLT), евентуално с последващо подаване към конвертор. И за да могат да се преглеждат FB2-файловете, Михаил Манцев написва първия четец за FictionBook, като го компилира за някои от най-масовите платформи за момента – PocketPC (три версии) и Windows. И така библиотеката заработила…
Но скоро се оказало, че форматът бил толкова компактен и удобен, че получил голяма известност и повечето потребители на библиотеката използвали само него за четене. Тази известност довежда до бързо изчистване на най-големите проблеми и само след половин година се появила втората (FB2), която и до момента се радва на голяма популярност. Това е единственият ми известен формат, за който има четци под всяка операционна система и кажи-речи – за всяко устройство, пригодно за четене на електронни книги. И няма защо да се учудваме, че преди няколко години библиотеката се трансформира в един от най-популярните магазини за електронни книги в Русия – LitRes – като запази първоначалната си схема за един източник (FB2) и много крайни формати, генерирани от него.
Както сигурно вече сте разбрали, в този формат се описва именно типът на текста – „това е заглавие“, „това е епиграф“, без по никакъв начин да се указва как се извежда дадения елемент. Това налага съответното форматиране да се извърши в четеца на крайния потребител, което е чудесно – така конкретните четци прилагат схема, която е най-подходяща за съответното устройство. Например при устройства със среден размер на екрана (около 6 инча) акцентираният текст се извежда с наклонен шрифт, но в устройствата с малки екрани същият текст се извежда в различен цвят. При първите епиграфът се извежда с ляв отстъп, при вторите – без, или с много малък такъв. По-добрите четци (включително и за eInk-устройства) дори предлагат възможност на потребителя сам да си дефинира как да се извеждат съответните елементи.
Друг интересен факт е, че във втората версия се появяват стилови таблици (като в HTML), което директно противоречи на идеологията на форма̀та и е източник на всевъзможни злоупотреби (имитация на HTML чрез FB2). Слава богу, това „отклонение“ не получава особено разпространение, защото много малко четци го поддържат. А тези, които все пак го реализират, имат собствени изисквания към стиловите таблици.
Любопитно е да се отбележи, че много хора, работещи с този формат, отказват да приемат идеологията му – „укажи какво е, а не как се извежда“ – и продължават да мислят с термините на крайно форматиране. Преди месец преглеждах FB2-файл, в който препратките към бележките под линия бяха допълнително повдигнати чрез маркер за горен индекс (по аналогия на книжните издания). Като резултат, на устройствата с малки екрани, където препратката се извежда с нормален размер на шрифта, беше невъзможно да се „уцели“ мястото с писалката и да се направи преход към тялото на бележката. Аналогично беше положението и на устройствата със среден и голям екран – там препратката се извежда в горен индекс и допълнителното повдигане доведе до ефекта „степен на степен“ – в крайна сметка отново беше невъзможно да я „уцеля“ с мишката.
Тук е мястото да вметна една забележка за крайното форматиране. До момента давах примери само с абсолютно крайно форматиране – „използвай този шрифт, в този размер“. Но всичко казано важи и за относителното крайно форматиране. Пояснявам с пример – в „Царска заръка“ на Теллалов има параграф, в който размерът на думите намалява прогресивно – за имитация на заглъхваща в далечината реч – до 50% от основния размер на шрифта. И тук хората, занимаващи се със семантично форматиране, се подвеждат; те си казват „Аз не искам да налагам с какъв шрифт или какъв размер ще се чете; просто искам следващите думи да са по-малки“. И съответно дефинират стилове за размер на шрифта 95%, 90% и т.н. до 50% от основния, като форматират съответните участъци с тези стилове. Резултатът? На устройства със средни екрани текста е нечитаем след около 70%, а на устройства с малки екрани – още на 85-90% от основния размер. Така че (отново) – никакво крайно форматиране; нито абсолютно, нито относително.
Но да се върнем на FB2. От всичко казано досега може би сте останали с впечатлението, че форматът е идеален и перфектен във всяко едно отношение. Е, както във всичко останало, и тук няма идеални неща. Първо, FB2 има доста ограничени изразни средства – в началото изброих основните блокови елементи. Второ, форматът има някои глупави ограничения, които буквално повреждат форматирането, но никога не са променяни; най-фрапиращият пример е правилото, че автор на цитат или епиграф може да се появи само в края на елемента. На пръв поглед е логично, но заради това правило не можете „чисто“ да форматирате писмо с подпис и послепис – налага се да се измъквате чрез акцентиране на подписа. Друг проблем е липсата на добър редактор за генериране и/или корекция на FB2 – двата най-популярни са само за Windows и всеки си има собствени „кусури“ за оправяне. Допълнителна заблуда причиняват редакторите, които за акцентиран и силно акцентиран текст използват стандартните икони за наклонен и удебелен текст. Това подвежда начинаещите, че работят със стандартен WYSIWYG-редактор и още на заглавието натискат иконата за „удебелен“ текст и търсят как да го центрират.
И още една вметка – много хора не разбират защо се е наложило Читанка да измисля собствен формат за представяне на текстовете. Някои дори стигат до крайности – „Откъде се пръкна този измислен формат?“. Много просто – форматът на Читанка (SFB) е обикновен FB2 файл, представен чрез текстови маркери по аналогия с уики системите. Това позволява да се изработват семантично форматирани файлове, и то с произволен текстов редактор, а конвертирането им до FB2 е сведено до почти тривиално заместване.


С това приключвам прегледа на най-популярните формати за електронни книги. Искам само да ви обърна внимание на още една особеност. Ако сте забелязали, всички разгледани формати (с изключение на PDF, но – както казахме – това не е формат за електронни книги) са базирани или на HTML, или на XML, където форматирането на елементите се извършва на блоков принцип. Тоест, указва се къде започва даден блок и къде свършва. От друга страна, всички популярни редактори форматират текста на абзацен принцип – там може да асоциираш стил само към параграф. И съответно не можеш (например) да укажеш два поредни цитата, всеки от по два параграфа, което е нещо тривиално при HTML/XML-форматирането. Което ги прави не особено подходящи за работа с формати, ориентирани към блоково форматиране.

[Mandor]

4. Конвертиране

Митовете в конвертирането са достигнали почти религиозни висоти. Най-лаконично могат да се обобщят така: „Всемогъщо е конвертирането и Calibre е неговият пророк!“ :-)
Но каква е истината? Хората сякаш си представят произведението като някаква течност, форматите – като различни бутилки, а конвертирането го свеждат до преливането на течността от една бутилка в друга. Само че ако продължим тази аналогия, трябва да имаме предвид, че много често опаковката определя съдържанието. Не е логично да налееш лимонада в бирено шише и да представиш това за бира. Да, на вид го докарва, на цвят – почти, на вкус – никак. Същото е и при конвертирането. Нека ви разкажа една случка, на която бях свидетел преди две години.
В Читанка се появява нов ентусиаст, който си беше харесал книга с налични сканове и пита какво е нужно, за да се обработи книгата. Обясняват му, че скановете трябва да се разпознаят, разпознатият текст да се коригира и да се качи резултата в някой от универсалните формати като RTF. Човекът благодари и изчезва, а на другия ден в записа се появява RTF файл, в който на всяка страница прилежно е вмъкнат по един скан. :-)
Същият ефект – в една или друга степен – можете да получите в много от вариантите за конвертиране. Но сканове в PDF не са точно PDF, а просто пакетиран набор от картинки; текстов файл, „налят“ във FB2 не е FB2, а просто текстов файл в друга опаковка. Изобщо, сляпата вяра в конвертирането може да ви осигури много проблеми и неприятности.
Няколко думи за Calibre. Поредният мит е, че това е програма за конвертиране. И този мит упорито се разпространява и налага по различни форуми и сайтове за въпроси и отговори: „Как да конвертирам RTF в HTML?“ – „Използвай Calibre!“; „Как да конвертирам HTML във FB2?“ – „Използвай Calibre!“; „Как да конвертирам вода в ракия?“ – „Използвай Calibre!“… Всъщност Calibre е програма за каталогизация на електронни книги. Но тъй като често се случва потребителят да разполага с четец, който поддържа ограничен набор от формати (например аз имам четец, който поддържа само FB2), е предвидена възможност да си конвертира наличните файлове в предпочитания от него формат – къде по-добре, къде по-зле; важното е, че ще може да го отвори в четеца си и да го прочете. Но масовата реклама (макар и неволна) подвежда неспециалистите да мислят, че пълноценното конвертиране е възможно и съответно да използват Calibre, за да генерират различни крайни формати на своя продукт. Да видим дали това е така.
Нека разгледаме три варианта за конвертиране, от гледна точка на семантичното и крайното форматиране.

1. От файл с крайно форматиране във файл с крайно форматиране
На пръв поглед няма никакъв проблем – всички формати с крайно форматиране имат кажи-речи сходни параметри за настройка – шрифт, размер, начертание, отстъпи и т.н. Но ако помислим още малко… дали може безпроблемно да се конвертира RTF/DOC в HTML? А какво ще направи конверторът, когато стигне до бележка под линия? Много просто – ще приложи някакво заобикаляне на проблема, такова, каквото е решил програмистът. Никой конвертор няма да ви каже „Не знам как да конвертирам този елемент“, а или ще игнорира съответното форматиране, или ще приложи фиксирана схема за имитация на липсващата функционалност. Аналогичен е проблемът и при конвертиране на HTML в mobi – на теория всичко е идеално (нали mobi е базирана на HTML), но какво ще се случи, когато във входния файл се използва функционалност, която липсва в изходния? Правилно, същото – пренебрегване или заобикаляне.
Искам изрично да подчертая, че тук става въпрос именно за конвертиране. Не бива да го бъркате с обикновеното пакетиране, както е случаят с преобразуването на HTML към ePub – в този случай съответствието е едно към едно и няма никакво преобразуване на входните файлове; те просто се компресират и допълват със служебната информация.

2. От файл с крайно форматиране към файл със семантично форматиране
Възможно ли е това, дори на теория? Абсурд. Още в началото подчертах, че семантично форматиране може да се извърши само от човек. Никой конвертор не е способен автоматично да определи типа на елементите от текста. А ако някой конвертор твърди, че може да конвертира например RTF във FB2, той просто ви заблуждава – ще получите един текстов файл, опакован във FB2-обвивка. Ето един пример:
Нашият изгряващ писател Алекс Белтов (здрасти, Алекс!) взема новия си роман, прилежно форматиран чрез някой офисен текстообработващ продукт, няма значение в какъв формат – RTF, DOC, ODT – и за да предложи книгата си в още няколко популярни формата, я подава на Calibre и – хоп! – получава ePub и FB2. За ePub-а няма да говоря; разгледахме този вариант в предишната точка. Да видим какво може да направи конвертора при преобразуване към FB2. Стига до първия елемент (заглавието) и чете характеристиките – „шрифт еди-кой-си, размер еди-кой-си, удебелен, центриран“. Хм-м-м… Във FB2 няма определяне на шрифтове – прескачаме го. Няма и размер – прескачаме го. Удебелен… ами-и… силният акцент много прилича на удебеляване, затова прилагаме него. Центриране – не се поддържа. И така нататък, и така нататък – в крайна сметка се получава един линеен текстов файл с тук-таме акцентирани редове, изкуствено отделени от основния текст с празни редове. Нямате съдържание (то се генерира автоматично на базата на заглавията, които липсват), нямате форматирани стихове, епиграфи и прочее елементи – просто един текстов файл. И това е само за текста; какво ще направи конверторът с метаданните? Точно така – незадължителните ще ги прескочи, а в задължителните ще сложи нещо по подразбиране, защото няма откъде да вземе тази информация. И така „Матрикант 2“ се появява с жанр „антична литература“ – най-вероятно защото е първа по азбучен ред в списъка с жанрове.
Забележете още нещо – дори Алекс да отвори генерирания FB2 файл и да остане недоволен от резултата, той просто няма полезен ход – или трябва да се откаже да го използва, или да го пусне както е.
Накратко – не можете да конвертирате във FB2!

3. От файл със семантично форматиране към файл с крайно форматиране
Възможно ли е? Ами да – никакъв проблем! Но с една особеност – само с фиксирана схема за заместване на семантичните елементи с конструкции за крайно форматиране. Тоест, някъде в конвертора има инструкции (под една или друга форма) от рода на „заглавие от първо ниво се конвертира в текст с шрифт Arial, 18 пункта, удебелен, центриран“. По-слабите конвертори използват фиксирани (вградени) схеми; по-добрите ви дават възможност да изберете конкретна схема, при което вече имате пълна свобода на действие – от един FB2 файл можете да генерирате ePub, RTF, mobi, че дори и няколко вида PDF.

Да обобщя. Не очаквайте чудеса; пълноценното конвертиране е възможно в много редки случаи. Не издигайте в култ Calibre – възможностите му не са безгранични. И в никакъв, ама в никакъв случай не го използвайте за генериране на файлове, които ще разпространявате; той е подходящ само за лична употреба.

[Mandor]

5. Заключение

И накрая да разгледаме още една масова заблуда сред издателите – че електронните книги се изработват по същия начин, както и хартиените (без печата).
Как се стига до това? Издателят си мисли: „Имам форматирана книга в InDesign, ще сглобя един PDF без маркери за ножове и другите външни атрибути, ще оправя белите полета и – готово, мога да пусна електронна книга! А с последното обновяване добавиха и експорт в ePub, така че мога да предлагам не един, а цели два варианта!“
Да мислиш по този начин е все едно някой превозвач от началото на XX век да си мисли: „Имам двайсет години опит в превозите, познавам и пътищата, и търговците, ще взема да сменя каруцата с някоя от тези модерни измишльотини – камионите. Хем ще превозвам повече, хем ще го правя по-бързо.“ И макар да съзнава, че вместо овес ще му е нужен бензин, някак му убягва от вниманието, че вместо теслата, с която е поправял колелата, ще трябва да се снабди с комплект гаечни ключове, отверки, клещи и т.н., а на всичкото отгоре ще трябва да придобива съвсем нови умения – да шофира.
Аналогично е и положението с издателите. Да предположим, че по гореописаната схема все пак се произведе книга в ePub. Какво може да направи издателя, ако получи сигнал, че книгата му не се чете или че форматирането не се извежда както е замислено? Първи вариант – може да наеме специалист, който да поправи проблема. Втори вариант – да започне да рови в Интернет с надеждата да попадне на готово решение. Трети вариант – просто да каже „при мен всичко е наред, проблемът е в твоя четец“ и по този начин да маскира проблема.
Тук се сещам за електронната версия (ePub) на официалната биография на Стив Джобс, издание на SoftPress. Не знам какъв изходен файл са използвали, но просто са го подали на Calibre и са го конвертирали в ePub. Резултатът – в целия текст се използват само два маркера за форматиране – за параграф и за вътрешнопараграфна модификация. Останалото „виси“ на стилове. Нямате заглавия (h1, h2…), нямате цитати, нямате нищо, освен обикновени редове с различни стилове. И подзаглавията са по-големи от заглавията, които пък са с размера на основния текст. И за елементарни модификации като наклонен текст се използва не простото <i>, а <span style=”italic”>. Като добавим и елементарните грешки като забравени тирета за пренос (здравей, крайно форматиране!) и не особено коректния превод, се получава нещо абсурдно. И за това недоразумение, което може да се отвори само на някои четци (заради DRM-а) ми искат 15.00 лв при цена на хартиеното издание 20.00 лв. Не, благодаря.
Накратко – изработката на електронни книги е съвсем нова професия, която изисква съвсем нов набор от умения и напълно нов инструментариум за работа. Да, опитът в хартиеното книгоиздаване ще е от голяма полза, а повечето от усвоените с годините трикове могат много да помогнат, но в никакъв случай не са достатъчни сами по себе си.


И най-важното – възприемайте целия този словесен дри… извинете, тези проницателни наблюдения не като указания, не като съвети, а просто като информация. Имате глави на раменете си – използвайте ги, вместо да правите глу… пфу! – вместо бързо и лесно да създавате електронни книги. ;-)

[Cliff_Burton]

Благодаря за лекцията

[bogdanov]

Напомни ми, ако някога те видя, да те черпя поне една бира.
Макар че имам някои леки забележки, за жалост си прав. Особено в частта за издателствата.

[Goa]

С това почти отпада необходимостта да се качи файла с дискусията, но все пак може и оттам да излязат интересни неща, така че няма да отпадне.

[Mandor]

С това почти отпада необходимостта да се качи файла с дискусията, но все пак може и оттам да излязат интересни неща, така че няма да отпадне.

В т.нар. „дискусия“ нямаше нищо полезно, така че не виждам смисъл да я качваш. Тук всичко е далеч по-пълно и подробно.