Защо SFB?

От Уики на Читанка
Направо към: навигация, търсене

Да предположим, че трябва да организирате уеб-услуга за съхраняване на форматирани текстове, и възможност за извличането им в различни формати (чрез автоматично конвертиране). Освен това искате да дадете възможност на потребителите сами да подготвят такива текстове и да ги изпращат за качване. В какъв формат ще съхранявате тези текстове? Основният проблем е, че почти всички масови формати за представяне на електронен текст са ориентирани към това, как изглежда всеки фрагмент от текста (наклонен, центриран и т.н.), а не към това, какво всъщност представлява (основен текст, заглавие на глава, епиграф и т.н.). Защо това е важно?


Представете си, че сте страньор в издателство. Възлагат ви да оформите книга от три свързани повести в по-големия формат (60×90/16). Вземате папката с авторския „ръкопис“ (напечатан на пишеща машина), сядате на компютъра си и отваряте текстовия файл, набран от 63-годишната леля Сийка, чийто компютърни умения се изчерпват с поливането на фермата й във Фейсбук, но която може да набира текст със скорост 160 символа в минута. Така-а… титулна страница… готово… още една титулна с „Книга първа“… готово. Какъв е следващият ред? „Глава първа“. Ясно, заглавие — ще го форматираме с 22 pt, удебелено и центрирано. Следващият фрагмент? Аха, епиграф – ще го форматираме с наклонен шрифт и седем сантиметра ляв отстъп. После – основен текст; ще му сложим размер 12 pt, двустранно подравнен с 1.5 см отстъп за първия ред от параграфа. Хм, тук е подчертал някаква дума, явно иска да наблегне на нея, затова ще я форматираме с наклонен шрифт… и така нататък, и така нататък, чак до края на третата повест. Накрая записвате резултата и го предавате на русата „асистентка“, чието единствено задължение е поддържането на доброто физическо и психическо състояние на управителя на фирмата.

След месец и половина шефовете на издателството с изумление научават, че астрономическият тираж от 200 броя вече е изчерпан, а разпространителите непрекъснато изпращат запитвания за количество. По стара, изпитана рецепта, те решават да пуснат допечатка (освободена от данъци поради липса на документни доказателства за съществуването й). Само че текущите представителни разходи на управителя (за поддръжка външния вид на асистентката) са блокирали плащането на печатницата за първия тираж, а те (какви гадове!) отказват да стартират нова поръчка без да са си получили парите за предишната. Но няма проблем: печатници — колкото искаш, и всички „плачат“ за поръчки; вече са намерили подходяща, само че машината им работи с листа 70×100, а шефовете не искат да губят ценно място (цели 16 кв.дм!) по скъпата 50-грамова вестникарска хартия, на която ще отпечатат книгата, затова решават да ударят с един куршум два заека — ще издадат трите части в отделни книжки с формат 70×100/32; така хем ще оползотворят мястото, хем ще спечелят два пъти повече, като разхвърлят надутата цена по трите книжки. Какво да се прави — нали за това ви плащат — сядате отново пред компютъра, разделяте стария файл на три нови, задавате новия формат на страницата и започвате отначало. „Глава първа“ — ще го намалим на 18 pt. Епиграфът е твърде навътре; ще намалим полето на три сантиметра. Първият ред от параграфите на основния текст също е много навътре, затова ще го намалим на 1 см, а самият текст — на 10 pt… и т.н., и т.н. — до края на третия файл (книга). В края на деня се прибирате уморен, но доволен от свършената работа и сядате пред домашния компютър, за да разпределите щедрата си заплата от 450 лв по всички разходни пера в семейния бюджет.

На другия ден обаче с изумление научавате, че печатницата е върнала файловете — просто не са закупили пълния набор шрифтове и издателската им система (от 1991 г.) преобразува всичкия текст с наклонен шрифт в неразбираема абракадабра. С удебеления текст нямат проблем, затова сядате и започвате да преобразувате всички появявания на наклонен текст в нещо друго: епиграфите — в нормален, но с размер 9 pt (за да се отличава от основния); акцентираните фрагменти в основния текст — в удебелен, стиховете — в нормален, но със запазване на отместването… и т.н., и т.н.

