czwartek, 12 stycznia 2017

Przez chmurę czy po kablu?

W tym wpisie podejmę temat sposobów dostarczania e-booków na czytniki Kindle.

Podstawowe założenie to skupienie się na formacie KF8 (AZW3) z całkowitym ignorowanie starego formatu MOBI 6. Przyczyny takiego założenia są oczywiste – MOBI 6 (obecny w pliku hybrydowym) i EPUB (niestety też często obecny w pliku hybrydowym) to zwykły balast, całkowicie niewykorzystywany przez czytnik. Dla e-booków, które posłużyły do testów na potrzeby tego artykułu nie ma to dużego znaczenia – pliki są relatywnie małe. Zdarzają się jednak „zawodnicy wagi ciężkiej”, czyli e-booki zajmujące po kilkadziesiąt MB – wtedy balast może dokuczyć.

Poniżej omówię dwie (i pół) metody na wrzucenie książki na czytnik i co wynika z wyboru jednej lub drugiej.

Temat był już podejmowany przez Roberta Drózda – Mailem czy po kablu? Porównanie dwóch metod wrzucania książek na Kindle – jednak wpis ten ma już kilkanaście miesięcy (od ostatniej aktualizacji) i jest tam kilka stwierdzeń, z którymi nie mogę się zgodzić, choćby takie – cytat: „Przesyłanie po kablu może w pewnych sytuacjach dać po prostu ładniejszy wygląd książki”. Jest ono semantycznie prawdziwe, ale przy poprawnym pliku nie ma możliwości by książki wyglądały inaczej, przynajmniej dopóki interesuje nas wersja KF8 (i tylko taka).

Omawiane metody

Przez chmurę, czyli wysyłając na przypisany do czytnika adres mailowy z akceptowanych adresów nadawcy (zdefiniowanych w ustawieniach na koncie w Amazon) lub poprzez aplikację „Send To Kindle”.

Po kablu, kopiując po prostu e-book do katalogu „documents” (może być do podkatalogu w tym katalogu).

Po kablu z wykorzystaniem programu Calibre – nie stosuję, ale dla porządku wspomnę. Szczególnie, że taka metoda jest wskazana dla osób nietechnicznych, a jednocześnie daje przyzwoity rezultat.

Ograniczenia

Czasami nie ma wyboru. Do przesyłki po kablu potrzebujemy… kabla. Zdarza się (jednym rzadko, innym częściej), że akurat nie mamy żadnego „pod ręką”. Z kolei do odebrania książki dostarczonej bezprzewodowo potrzebujemy albo czytnika w wersji z 3G, albo dostępu do sieci WiFi (w warunkach miejskich nie powinno być z tym problemu, ale…). W takich sytuacjach korzystamy z jedynej dostępnej metody.

Co daje wybór wysyłki do chmury?

Przede wszystkim synchronizację pomiędzy różnymi czytnikami i programami Kindle (np. na Androida). Synchronizowane są zarówno notatki i podkreślenia, jak również postęp czytania.

Sam fakt umieszczenia książki w chmurze pozwala na odroczone czytanie, bez „zaśmiecania” pamięci czytnika czymś, co będzie czytane np. za pół roku.

Automatyczna wysyłka na mail może być realizowana bezpośrednio przy zakupach w księgarniach, co pozwala na dostarczenie książki np. wprost ze smartfona, bez udziału komputera.

Pliki jakie trafiają na czytnik z chmury są mniejsze niż takie same wrzucone po kablu – konkretne przykłady w dalszej części tekstu.

Chmura Amazona modyfikuje przesłane pliki, między innymi optymalizując je pod docelowy czytnik i wycinając elementy niezgodne z formatem (np. nieużywane style, skrypty itp.). To dla niektórych wada, ale niezaprzeczalnie tak obrobiony plik jest najlepiej przystosowany do odtwarzania na czytniku.

Co daje wybór kabla?

