You are hereEPUB

EPUB

warning: Creating default object from empty value in /home/ebookua/public_html/modules/taxonomy/taxonomy.pages.inc on line 33.

Аналіз EPUB 3

Недавно IDPF опублікували огляд технічних характеристик нового EPUB 3. Отож тепер ми дізнаємось, чи оправдає він наші очікування. Майте на увазі, що цей пост буде довгим.
Я прочитала всі характеристики EPUB 3 і моє загальне враження можна висловити часткою «ні». Це найточніше вираження моєї думки. Власне «ні», наближається у значенні до «не дуже». Під час читання я записала деякі моменти і нижче, власне, подано мої висновки та твердження.
Вважайте, що я погоджуюся з усіма нюансами, проти яких не висловила чіткого заперечення у цьому пості. Також, хоча я і взялась коментувати негативні сторони EPUB 3, пам’ятайте, що ця розробка має певні переваги.

Я розпочну цей розділ словами про те, що не маю нічого проти JavaScript у мережі, адже це було б нерозумно. Я маю на увазі, що без JS веб-бізнесу просто б не існувало. І якщо заяви проти надмірності веб-додатків все ще мають якусь вагу, то незалежно від того на чиїй Ви стороні, Ви просто не можете сказати, що Gmail непотрібний.
Проте зараз мова йде про книги. У EPUB 2 використання JavaScript не рекомендували (RFC 2119), у будь-якому випадку це означало заборону. Це звичайно ж не абсолютна заборона, проте варто звернути на це увагу.
У EPUB 3 підтримка JS є вибірковою опцією. Тобто Ви можете використовувати JS для epub-книг. Тепер Ви також маєте можливість користуватися технологіями Web 2.0 для електронних книг. Зараз я розкажу, чому така можливість на даний момент не є цілком позитивною. Проте, спершу, хочу наголосити на тому, що в тексті огляду технічних характеристик EPUB згадується, що розробникам контенту варто при можливості уникати використання JS. Наведу цитату з тексту оригіналу: «Відповідно JS варто використовувати лише, коли цього потребує досвідчений користувач, адже це зменшує ймовірність передачі контенту усім системам читання, а також знижує доступність та повторне використання контенту».
На жаль ніхто не звертає на це уваги. Але, принаймні, IDPF зі свого боку попередили, хоча це нічого і не змінить. Отож тепер, коли підтримка JS з «не рекомендованої» перетворилася на «вибіркову», користувачі зроблять все можливе, аби встановити опцію «потрібно для досвідченого користувача», яка включає JS. І це просто кардинально погіршить ситуацію. Тепер усі epub-книги будуть створені виключно для iBooks, а всі інші системи для читання залишаться пережитком минулого. Прогресивні вдосконалення? Ми ніколи їх не дождемося. Люди, що займаються створенням epub-книг не є web-дизайнерами, а працівниками видавничої сфери. Вони не мають найменшого уявлення як виглядає web-код, чи будь-який інший код цієї сфери. Отож з часом, ми побачимо, що ця робота є випадковою і нічого окрім створення електронних книг не включає. Я завжди казала, що день, коли epub специфікації почали просувати підтримку JS, став днем, коли ті сам специфікації опинилися у пащі акули. Не все ще втрачено, хоча ворота пекла вже привідчинені.

Що чекає нас далі:
EPUB 3 запровадить вибіркову підтримку JS.
Видавці почнуть додавати до своїх книг недоладні JS з надією, що це допоможе їм виділитися чи йти в ногу з майбутнім.
Тепер будуть тисячі книг з абсолютно непотрібними JS-шрифтами, без яких читання буде неможливим. Тобто, такі загальновідомі речі як, спеціальні навігаційні меню, клавіші для розширення коду прикладу, зноски у стилі підказок чи інші дизайнерські ідеї, перестають працювати, якщо Ви не підключили JS.
EPUB 4 тепер теж вимагатиме підтримки JS. Ви ж не думаєте, що видавці перероблять всі свої недолугі epubs думаючи про прогресивний розвиток, чи не так? Звичайно ж вони цього не зроблять. А лише змусять IDPF зробити підтримку JS обов’язковою, і їм це вдасться.
Ласкаво прошу у Web-світ 2000! Це буде весело.