Приключвате и тази работа, но с нарастващо раздразнение — не може ли това да се извърши някак по-лесно? За какво са ми тези компютри, като създават повече проблеми, отколкото решават? Всъщност — може; всяка нетривиална текстообработваща програма поддържа т.нар. „стилове“. Това са именовани набори от начертания (шрифт, размер, отстъп и т.н.), които могат да се асоциират както с цели параграфи (като например епиграф), така и с участъци от текста (напр. акцентиран текст). Но да се върнем на темата.

Обърнахте ли внимание какво всъщност прави нашият (уж) хипотетичен страньор? Всеки път той определя типа на текста (заглавие, епиграф…) и в зависимост от резултата прилага определен набор от характеристики (размер, наклонен, центриран и т.н.). При изисквания за друг набор стилове („нямаме наклонен шрифт; махни го!“) той отново определя типа на всеки фрагмент от текста, след което прилага новия набор характеристики. И именно определянето типа на текста е единствената дейност, която не може да се автоматизира, а трябва да се извърши от човек. И ако се използва средство, чрез което еднократно да се асоциира даден фрагмент от текста с неговия тип, всички последващи изменения в изгледа могат да се извършат автоматично.

Но да се върнем на нашата уеб-услуга; защо се занимаваме с проблеми на печатните издания? Защото абсолютно същите проблеми възникват и при подготовката на електронни текстове. Искате да форматирате „Глава първа“ за уеб-страница? Ще трябва да сложите (например) <h2>Глава първа</h2>. Аха, искате и за някое уики? Тогава ще трябва да го смените на ==Глава първа==. Същото е положението и с останалите елементи. И с другите формати. Допълнителен проблем е, че масовите формати са твърде „тежки“ за автоматичен анализ; да не говорим пък за техните редактори, които добавят купчина излишна информация (който не вярва, да направи един текстов файл с име test.htm, да напише вътре <html><body><p>Hello</p></body></html>, да го отвори в текстов редактор от класа на Word/OOo/StarOffice, да поправи „Hello“ на „Hi“, да го запише и да види резултата). Проблем?

За щастие, има един формат, който е ориентиран точно към представяне структурата на текста (т.е. типа на елементите му), а не към начина на извеждането му — това е FictionBook. В него не описвате как се изобразява даден фрагмент (наклонен, центриран…), а описвате какво представлява той (заглавие, епиграф…). Създаден преди повече от десет години за целите на руска онлайн-библиотека, той се оказва много подходящ и удобен за тази дейност и бързо набира популярност. Масовото разпространение довежда до изчистване на повечето „недомислици“ и е обявена втора версия, FictionBook2, която се използва и до ден-днешен. Въпреки че е замислян само като средство за съхранение и изходен материал за ковертиране, неговата простота довежда до появяването на четци за всякакъв вид устройства — дори и такива със силно ограничена памет (Palm, PPC и т.н.). В днешни дни почти всеки самостоятелен четец (като eInk-базираните) поддържа директно FB2-формата. Едно допълнително удобство е, че четците имат стиловите съответствия на всеки елемент и повечето от тях предоставят възможност на потребителя да ги промени по свой вкус — напр. да махнете левия отстъп на епиграфите (за да не хабите място) или да увеличите този на цитатите (за да се отличава от основния текст) и т.н. — крайният вид на текста е оформен изцяло по ваш вкус.

