Dlaczego ebook źle wyświetla się na czytniku?

Ebook, który na jednym urządzeniu wygląda dobrze, a na innym się rozjeżdża, nie jest ofiarą „dziwnego czytnika" – jest ofiarą kodu, który zostawia zbyt wiele przypadkowi. Czytniki naprawdę różnią się interpretacją plików, ale porządnie zrobiony EPUB wygląda dobrze na wszystkich. Oto najczęstsze objawy, ich przyczyny i trwałe naprawy.

Objaw 1: rozjechane odstępy, „sklejone" lub porozrywane akapity

Przyczyna: stylowanie inline i śmieciowe klasy z eksportu. Konwertery i eksporty (Word, InDesign bez czyszczenia) generują dziesiątki klas typu para-style-override-3 oraz style przypisane do pojedynczych akapitów. Część czytników je honoruje, część ignoruje, część interpretuje po swojemu – stąd loteria.

Druga częsta przyczyna: „odstępy enterami" – puste akapity i wymuszone łamania <br/> zamiast marginesów w CSS. Na małym ekranie potrafią wygenerować pustą stronę w środku rozdziału.

Naprawa: czyszczenie kodu do prostej, semantycznej struktury + jeden przemyślany arkusz CSS dla całej książki. Zero stylów inline. To dokładnie ten etap konwersji, którego pominięcie odróżnia plik „z automatu" od pliku zrobionego porządnie (jak wygląda pełny proces).

Objaw 2: fonty nie działają / szeryfowa elegancja zamienia się w systemowy default

Przyczyny – trzy różne:

1. fonty niedołączone do pliku (CSS się do nich odwołuje, ale w paczce ich nie ma → błąd walidacji i fallback na font systemowy),
2. fonty dołączone, ale czytnik domyślnie używa własnych (użytkownik może to przełączyć; na niektórych platformach trzeba zadeklarować użycie fontów wydawcy w ustawieniach pliku),
3. fonty dołączone bez licencji na osadzanie – to nie problem wyświetlania, tylko prawny, ale wypływa przy kontroli.

Naprawa: osadzenie fontów z licencją (albo bliskich odpowiedników z legalnych bibliotek), poprawne @font-face, deklaracja w metadanych – i świadomość, że czytelnik ma prawo nadpisać typografię. Dobry skład wygląda dobrze także fontem systemowym.

Objaw 3: „krzaczki" zamiast polskich znaków

Przyczyna: kodowanie inne niż UTF-8 (pamiątka po starych plikach źródłowych) albo font bez polskich glifów – ą, ś, ź wyświetlają się wtedy fontem zastępczym lub jako znaki zapytania.

Naprawa: konwersja plików do UTF-8 z poprawną deklaracją oraz fonty z pełnym zestawem polskich znaków (przy fontach z bibliotek internetowych zawsze sprawdzamy podzbiór latin-ext).

Objaw 4: ilustracje gigantyczne, mikroskopijne albo rozmyte

Przyczyny: brak wymiarowania w CSS (czytnik pokazuje obraz 1:1 – skan 3000 px zajmuje trzy ekrany), wymiary zaszyte w pikselach w HTML, albo obrazy o zbyt małej rozdzielczości rozciągane do szerokości ekranu.

Naprawa: skalowanie względne w CSS (obraz maksymalnie na szerokość ekranu, wysokość automatyczna) + rozsądna rozdzielczość źródeł – w praktyce 640–1000 px szerokości zależnie od szczegółowości grafiki; mapy i schematy z drobnym tekstem bliżej górnej granicy. Przy okazji pilnujemy wagi pliku: nieoptymalizowane ilustracje to główny powód, dla którego ebook waży 80 MB, wolno się pobiera i odbija od limitów dystrybutorów.

Objaw 5: książka „tnie się", wolno otwiera, czytnik zawiesza się przy kartkowaniu

Przyczyna: cała książka w jednym ogromnym pliku XHTML. Czytniki (zwłaszcza e-ink) renderują pliki w całości – pojedynczy plik o wielkości setek kilobajtów potrafi zamrozić urządzenie.

Naprawa: podział treści na pliki per rozdział (duże pliki dzielimy także wtedy, gdy rozdział sam w sobie jest bardzo długi). Efekt uboczny: szybsze otwieranie, sprawniejsza nawigacja i mniejsze ryzyko utraty pozycji czytania.

Objaw 6: na Kindle wygląda inaczej niż w Apple Books / aplikacji księgarni

Przyczyna: różne silniki renderowania + różny zakres obsługi CSS. To normalne – ale skala różnic zależy od jakości pliku. Kod prosty i semantyczny renderuje się niemal identycznie wszędzie; kod barokowy – loteryjnie. Osobny przypadek to pochodne formaty (MOBI/KPF): dziedziczą problemy źródłowego EPUB-a i dokładają własne ograniczenia.

Naprawa/profilaktyka: projektowanie „na najsłabsze ogniwo" – prosty CSS o szerokiej kompatybilności i test na realnych urządzeniach przed publikacją: czytnik e-ink, telefon, tablet. U nas próba na czytniku jest częścią każdego zlecenia, obok walidacji EPUBCheck i Ace.

Objaw 7: czytelnik zmienia rozmiar czcionki i skład się sypie

Przyczyna: rozmiary zaszyte w pikselach, sztywne wysokości ramek, pozycjonowanie absolutne – czyli walka z naturą formatu reflowable.

Naprawa: jednostki względne (em, %), zero sztywnych wysokości. Skalowalność tekstu to nie tylko wygoda – to wymóg dostępności WCAG, którego brak wyklucza plik z rynku po pełnym wejściu wymogów EAA. Jeśli układ strony naprawdę jest treścią (album, komiks) – to sygnał, że tematem jest fixed-layout, nie łamanie reflow na siłę.

Diagnoza w 10 minut – zanim zlecisz naprawę

1. Otwórz plik w 2–3 środowiskach (czytnik e-ink, telefon, aplikacja desktopowa) – problem wszędzie czy tylko w jednym?
2. Przepuść plik przez EPUBCheck – błędy struktury często odpowiadają też za wygląd.
3. Zajrzyj do środka (EPUB to ZIP): dziesiątki klas override w CSS i style inline w HTML = diagnoza gotowa.
4. Sprawdź wagę pliku i ilustracji.

Z taką diagnozą rozmowa o naprawie – z nami czy kimkolwiek – jest szybka i konkretna.

FAQ

Czy da się naprawić wyświetlanie bez ruszania treści? Tak – naprawa dotyczy kodu i CSS, nie tekstu książki. Redakcyjnie plik pozostaje nietknięty.

Czy problem może być po stronie czytnika? Zdarza się (stary firmware, egzotyczne aplikacje), ale zasada jest prosta: jeśli plik źle wygląda na więcej niż jednym urządzeniu – problem jest w pliku.

Mam kilkaset tytułów z tymi objawami po starym konwerterze. Co teraz? To scenariusz na masową remediację – powtarzalne błędy naprawia się procesem, nie plik po pliku. Przy okazji domyka się zgodność z EAA.

---

Ebook wygląda źle, a czytelnicy to zgłaszają? Naprawiamy pliki – od kodu i CSS po walidację i test na urządzeniach. Prześlij plik do wyceny → Chcesz najpierw sam zajrzeć do środka pliku? Otwórz go w darmowym czytniku i zobacz podgląd oraz metadane.