Проте я не звинувачую IDPF у тому, що підтримка JS з «не рекомендованої» стала «вибірковою». Хоча, ні, звинувачую. Але я звичайно ж розумію, що вони не мали особливого вибору. Адже що можна зробити, коли більшість людей, які складають групу працівників EPUB є одночасно тими, хто зловживав терміном HTML 5 настільки, що він перестав означати будь-що. І це не є перебільшенням. Він став першокласно загарбаним маркетинговим терміном кинутим у забуття фруктовою компанією. Така нісенітниця як «HTML 5 – це любов та майбутнє людської цивілізації» навіть змусила WHATWG скоротити назву до «HTML», хоча вони і не оприлюднили причини цих дій. Саме так, тепер термін «HTML 5» офіційно нічого не означає. Цікаву інформацію на цю тему можна знайти за посиланням «HTML 5 означає все» («HTML 5 means everything»). Брюс Лавсон прирівнєю CSS 3 до HTML 5 та JavaScript і голосно називає це все ідіотизмом, але ж Ви розумієте в чому справа.

Інтерактивність у книжках? І як друкований світ тільки виживав останні п’ять тисяч років без JavaScript, аудіо, відео та обговорення? Це просто збиває з пантелику.

Цитата зі слів видавців: «Книги HTML 5? О, так! Дивіться просто у майбутнє! Ми аж ніяк не збираємося зникати!»

JavaScript, відео, аудіо та обговорення у книгах прирівнюються до «цій книжці потрібен нашийник».
Я розумію, що виглядаю циніком, але нічого не можу з цим зробити. Коли з‘явився iPad, його проголосили рятівником видавничої індустрії, а зараз, таке враження, що люди просто втрачають голову.

Знову «HTML 5»? Переваги для мережі? Насправді ніякої користі. Нові можливості для електронних книг? Не можу пригадати, коли востаннє думала, що та чи інша книга потребує відео. Насправді 99.99% всіх epubs були б набагато кращими, лише з найпростішими HTML-розробками і декількома рядками CSS.

Я розумію, що це не є виною IDPF, яких так безпардонно звинувачують, проте я все одно дотримуюся думки, що схожі розробки повинні залишатися на рівні «не рекомендовано». Вам подобаються інтерактивні електронні книги? Але це вже не електронна книга, це програма. Ну що ж, створіть таку програму. Ви ж не думаєте, що Вам вдасться написати інтерактивну книгу, яка буде працювати однаково у всіх системах читання. Адже, Вам це не вдасться. Не ускладнюйте собі життя і напишіть програму.

Людям, які мають геніальні ідеї щодо таких інструментальних–підказок windows як, навігаційне меню користувача, без яких книги були б набагато кращими, раджу їх не втілювати в реальність. Це зовсім не круто і навіть не модно. Це просто по-дурному. Ви створюєте книжку, а не сайт, не забувайте про це.

Я впевнена, що є цілком виправдані випадки використання цих технологічних новинок у книжках. Розумна людина, використавши їх у правильному руслі, може зробити щось дійсно грандіозне. На жаль, більшість людей вважають себе розумними, а зазвичай вони помиляються.

Пам‘ятаю як все це починалося. Ще в ті часи, коли EPUB була лише ідеєю, хід думок був наступним: «Як ми будемо представляти електронні книги? Через недосконалий XML як у DocBook? А можливо, краще використовувати таку технічну розробку як HTML, широко відому мову, з готовими компонентами, які полегшать створення системи читання »

Отож, мережні технології використовували через зменшення перешкод при вході. Адже чому б замість DocBook’s не використати HTML’s . CSS також надає можливість вибору стилю.
Але тепер все змінилося. Зараз ми вже не використовуємо веб-технології, щоб створювати електронні книги, ми користуємось електронними книгами, щоб мати застосування для веб-технології. Тобто мова йде не про створення книжок, а про автономне використання технологій. Ви думаєте, що я перебільшую? А чи знаєте Ви, який термін використовували для стислого опису EPUB, під час розробки EUPB 3? Не інакший, як «вебсайт у таблиці» («website in a box»). І це цілком серйозно. Цей термін використовували на зустрічах і його навіть оприлюднили 12 листопада 2010 року в чорновому огляді EUPB. Наведу дослівну цитату: «Оприлюднений EUPB можна вважати вебсайтом у таблиці». Але так не мало б бути, нізащо і ніколи.

