Vi trykker “eksportér”, så kører det

Lidt om, hvorfor “eksport til epub” fra DTP-software sjældent ender godt

(dette rant fra min gamle twitterkonto, har jeg nu efterfølgende har besluttet mig for at sammenskrive og udvide til dette lille indlæg. Kontekst: det omhandler primært reflowable epub. Og nej, PDF er ikke et e-bogsformat, i al fald ikke som jeg snakker om e-bøger i indlægget.)


Jeg hører tit “e-bøger? Er det ikke bare noget med at trykke på ‘eksportér’ i InDesign” (eller hvad man nu bruger til at layoute)?
Og svaret er “nej”. Ikke hvis man vil have et professionelt resultat.

“Men jeg trykkede ‘eksportér’ og den ser skidegodt ud”.

Jah. Jo.

Prøv et andet brugerscenarie.
Skift tekststørrelse.
Skift font.
Prøv en anden skærmstørrelse.
Et andet operativsystem.
En læsedims, som har nogle år på bagen.

Hvis du er heldig, crasher du ikke noget.

Men den skidegode e-bog ser ud som noget der er løgn flere steder undervejs, det garanterer jeg. (pssst, validerer den?)

Det korte af det lange er, at man ikke kan lave en god e-bog uden at kunne HTML/CSS som absolut minimum. Kan (eller i al fald forstår) du XML er du endnu længere. Vil du arbejde mere effektivt og gøre livet nemmere for dig selv, er det en god ting at kunne programmere i et simpelt, men overskueligt sprog som Python eller Ruby (andre sprog kan naturligvis også bruges).

Og endnu vigtigere: du skal tænkte strukturelt, for det er strukturen, der laver en god e-bog. Eller rettere, god struktur er grundforudsætningen for en god e-bog. Garbage In, Garbage Out. Din grunddata skal mærkes semantisk op. Overskriftniveauer skal tildeles ud fra semantiske overvejelser, ikke “den her skal være lidt mindre end den før”. Når du er nået dertil, kan du begynde at overveje at lave en e-bog. KISS HTML/CSS er vejen frem.

Pointen er: INGEN automatiseret eksport får dig derhen. De lader hånt om struktur (med mindre de bliver tvunget og selv da råber og skriger de JEG VIL IKKE! DU KAN IKKE TVINGE MIG! JEG VED BEDST!! hele vejen), og producerer divitis-inficeret HTML-kode, som guderne må vide hvordan opfører sig på forskellige platforme.

Og så er der de vildt inkonsistente læseapps. QA er branchens Sisyfos-opgave, og ca 46% af mine grå hår stammer derfra (men hey, min kone siger at de grå hår klæder mig).

Det korte af det lange: nej, det er ikke “bare lige” at eksporter en e-bog. Hvorfor tror I ellers at en kriseramt branche, som kigger overalt efter sparemuligheder ansætter specialister til at løse opgaven, hvis den bare kunne løses tilfredsstillende ved at en grafiker trykkede “eksport”?

Og for at det her ikke kun skal være mig, der brokker mig: denne liste er vanvittigt brugbar og et godt indblik i, hvad man skal være opmærksom på, når man designer en god e-bog.


Adobe vs Skynet

Når engang vi får udviklet en ond AI, som vil overtage magten over Jorden og underlægge sig menneskeheden, har vi heldigvis et es i ærmet:

AI: “I er MAGTESLØSE overfor mit overlegne intellekt. Underkast jer, menneskeskravl!”

Menneske: “VI ser og anerkender din overlegenhed. Faktisk har vi allerede skrevet et dokument, som overgiver dig al magt i verden.”

AI: “Som om jeg falder for det gamle trick – I har gemt en virus i dokumentet.”
[scanner]
“Det ser ud til at dokumentet er rent. Nuvel, jeg vil læse jeres overgivelse.”
[åbner dokument]
“Men … hvordan? … Jeg har … en positronisk … 1000-kernet … CPU … 1000 jottabye hukommelse … jeg …. jeg …
[crasher uigenkaldeligt]

Menneske: [trækker stikket] “Tak, Adobe! En 200+ siders Indesign-fil bringer enhver maskine i knæ.”

Find nålen i epub-høstakken

Forleden stod jeg overfor en interessant problemstilling. Jeg skulle blandt vores over 1000 epub-filer finde dem, der var lavet i fixed layout. Ja, vi havde noteret det, men var optegnelsen komplet og var der almindeligt reflowable epubs, der ved en menneskelig fejl var blevet indført som fixed?

Så hvad nu? Åbne hver enkelt fil og checke om den var fixed? Python to the rescue! Læs videre “Find nålen i epub-høstakken”