Złudne poczucie prywatności.

Poza tym: nic. Chyba że…

Przesyłając e-booki po kablu, poprzez program Calibre, można w łatwy sposób zapewnić sobie przyzwoity wygląd tekstu, okładkę (wyświetlaną w Bibliotece czytnika) i numery stron bez dodatkowych kombinacji. Calibre jednak jest dość agresywnym programem i nawet przy tak niewinnym wykorzystaniu dorzuca do pliku informacje o sobie. To małe przewinienie w porównaniu z tym, co robi przy konwersji (Sieczkarnia calibre w akcji. Porównanie do kindlegena.), ale i tak irytujące.

Ofiary… czyli pliki testowe

Do testów wybrałem dwie książki z serwisu Wolne Lektury:

  1. Groźny cień Arthura Conana Doyle'a;
  2. Wehikuł czasu Herberta George'a Wellsa.

Pobrałem pliki MOBI i dla wyrównania szans, na potrzeby przenoszenia po kablu, wypakowałem wersje KF8 narzędziem mobiunpack.py. Do chmury wysyłałem pliki takie jak były pobrane z serwisu WL.

W obu przypadkach wygląd e-booków był identyczny, a przykładowe screeny poniżej:

Czcionki wydawcy i jak widać skład jest elegancki – justowanie, podział wyrazów, polskie zwyczaje typograficzne (np. wcięcie akapitowe o wielkości 1,5 firetu). Dawniej wiele osób miało krytyczny stosunek do plików z Wolnych Lektur (np. TUTAJ), ale to już przeszłość. Dziś WL to jedno z niewielu miejsc w sieci (wliczając księgarnie), z których mogę komfortowo czytać książkę bez „przemielenia” jej choćby narzędziem epubQTools.

Okładki, numery stron…

W skrócie: nie ma. Bez względu na to czy wrzucam pliki AZW3 (wypakowane z hybrydowych MOBI) po kablu, czy pobieram książki z chmury.

Obie te niedogodności poprawiam sobie skryptem Extra Kindle Tools. Podobnie zadziała też ExtractCoverThumbs (tym razem pliki mają fałszywy ASIN wygenerowany w Calibre, ale nie zawsze tak będzie). W przypadku obu tych narzędzi generowanie stron działa bezproblemowo, natomiast generowanie okładek jest bezproblemowe tylko dla wersji wrzuconej po kablu. W przypadku wersji z chmury, aby zobaczyć okładki, potrzebny jest hmmm… patch o którym wspomniałem w poprzednim artykule – bez niego zarówno EKT, jak i ECT okładkę wygenerują, ale czytnik jej nie wyświetli.

Używając eksperymentalnej opcji (--patch-azw3) w nowych wersjach ExtractCoverThumbs, można mieć okładki dla książek z chmury, bez używania powyższego patcha, kosztem synchronizacji – przy używaniu tylko jednego czytnika ma to sens. Osobiście czytam wyłącznie na Voyage, choć sam dostęp do biblioteczki Kindle (pozycji w chmurze) mam jeszcze na trzech innych urządzeniach.

Inne elementy…

Wszystko co jest związane z wyglądem e-booka, przy prawidłowym składzie, działa tak samo, bez względu na drogę dostarczenia na czytnik. Takie elementy jak dzielenie wyrazów, blokowanie „sierotek” czy sposób formatowania akapitów są zdefiniowane w pliku i nie ulegają żadnym zmianom przy wysyłce mailowej.

Skoro więc nie widać różnic, to dlaczego wybieram wyłącznie metodę bezprzewodową? Chodzi o optymalizacje dokonywane w chmurze, które między innymi objawiają się rozmiarem pliku jaki finalnie trafia na czytnik. Dokładne liczby:

Pozycja:      MOBI hybrydowy (z serwisu):      AZW3 z mobiunpack.py:      Plik z chmury:
Groźny cień      847 790 B (828 kB)      597 193 B (583 kB)      457 132 B (446 kB)
Wehikuł czasu      654 992 B (640 kB)      509 793 B (498 kB)      338 836 B (331 kB)
…i dla podkreślenia różnic…
Airport City. Strefa okołotniskowa jako zagadnienie urbanistyczne. Monografia.
     40 800 303 B (38,91 MB)★      21 739 164 B (20,73 MB)      8 348 660 B (7,96 MB)

★ W trakcie pisanie tego artykułu próbowałem pobrać tę pozycję jeszcze raz. Plik MOBI pobrany prosto z księgarni ma rozmiar 18 784 863 B (17.91 MB), ale…
…pliku tego nie można rozpakować skryptem mobiunpack.py, a Kindle Previewer nie wyświetla go – w obu przypadkach komunikat informujący o tym, że wskazany plik nie jest plikiem MOBI, a program file podpowiada, że to… EPUB. Tak więc „poprawili”. Oczywiście upewniłem się co pobieram, więc o przypadkowym kliknięciu nie tam gdzie trzeba nie ma mowy. Tylko dla formalności wspomnę, że oczywiście czytnik nie widzi takiego pliku.

Podsumowanie

Jeszcze niewiele ponad pół roku temu, w czasach wersji FW 5.7.4 czy jakoś tak, używałem niemal wyłącznie metody „po kablu”. Dziś 99% książek wrzucam przez chmurę. Ten brakujący 1% to sytuacje, gdy nie mogę tego zrobić z przyczyn technicznych, czyli w praktyce kiedy jestem przez dłuższy czas (kilka dni) bez dostępu do sieci (WiFi).

Dla przesyłek do chmury istnieje sztywny limit 50 MB na mail, ale Amazon najwyraźniej mnie lubi, bo spokojnie przesłałem (tydzień temu) książkę ważącą 65 MB i doszła bez problemów (oczywiście na czytniku odpowiednio mniejsza). Albo to był jakiś bug, albo ograniczenie nie jest takie sztywne.

wtorek, 3 stycznia 2017

Extra Kindle Tools

Przedmowa

Extra Kindle Tools to narzędzie, które pozwala na zrobienie porządku na czytniku Kindle, bez konieczności podłączania go do komputera. Na pomysł stworzenia takiego narzędzia „wpadłem” w połowie grudnia 2016 roku. Źródła znajdują się na github-ie (github.com/AthameBook/EKT/).

Projekt pierwotnie bazował na PC-owym narzędziu ExtractCoverThumbs stworzonym przez Roberta Błauta (znanego też jako quiris), który w swoim projekcie korzystał m.in. z pracy Johna Howella (obsługa formatu KFX) czy Charlesa M. Hannuma oraz Pawła Jastrzębskiego (autorów kindle_unpack).

ExtractCoverThumbs miał jednak z mojego punktu widzenia kilka wad, z czego najpoważniejsza dotyczyła uzależnienia działania od obecności numeru ASIN (bez tego tytułowy „cover” nie powstawał) oraz działał z poziomu komputera.

Aktualną wersję, o możliwościach znacznie rozbudowanych względem ExtractCoverThumbs (z oryginalnego kodu pozostał głównie pomysł…), przygotowała @Becky, znana z forum eksiazki oraz z tłumaczenia interfejsu Kindle na język polski. Ja w tym układzie robiłem za „natręta”, który zasypywał pytaniami quirisa oraz dopingował pracę @Becky. No dobra, moja rola nie była do końca tak bezproduktywna – przygotowałem niezbędny składnik całości – pythona 2.7 działającego bezpośrednio na czytniku wraz z modułem Pillow.

Beczka dziegciu…