Відсутність необхідної кількості символів.
Правду кажучи, найбільшою проблемою EUPB 2 була відсутність необхідного юнікоду для символів. Дозвольте пояснити, що це означає. Якщо дивитися поверхнево, то весь EUPB написаний юнікодом. Все повинно бути або на UTF-8, або на UTF-16. Це звучить просто чудово, адже я можу використовувати будь-які літери. Проте, це не зовсім так. В той час як Ви можете вказати який-завгодно символ, не кожна система зчитування покликана відтворювати той символ. Отож, не має підстав заявляти, що всі системи читання володіють символами усього набору юнікодів, проте не вказано і мінімальних об’ємів покриття, а така інформація була б доволі корисною. Я надіялась, що її нададуть у EUPB 3, проте, помилилася.
Враховуючи сьогоднішній стан речей, системи читання можуть обмежуватись підтримкою ASC11. Деякі системи працюють також і з іншими стандартами. Звичайно ж, що Ви можете уникнути цієї проблеми підключивши шрифти з необхідними для Вашого epubs символами, проте, більшість людей не знають як це зробити. Для того, щоб ознайомитися з найпоширенішими питанням про Sigil, перегляньте статтю про FAQ. Мені складно підрахувати кількість людей, які говорили просто до неможливості некоректні речі, наприклад про те, що Sigil не підтримує Unicod, бо, книга, яку Вони зберегли, відображалась як сукупність знаків питання як у ADE, так і в усіх інших програмних рідерах, які використовують Adobe’s RMSDK.
І це не лише проблема Sigil, це спільна проблема. Люди розробили epubs, які пройшли тестування лише на iPad, і, оскільки, iBooks включають шрифти з більшою кількістю символів, ніж ADE, деякі символи, в кінцевому результаті, відтворюються у вигляді знаків питання.
Тому потрібно вказувати мінімальний об’єм символів. Адже, хтось може спитати, де ця межа? Чи повинна підтримка CJK бути обов’язковою? Де все таки границя? Ви маєте рацію, це складне питання. Саме над їх розв’язанням працює спеціальна робоча група. Надто важко встановити межу? Гаразд, а як щодо того, аби добавити ще одну з тих голосних заяв RFC 2119 про «рекомендацію» розширити покриття? Це нічого не змінить, але могло б.
Проблема в тому, що нікому у IDPF немає ані найменшого діла до цієї проблеми. Це все через те, що більшість працівників живуть у «країні ASC11», але ж ці люди розробляють міжнародний стандарт. Виявіть своє розуміння. Нестача необхідного покриття є набагато більшою проблемою для EUPB 2, ніж «я не можу закачати у свою книгу відео». І повірте мені, це саме так.

