söndag 3 mars 2013

Får du DTD-fel från Indesign? Tips på lösning.

När man exporterar ut en EPUB från Indesign 5.5 eller tidigare versioner finns en bugg i alla xhtml-innehållsfiler.
Epubcheck ignorerar detta fel, men om man kontrollerar filen i FlightCrew får man meddelandet:
The file specifies an incorrect DTD. The correct public ID for the DTD is "-//W3C//DTD XHTML 1.1//EN", while the correct system ID is "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd". Do note that using a DTD is optional; but if used, it must be correct.

Överst i xhtml-filerna under xml-deklarationen finns en hänvisning till den DTD-fil som gäller. Den ska se ut så här:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

I EPUB-filen från Indesign ligger ett extra mellanslag mellan XHTML 1.1 och //EN som gör att länken till DTD-mallen inte fungerar. Man måste alltså ta bort detta extra mellanslag i länken, i alla xhtml-filer i boken. Vad som kan hända om det här felet ligger kvar är att udda tecken i boken (mjuka mellanslag exempelvis) inte kan tolkas rätt av läsarprogrammet (ex. iBooks på iPad) och det kommer upp ett felmeddelande på de sidor i själva boken där det udda tecknet finns när man läser den.

En lösning på det här problemet är att öppna EPUB-filen i Sigil och spara om den. Sigil rättar automatiskt den här buggen från Indesign. Men, ta en backupkopia av din EPUB-fil innan du sparar om den i Sigil om du inte skulle vara nöjd med resultatet, eftersom Sigil organiserar om din EPUB-fil en del.

Du som använder OxygenXML kan självklart rätta detta fel genom en search/replace.

Problem med epubcheck error från Pages? Tips på lösning.

Det verkar finnas en bugg när man skapar EPUB-filer från Pages som genererar ett långt felmeddelande i epubcheck innehållande typ:
...
element "div" not allowed here; expected the element end-tag, text or element "a", "abbr", "acronym", "applet", "b", "bdo", "big", "br", "cite", "code", "del", "dfn", "em", "i", "iframe", "img", "ins", "kbd", "map", "noscript", "ns:svg", "object", "q", "samp", "script", "small", "span", "strong", "sub", "sup", "tt" or "var"
...

EPUB-filen som skapas innehåller strukturfel i html-koden där en div-tagg läggs innanför en p-tagg. Jag hittade en diskussion på nätet med ett lösningsförslag som fungerar:
https://discussions.apple.com/thread/4580411?start=0&tstart=0

Jag har testat och det fungerar om man gör som de säger i diskussionen, dvs öppnar filen i Sigil och sparar den. Ta en backup-kopia av din EPUB-fil innan du sparar den i Sigil ifall du inte blir nöjd med resutatet därifrån.

Det kan hända att man måste redigera sin stilmall (css-filen) en del i Sigil när man har sparat om filen.

OBS! Kom ihåg att inte döpa vare sig bildfiler eller Pages-filen så att de innehåller en massa mellanslag, udda tecken eller å,ä,ö. Håll dig till a-z, 0-9 och bindestreck eller understreck så slipper du en massa problem.
Exempel:
Döp INTE en bildfil eller bokfil till "Döden på Nilen. 100% action.jpg"
Döp den i stället exempelvis till "Doden-pa-Nilen.jpg" eller "doden_pa_nilen_action.jpg" eller liknande. Alltså inga mellanslag, punkter, komman eller udda tecken.

onsdag 21 november 2012

Läsa bak och fram?

Fick härom dagen ett supportärende där jag fick lära mig något nytt.
En bok som öppnade sig bak och fram i Bluefire Reader men inte i någon annan läsare! Omslagsbilden dök upp först som vanligt när man öppnade boken, men sen var man tvungen att bläddra åt vänster.

Inget fel på EPUB-filen vad jag kunde se, så detektivarbetet började. Vad skiljer sig från en "normal" bok? Det låg tre språkkoder i opf-filen. Visst, man får lägga in flera språk i metadatan. Hm. Är någon av koderna felaktig? Kollade upp språkoder och identifierade en av koderna, ar-SA, som "arabic, Saudi Arabia". Då började det gå upp ett ljus... arabiska böcker läses bakifrån och framåt.
Språkkoden för arabiska låg före svenska och engelska i listningen, så jag ordnade om dem så att svenska låg överst. Då öppnade sig boken på rätt sätt. Heureka!