Е, значи намерихме идеалният формат за съхранение на текстове… всъщност — не съвсем. Като изключим факта, че FB2 не е идеален (той наистина има някои глупави ограничения, с които трябва да се съобразявате), все още не сме решили проблема с неговото създаване от страна на потребителите. За FB2 има само два що-годе прилични редактора, но: и двата са само за Windows; и двата имат проблеми, които ги правят неприложими за масовия потребител. А никой няма да седне и да изписва на ръка FB2-маркерите: <p>…</p> около всеки параграф; <title>…</title> около всяко заглавие; да не говорим пък за метаданните (издателство, година, преводач и т.н.) — освен всичко друго, такъв форматиран текст се преглежда много трудно.

Добре, а няма ли как да предоставим на потребителите възможност да въвеждат форматиран текст, като не ги ограничаваме откъм редактори и тежки маркери, които буквално „скриват“ същинския текст? И този въпрос вече е възниквал и има много прилично решение — уики системите използват чист текст с маркери, повечето от които са замислени така, че да са възможно най-къси и да не пречат на възприемането на основния текст. Например вместо да караме потребителя да огражда всеки параграф в <p>…</p>, нека просто поискаме в началото на параграфа да има един табулатор. Така хем получаваме еднозначен маркер за автоматичното конвертиране — къде започва текста, — хем визуално имитираме отстъпа на първия ред на всеки параграф. И той изглежда добре при преглед в обикновен текстов редактор. Вместо да загражда всяко заглавие в <title>…</title>, нека просто да сложи една вертикална черта пред табулатора на текста („| Глава първа“). Точно по този начин и с тази цел е създаден SFB. Можете да го редактирате с всеки текстов редактор; маркерите не „досаждат“ на погледа при корекция, правилата осигуряват еднозначно конвертиране към желаните изходни формати (ePub, mobi и т.н.), като начинът на извеждане се задава от самия конвертор (например PDF със страница 10×12 см или PDF със страница 13×20 см).

Тук смятам за уместно да вметна следните забележки:

1. Ако сте осмислили написаното досега, би трябвало да сте разбрали, че еднозначното конвертиране от един формат към друг е невъзможно. Първо, различните формати имат различни възможности и просто липсва подходящо съответствие — например как ще конвертирате HTML с CSS3 към mobi, който поддържа само ограничен набор от CSS1? Второ, наборът стилове може да има произволни имена, които няма как да бъдат представени в целевия формат; например какво означава блок от текста със стил „abc234“? Цитат? Епиграф? Заглавие? Единственото, което може да направи програмата, е да анализира съдържанието на стила и да направи всичко по силите си, за да го представи в искания формат. Което в повечето случаи е невъзможно. Да не споменаваме и това, че различните програми визуализират по различен начин един и същ файл с ясно описана спецификация (напр. RTF).

2. При същите условия като в предишната точка — вече би трябвало да ви е ясно, че няма как да съществува „нормален“ конвертор към FB2 (или текстовото му представяне — SFB). Самата същност на формата изисква разпознаване типа на текста, което може да се извърши само от човек. Вижте пак примера от предишната точка — какво означава участък от текста със стил „abc234“? Какво да направи конвертора — какъв тип да постави на този текст, за да получите „нормален“ FB2? Ами нищо не може да направи; обикновено програмите, рекламирани като „конвертор към FB2“ прескачат такива участъци и ги оставят неформатирани и в резултат получавате бледо подобие на оригиналния текст. Специалистите могат да се замислят върху въпроса, как се представят бележки под линия в HTML (или ePub), по какво се различават от вътрешните препратки и как могат да се идентифицират автоматично с цел получаване на коректен FB2 файл…


И така, да обобщим:

  • Автоматизираното конвертиране към няколко изходни формата изисва единен вътрешен формат, ориентиран към представяне типа на текстовите фрагменти, а не към начина на тяхното извеждане.
  • Има само един утвърден формат, който представя такава възможност, но за него липсват подходящи програми за редакция и е твърде тежък за директна корекция.
  • Подобна задача се изпълнява отлично от текстовите маркери на уики-системите, затова е разработен SFB — формат за текстово представяне на FB2-файлове.

Февруари, 2013 г.