Життя у чарівній країні
Серед цих нових характеристик є безліч цікавих та захоплюючих речей, але це лише з першого погляду, адже вони ніколи не стануть реальністю. Наприклад, «обмежувач вмісту» для JavaScript, це ж просто чудова ідея, чи ipub-тригер, дещо необдумана думка, адже люди все одно будуть використовувати JS. Проте, всі ці ідеї ніколи не будуть підтримуватися різними системами зчитування, а навіть, якщо і будуть, то ніхто ними не користуватиметься. Люди, що розробляють RS (системи зчитування) здебільшого звичайні шахраї, які перевіряють базу клієнтів у веб-наборі і на тому закінчують робочий день, звичайно ж існують винятки. Так звані розробники не здатні навіть змодифікувати веб-набір, сумісний з певною epub-структурою. Для них це занадто складно. Невже я єдина, хто пам’ятає такі користувацькі елементи EUPB 2, як «switch» і «case», чи оперативні HTML-ділянки, чи всю DTBook. Єдиною системою зчитування, яка підтримувала все це була ADE, знімаю капелюха перед Adobe за гарну спробу. Всі інші просто вдають, що таких характеристик не існує. І навіть Adobe не впровадив підтримки «oeb-page-foot» («вниз сторінки») і «oeb-page-head» («вверх сторінки»), а це було б досить зручно, ну принаймні на папері.
З часом стало зрозуміло, що якби далеко не заходили характеристики EPUB і які б популярні браузерські новинки не впроваджували, їх просто ігнорували. Це ж занадто складно, хоча, звичайно, що ж ні. Це вимагає лише двох складових: компетентних розробників і людей, які у цьому зацікавленні. Як перші, так і другі дуже рідкісні екземпляри. Знайшли? Удачі! Ну і звичайно ж це вимагає ще одного: власне виконувати роботу. Не просто взяти вже наявну браузерську розробку, переробити її для відтворення HTML по-сторінках і назвати це все системою зчитування. Насправді потрібно розробляти програмне забезпечення і найскладнішою у цьому процесі є робота з величезною базою чужорідних кодів. Для більшості розробників це занадто складно.
Наприклад, мені доводиться працювати з HTML Tidy, оскільки це внутрішня складова Sigil. Не можу передати своєї радості, коли я дізналася, що для цього мені треба буде виконати аналіз HTML 5, і все це через EPUB 3. Мені шалено подобається ця перспектива. Вже сама ідея зводить мене з розуму. Але я зроблю це лише тому, що так треба. І заради всього святого, запам’ятайте різницю у якості коду WebKit і Tidy.
Tidy легко може посісти місце найгіршої бази кодів у світі. Адже, це – 40 кілометрів одних лише C, написаних просто жахливим способом; 800 рядків формул; приховані, однобуквені, змінні назви; надмірна кількість компіляторів; коментарі, які або вже застаріли, або просто не відповідають реальній суті речей. Це абсолютно непотрібне сміття, що залишилося від оригінальних розробок та їхніх наступників ще багато років тому. Сьогодні вже ніхто не працює на Tidy, принаймні не на офіційних проектах.
І все таки я працюю з Tidy лише тому, що мушу. Натомість, сотні людей працюють на WebKit, оскільки він дуже добре написаний. Розробники систем читання, пора вже щось робити!
Чесно кажучи, я думала над розробкою відкритої системи зчитування, як для desktop, так і для пристроїв з обмеженою пам‘яттю чи живленням, основною метою було, просто показати, як це робиться. В мене навіть було декілька геніальних ідей. Але я ледве знаходжу час для роботи над Sigil та FightCrew. Третій проект? Я скоріше застрелюся.
І навіть не просіть мене коментувати якість систем зчитування. Пам‘ятаю, коли ми ще скаржилися на ADE. Сьогодні, це – чи не найкраща доступна зчитувальна система. Зверніть увагу на те, що я сказала, «Найкраща доступна», але не «ідеальна». Сьогодні я б оцінила її на трійку. Всі інші отримають, у кращому випадку, двійку.
Кожен розробник epub скаже Вам, що найгірша ситуація з електронними книгами. Спитайте будь-чию думку про електронні книги і можете бути впевнені, що відповідь буде не вельми приємною для ваших вух. Apple любить хвалитися підтримкою відкритих стандартів і їх важливістю. А особливо, коли йдеться про придушення Flash. Що ж до характеристик EPUB, то їм навіть критика не потрібна. Не те, щоб їх розробники були лінивими, некомпетентними, чи не хотіли вкладати гроші у покращення підтримки EPUB. Це навіть не відсутність функціональності. Справа в тому, що вони цілеспрямовано зіпсували Mobile WebKit, для того, щоб продовжити свою програму. Якби вони зробили щось схоже з Safari, під час перевірки spellcheckers виникали б просто неймовірні казуси.
Проте, кількість людей, що створюють EPUB-книги, чи працюють у видавничій сфері, порівняно з кількістю веб-розробників, відносно мала. Вже не говорячи про те, що ми, як галузь, надто зайняті підлещуванням до Apple, аби помічати, що твориться навколо. Вони легко можуть закрити нам рота. Apple вимагає 30% усіх передплат, право на придбання внутрішніх програм і зниження цін. Але це вже остання крапля. І тепер ми провчимо їх.
Ви можете подумати, що я маю щось проти того, що робить Apple. Але це зовсім не так. Якщо хтось дозволяє себе експлуатувати, то чому б цим не скористатися. Apple використовує нас як галузь рівно настільки, наскільки ми дозволяємо себе використовувати. А зараз вони підходять все ближче і ближче і складається враження, що Apple просто дихають нам в спину. Як же це сталося? А справа в тому, що ми дозволили цьому статися, от і все. Крок за кроком вони добивалися цього ми дозволили їм прослизнути. І зараз звичайно ми були б не проти, щоб вони відступили. Але знаєте, досить складно вести переговори, коли співрозмовник на голову вищий за тебе і саме він диктує умови.