Är det här bra eller dåligt? Att arabiska var listat först spelade ingen roll i andra läsare som jag testade, t.ex. Digital Editions och iBooks. Rent spontant känns det inte rätt att läsriktningen styrs från metadatan. Kollar man i EPUB3-specen så finns attributet "page-progression-direction" som kan sättas i <spine> till ltr (left-to-right), rtl (right-to-left) eller default.

<spine page-progression-direction="rtl">
...</spine>

Men det här gäller alltså i EPUB3-filer. Lägger man in det i EPUB2 så blir det error i epubcheck.

Kunde förstås inte låta bli att testa att lägga in <spine page-progression-direction="rtl"> i en vanlig EPUB 2-fil och läsordningen ändras faktiskt i Digital Editions, iBooks och i Bluefire Reader. Rekommenderas dock inte! Kommer som sagt att bli error i valideringen.

Lägger man in page-progression-direction="ltr" samt språk arabiska och kollar i Bluefire Reader så visas sidorna från vänster till höger. Spine går före språk. Det verkar alltså som att det här med ändrad läsordning beroende på språk är en specialfix som Bluefire har infört i väntan på EPUB 3. Eller...

fredag 16 november 2012

Metadata i och kring en e-bok

Hur exponerar man idag en e-bok? Hur gör man den synlig? Ett av svaren är förstås metadata. Både den interna metadata som finns inuti själva EPUB-filen och den som jag kallar extern, dvs den som distributören skickar med till återförsäljare eller bibliotek, och som kopplas till boken med hjälp av till exempel ISBN.

Metadata är till för synliggörande, inte bara beskrivning. Det finns flera typer av metadata, t.ex. bibliografisk, kommersiell, distributionsrelaterad och butiksspecifik.
Grundläggande bibliografisk metadata kan vara ISBN, titel, författare, osv och den är både intern och extern.

Mycket av den externa metadatan tillkommer efter publicering och det är ofta läsarna som bidrar till den. Extern, kommersiell metadata kan vara Augustprisvinnare, bästsäljare, osv. Jag tror att återförsäljarna skulle kunna göra mycket på den här fronten genom att lägga till extern metadata på böckerna i sina butiker.

Jag lyssnade nyligen på ett föredrag som hölls av Laura Dawson, Product Manager for Identifiers på Bowker i USA. Enligt henne letar Google aktivt efter ISBN och prioriterar titlar som innehåller ISBN. Andra typer av identifierare som alltmer ökar i betydelse enligt Dawson är ISTC och ISNI. Båda dessa används aktivt av Wikipedia för att identifiera enskilda verk och författare och Google har visat intresse för att börja använda sig av ISTC.

ISTC (International Standard Text Code) är en identifierare på verksnivå.
ISNI (International Standard Name Identifier) identifierar en viss författare oavsett hur namnet stavas (exempelvis ryska namn som skrivs med latinska alfabetet). Även författare med samma namn kan skiljas åt med hjälp av ISNI. Organisationer och till exempel förlag kan identifieras med ISNI. Det är inte ovanligt att man ser ett förlagsnamn skrivas på två eller tre olika sätt.

lördag 12 november 2011

Ska man inkudera fonter i EPUB?

Som det ser ut just nu i skrivande stund så rekommenderar jag inte att man använder fonter i EPUB-filen. Man kan till exempel från Indesign välja att exportera med fonterna, och får då WARNING i epubcheck. Det är med andra ord inte något fel på filen, men en varning att det kanske inte kommer att fungera optimalt. Min erfarenhet är att det kan uppstå problem i olika läsarprogram och e-boksappar om man skickar med fonter, så avstå gärna från det.

Hur ska man göra då om man vill ha lite olika stilar i sin bok?
Jo, använd de så kallade basfonterna eller generiska fonterna som finns att tillgå i css, det vill säga
serif, sans-serif och monospace. Det brukar räcka för att få fram de olika känslorna man vill förmedla genom att använda sig av olika fonter. Observera att de generiska fonterna i css skrivs inte med "flärpar" som andra inkluderade fonter. Det ska med andra ord se ut enligt följande:

.minfontstil {
font-family: serif;
}

Det här är med andra ord FEL:

.minfelaktigafontstil {
font-family: "serif";
}

