Jinke Hanlin a vleklá chyba s češtinou v epub

Zklamali mne čeští distributoři těchto čteček e-knih, jelikož o docela podstatném problému, jakým je nezobrazování korektních českých znaků v případě knih ve formátu epub, vědí řádově roky, a doteď ho nebyli schopni vyřešit. Problém spočívá v tom, že software určený k prohlížení epub souborů používá font bez některých českých znaků s diakritikou. Paradoxně, byť čtečky jako takové umožňují změnu fontu, v případě formátu epub to nejde (ten software to neumožňuje).

Nejnovější anglický firmware již umí u epub měnit font, česká varianta firmwaru ale není dostupná (byť byl čas od dubna 2011, kdy firmware vyšel) a anglický firmware nemá (překvapivě) podporu pro český jazyk.

Nouzovým řešením je upravit e-knihu, aby používala jiné fonty. Lze buď postavit fonty mimo epub a z něj se odkazovat na pevné umístění na kartě, nebo fonty „zadrátovat“ do knihy (pak je kniha v této podobě pěkně přenositelná). Obojí představuje nutnost upravit knihu, což není úplně triviální.

Za tímto účelem jsem pro vlastní potřebu vytvořil shellový skript, který fonty natvrdo zadrátuje do e-knihy. Kód není nic moc a nezaručuji, že to bude fungovat u všech e-knih. Stejně nezaručuji, že skript neudělá nějakou neplechu. Pokud jste ochotni se skriptem pracovat na vlastní riziko a s vědomím, že se jedná o nedostatečně otestovaný skript, kde mohou číhat příšerné chyby s možnými fatálními důsledky, můžete si jej stáhnout (5Kb) – v opačném případě nic nestahujte a alespoň pište rozhořčené e-maily českému distributorovi. Skript se používá se takto (vyžaduje to Bash, sed, zip a unzip a další běžné unixové nástroje):

./hanlinize mybook1.epub mybook2.epub

Je to špinavé řešení, ale třeba OpenMagazín to upraví korektně. Místního distributora těchto čteček bych rád pokáral za jeho netečnost. „Pěkné“ je také to, že aktuální český firmware nelze odnikud stáhnout (oficiální odkazy jsou mrtvé), a jelikož firmware nejde před změnou zazálohovat, je třeba případné experimenty s jiným firmwarem zvážit (přijdete o nejnovější verzi českého firmwaru, který tam už nedostanete, dokud se distributor nezmátoří a neupraví odkazy na svém webu). To také považuji za nešťastné. Přitom to jsou schopné a levné čtečky, navíc na Linuxu založené (i když to jsou asi všechny).

Kdybyste potřebovali výsledný epub upravit nebo zkontrolovat, můžete využít vynikající epub editor Sigil.

Zdroje a další informace:

Drupale, Drupale, ty jeden lumpe

Právě se zabývám nasazením Drupalu jako CMS v jednom svém projektu. Jelikož je již k dispozici stabilní vydání z nové řady 7.0, rozhodl jsem se použít právě to (nechtělo se mi použít verzi 6 a po čase řešit upgrade na sedmičkovou řadu). Samozřejmě nelze očekávat, že nová řada bude zcela bez chyb, nicméně je-li k dispozici stabilní vydání, domníval jsem se, že alespoň ty nejvíce do očí bijící chyby a nepříjemnosti budou odstraněny.

Pro realizaci řady pravidelných interních činnosti je v Drupalu použit cron. Jednou ze stěžejních funkcí, alespoň z hlediska bezpečnosti, je ověření stavu dostupných aktualizací, aby správce tušil, kdy vyšla bezpečnostní aktualizace, a kdy má CMS aktualizovat. Stav aktualizací se má zkontrolovat při běhu cronu. Bohužel se tak ale u sedmičkové řady neděje. Drupal vám sice říká, že máte spustit cron ke zjištění dostupných aktualizací, ale spuštění cronu stav nezkontroluje a hláška zůstává. Nezbývá tedy než aktualizace kontrolovat ručně.

Chyba byla nahlášena v prosinci roku 2009, Drupal 7.0 (stable) vyšel 5. ledna 2011, avšak chyba nebyla dosud (březen 2011) opravena. Samozřejmě si nesmírně vážím vývojářů Drupalu, Drupal samotný považuji za vynikající CMS a rozhodně nemám v úmyslu tento projekt nijak shazovat či kritizovat, jen se trošku podivuji nad tím, že takový problém nechali při vypuštění dlouho očekávané nové verze nevyřešený a že ani 3 měsíce po jejím vypuštění není k dispozici alespoň patch.

Význam svobody softwaru

V jedné dávné diskusi jsem byl dotázán, k čemu jako uživatel softwaru potřebuji svobodu. Dotyčný přišel s materiální analogií, tedy s příkladem konkrétního, fyzického nástroje, který si koupím, ale nedostanu k němu dokumentaci, jak byl sestaven. Daný nástroj používám, pokud mi vyhovuje, a pokud ne, koupím si jiný. Proč mi tato analogie přijde zcestná? A proč si myslím, že svoboda softwaru je klíčová?

Continue reading

Přátelé Open Source

Dnes jsem uzřel zprávičku o IBM, kterak hrozí patentovým sporem firmě, která vyvíjí open source software. Součástí patentového sporu jsou i dva patenty, které IBM přislíbilo open source vývojářům. V souvislosti s tím mne napadlo následující:

Open source nemá přátele. Pouze své tvůrce, uživatele, zneuživatele a nepřátele.

Pravdou je, že open source má kromě tvůrců a uživatelů své nepřátele – obvykle konkurenty z prostředí proprietárního softwaru. Jako zneuživatele bych viděl někoho, kdo začne na nějakém open source projektu rýžovat, aniž by cokoliv vrátil zpět původním lidem, z jejichž práce těží. Ale to je sporné – pokud dotyční daný software vydali pod jistými licenčními podmínkami, pak mohli s podobným scénářem počítat (dovoluje-li to licence), a tudíž se nejedná o zneužití.

Kdo je ale přítelem open source? Nejsem si jistý, kdo by tak mohl být označen (uživatel je uživatel, vývojář je vývojář…). Vím ale to, že přítelem open source rozhodně není entita, jejímž primárním cílem je dosažení zisku (tedy jakákoliv komerční společnost). Ta totiž bude stát za Open Source jen tak dlouho, dokud se jí to vyplatí, a jakmile se situace změní, bez jakýchkoliv rozpaků vytáhne nůž a vrazí mu ho do zad. Firmy podle mého nejsou a nemohou být přáteli Open Source. Zejména pak Ubersoft.