Але не про це мова, ми ж говоримо про EPUB 3.
А я й не помітила, як відхилилась від теми. Оскільки я вже стомилася, наведу ключові аспекти аналізу:
Значний наголос варто зробити на доступності. Це добре, що люди розуміють, якою знахідкою є електронні книги для людей з поганим зором. Раніше цій проблемі теж приділяли увагу, проте зараз це набуло ще більших масштабів.
Таблиця стилів xml, а чи дійсно вона потрібна? Цікава і несподівана розробка, проте, я сумніваюся, що будь-яка система зчитування зможе її підтримувати.
«Ця схема є нормативною, проте, якщо виникають певні суперечності між текстом специфікації та схемою, останню варто розглядати як визначену». Принаймні тепер ми знаємо, яка саме схема вважається визначеною. Повірте, що Ви стикнетеся з цією проблемою, як тільки спробуєте підключити верифікатор. А як щодо NVDL, RELAX NG та Schematron? Можна сказати, що Вам доведеться використовувати Jing. Дехто буде проти цього. Тоді, як щодо забезпечення HTML-схеми, це ж стандартна програма? Чудово, тепер мені доведеться взятися ще за один проект.
Додаткові ресурсі за силками на метадані? Звучить привабливо. Елементи метаданих DCMES потрохи витісняються можливостями DCTERMS. І це дійсно гарна ідея, нова система буде набагато гнучкішою. Перехідний період буде не найприємнішим, але нікуди від цього не дінешся. Варто наголосити як на заміні, так і на переході. «Хоча при опублікуванні EPUB вимагаються навігаційні документи EPUB, включати чи не включати їх у корінець книжки залежить від Вас». Це усуне потребу у цих жахливих контурних TOC’s, які всі так люблять створювати і, які, зазвичай, закінчуються побудовою двох різних файлів, що описують TOC. Тепер NCX – це документ XHTML, який можна редагувати. Якщо Ви дійсно хочете отримати цей документ у форматі придатному для читання, додайте його у корінець книжки.
«Page-spread-left» («розгорнути сторінку вліво») і «page-spread-right» («розгорнути сторінку вправо»). Непогана опція, проте чи для багатьох книжок використовують двосторінковий режим відображення?
Вмонтована підтримка MathML, це просто чудово. Тепер нікого не турбуватимуть обмеження накладені IDPF на її використання. Якщо система читання і буде підтримувати MathML, то лише через рушій виведення.
Меню для відображення списку сторінок підтримує взаємовідношення між epub та кількістю сторінок опублікованого видання. Це досить важлива опція, яку будуть використовувати видавці, і, яку, відповідно, повинні підтримувати системи читання.
Меню для відображення орієнтирів замінить OPF-путівника. Це теж дуже добре вдосконалення.
Медіа додатки. Ви можете спокійно ігнорувати наявність великої кількості медіа додатків. Я дійсно хочу сказати, що не варто навіть читати їх. Поводьтеся так, наче їх там нема, адже, ніхто й так ніколи їх не підключить. А оскільки їх підтримка є вибірковою, то ніхто не зобов’язаний їх впроваджувати. Ця ідея з самого початку була утопічною, так само, як і синтаксис DNBook у EPUB 2 OPS. Зрозумійте мене правильно, це було б просто чудово, якби системи читання підтримували такі впровадження, але цього ніколи не буде. Ніхто ще не заробив на тому, що зіпсував візуальний вигляд свого продукту.
Традиційні ідентифікатори фрагментів.
Ця інформація заслуговує на те, що б її виділили в окремий абзац.
Ідея з традиційними ідентифікаторами фрагментів звучить просто смішно, принаймні у такому представленні. Якщо сказати більше, вона близька до абсурду. Взяти до уваги хоча б перераховані індекси: не бути чутливим до керування HTML-розбору пробілів, посилань на об’єкти та CDATA-параграфи. Це аж занадто надумано. В рамках цієї розробки є не лише виділення елементів та їхнього текстуального змісту, що дійсно є вартим уваги, а, і виділення піксельних та растрових зображень, логічних одиниць у векторних зображеннях, тимчасових позицій в аудіо та відео і, якщо я правильно зрозуміла, правил вживання знаків оклику та навіть підтримка переходів між документами.
Ви просто не можете втиснути це все в одну схему. WG варто припинити свої намагання виділяти текстуальний зміст. Написана таким чином схема CFI необдумана і нагадує мені не менш дурнувату схему SVG 1.2. Більшість не знає, що SVG вимагає дивних розеток та підтримки передачі файлів. У специфічних робочих групах є доволі дивне бажання, підтримувати кожну-кожнісіньку ідейку. Здоровий глузд виходить за двері і ніхто вже не в змозі відмовитись від чергової нісенітниці.
Ця CFI-схема просто абсурдна. Ніхто не підтримає такий варіант розробки. Принаймні я точно цього не зроблю.
Висновки.
От і все, я закінчила. EPUB 3 непогана розробка, проте більшість з її характеристик або будуть використовуватися не за призначенням, або не використовуватимуться взагалі. Звичайно, що не можна цілковито звинувачувати у цьому IDPF, проте це частково їхня помилка. Ті нововведення, які люди таки підтримають, це меню для перегляду списку сторінок замість NCX чи DCTERMS замість DCMES.
Але що я знаю про це все.

Розповісти

Share this

Яндекс.Метрика