Fonter och EPUB3
I EPUB3 kommer fonthanteringen att ändras så att inkluderade fonter stöds enligt vissa kriterier (CSS Fonts Module Level 3). Det finns mer om det i EPUB3-specen
http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-css-fonts.

lördag 18 juni 2011

Om epubcheck och Oxygen

I den senaste versionen 12.2 av Oxygen XML (www.oxygenxml.com) ingår nu epubcheck, och man kan söka/ersätta i alla filer i den EPUB som är öppen (inte bara i en innehållsfil i taget som i tidigare versioner). Verkligen en stor förbättring av detta redan utmärkta program för alla som redigerar EPUB-filer ofta. Rekommenderas varmt!

onsdag 18 maj 2011

Använda epubcheck lokalt

Epubcheck är ett verktyg för att kontrollera att en EPUB-fil följer den standard som IDPF har satt. Epubcheck upptäcker en mängd olika typer av fel i en EPUB-fil. Det som kontrolleras är OCF container-struktur, att kodning är korrekt i OPF och OPS, och att allt bokinnehåll är korrekt refererat till via olika metadata-taggar. Epubcheck kan köras lokalt på datorn via kommandofönster eller on-line. Jag tänkte beskriva här hur man kör epubcheck lokalt på PC.

För att kunna köra epubcheck lokalt måste Java Runtime vara installerat (1.5 eller högre). Finns inte java installerat på datorn kan det hämtas via http://www.java.com/


Därefter behöver man ladda ned själva programvaran epubcheck. Den finns att hämta via http://code.google.com/p/epubcheck/. Välj där att ladda ned ”Stable build” och därefter den senaste versionen.

Alla filer som behövs för programmet ligger i ett zip-arkiv som man zippar upp till en mapp på sin c:-disk som heter till exempel ”epubcheck” (valfritt namn).

Köra epubcheck, steg för steg

1. Öppna ett kommandofönster genom att gå till Startmenyn. Öppna mappen Tillbehör och klicka på Kommandotolken.

2. I kommandofönstret som dyker upp skriver man efter prompten (>):
java –jar och ett mellanslag.



3. Öppna i ett fönster bredvid, den mapp där epubcheck-programmet finns nedladdat. Dra den fil som heter epubcheck-x.x.jar till kommandofönstret och släpp där (det som markeras med x i programfilen är den aktuella version av programmet som gäller, i detta exempel är det version 1.2). Skriv därefter in ett mellanslag efter programnamnet. Det ska då se ut enligt nedan.



4. Dra därefter den EPUB-fil som ska kontrolleras till kommandofönstret och tryck på retur.



5. Innehåller inte filen några fel får man meddelandet nedan.



6. Om EPUB-filen innehåller fel kan man få meddelanden ungefär som nedan.



De felmeddelanden som syns ovan betyder att:
- datumet som finns på rad 7 i filen package.opf inte är korrekt inlagt
- det är ett fel på rad 16 och 17 i innehållsförteckningen toc.ncx.
Detta är bara ett par exempel på felmeddelanden som kan uppstå.

Rätta en EPUB-fil

Arbetar man ofta med EPUB-filer som kan behöva rättas kan det vara värt att investera i till exempel programmet Oxygen XML (http://www.oxygenxml.com/) som är en xml-hanterare där man kan öppna en EPUB-fil och redigera direkt.

Ett något mer besvärligt alternativ är att dra ut en innehållsfil ur en EPUB via något zip-program, redigera, och sen stoppa tillbaka filen igen.

OBS! Zippa inte upp hela EPUB-filen eftersom det med stor sannolikhet blir fel när den zippas igen. En EPUB-fil är i själva verket en vanlig zip-fil, organiserad på ett specifikt sätt. Öppna zip-arkivet utan att zippa upp och dra endast ut den fil som ska redigeras ur zip-arkivet, redigera i någon texthanterare (anteckningar) och lägg tillbaka den igen.

Epubpreflight

Epubpreflight är ett program där man kollar sina EPUB-filer på exakt samma sätt som i epubcheck. Det epubpreflight framför allt gör är att kontrollera att EPUB-filens innehållsfiler inte är för stora. Textfilerna får inte överskrida 300KB okomprimerade och bildfiler ska inte överskrida 10MB. EPUB-filer som innehåller för stora filer kan nämligen inte alls öppnas på en del e-boksläsare.