Extra Kindle Tools to nie jest samodzielne narzędzie. Do działania wymaga pythona wraz z niestandardowym modułem. O ile na PC nie stanowi to żadnego problemu, o tyle na czytniku już nie jest tak miło. Do tego trzeba zastosować jakiś „wyzwalacz” lub powiązać wykonanie z jakimś zdarzeniem. Osobiście dodałem do systemu polecenie „ekt”, które wykonuje skrypt.

Niedogodność to brak generowania okładek dla niektórych e-booków w formacie KFX – tych które informacje o okładce mają w części zaciemnionej DRM-em. Na szczęście to mniejszość w Kindle Store, ale i tak irytuje. Oczywiście nie wygeneruje okładki, jeśli takowej nie ma zaszytej w pliku (jeden przykład w filmie demonstracyjnym).

Dodatkowo domyślnie cierpi na tę samą złośliwość, zafundowaną przez Amazon, co ExtractCoverThumbs – od wersji oprogramowania Kindle FW 5.8.5, wszystkie własne pliki pobrane z chmury trafiają na „czarną listę” – nie można dla nich wygenerować okładki, a dokładniej można, ale czytnik z niej nie skorzysta (nie wyświetli się w Bibliotece).

Osobiście stosuję pewien skomplikowany mod, który niweluje ten efekt, ale niestety zrobiłem go dość intuicyjnie, przy okazji kilkanaście razy brickując czytnik (nawet kiedy już wiedziałem co robić) – po prostu modyfikowany plik (/opt/amazon/ebook/lib/kaf.jar) jest z jednej strony wrażliwy na zachowanie integralności (nie można bezkarnie w nim „grzebać”), a z drugiej jest niezbędny do prawidłowej pracy czytnika (ładuje się jako jeden z pierwszych). Co gorsza jest nieprzenośny pomiędzy różnymi egzemplarzami czytnika, chyba że pochodzą one z tej samej partii produkcyjnej tzn. poprawny plik z PW3 zadziała na niektórych innych PW3, ale nie na każdym.

Z uwagi na powyższe problemy taki mod funkcjonuje aktualnie na tylko dwóch czytnikach w Polsce i z dużym prawdopodobieństwem także na Świecie. Przydałby się jakiś hacker, który zrobi to porządnie, bo brak okładek dla PDOC-ów jest strasznie irytujący. Nawet pomimo domyślnego upośledzenia w tym względzie, Extra Kindle Tools to nadal przydatne narzędzie, o czym poniżej.

Beczka miodu…

W przeciwieństwie do ExtractCoverThumbs, Extra Kindle Tools działa nie z poziomu komputera, a z poziomu czytnika. Przez to nie tylko uniezależnia nas od kabla, ale też może korzystać z danych ukrytych w systemie, a niedostępnych z poziomu PC. Dzięki temu działa niezależnie od obecności numeru ASIN (ExtractCoverThumbs pomija takie pliki) i generuje okładki dla każdej książki, dla której to możliwe (pomija PDF-y i wymaga jedynie tego by jakakolwiek okładka była w pliku).

Po ExtractCoverThumbs odziedziczył także generowanie numerów stron – zgrubnym algorytmem, nie przez pobieranie tej liczby z serwisu Lubimy Czytać – to spowalnia drastycznie pracę, a efekt i tak nie jest precyzyjny, bo księgarnie często dodają stronę lub dwie z informacjami o „znaku wodnym” – co przekłamuje wynik, a dla publikacji zawierających grafiki czy tabelki, strony i tak nie będą się pokrywać – słowem: więcej wad niż pożytku.

Ma jednak więcej funkcji – przede wszystkim moduł czyszczący czytnik z:

  • folderów .sdr będących pozostałością po usuniętych już książkach;
  • pustych folderów;
  • okładek dla książek, których już nie ma na czytniku;
  • plików tymczasowych (.partial, _ASC itp.);
  • plików wininfo_screenshot*.txt tworzonych wraz z zrzutem ekranu.

W skrócie – dba o porządek na czytniku.

Działanie w praktyce