Hmm, werde wohl trotzdem in Zukunft und in ePub3 <em> usw. benutzten, statt <i> usw. Mir gefällt die Logik. 😉
Hab gerade mal ein wenig ge-Wikipediat und dort stand, dass XHTML5 auch noch nicht fertig ist (Working Draft).
Mit <em> ist doch alles in bester Ordnung, da es allgemein eine einfache Betonung, Hervorhebung gegenüber dem übrigen Text kennzeichnet. Solange es nicht für mehrere verschiedene Arten von Betonungen gleichzeitig verwendet wird, entspricht dies durchaus einem semantischen Gebrauch, zumal es dem Anzeigesystem überlassen wird, mit welcher visuellen Repräsentation eine solche Betonung hervorgerufen werden soll. <em> aber einfach
statt <i> zu verwenden, kommt den Anforderungen an semantische Encodierung aber nicht nach, denn <i> würde dann auch nur
anstatt der tatsächlichen Bedeutung eingesetzt werden. Ja, an HTML5 kann im Zweifel noch herumgeschraubt werden, weshalb das mit der 100%-EPUB3-Unterstützung ohnehin keine besonders realistische Forderung ist.
Und ich hoffe doch, dass noch jemand außer Amazon sich mit AZWs beschäftigt, wir sind doch hier um Erfahrungen auszutauschen, oder?
Es gibt zwar Programme, mit denen man Mobi/AZW im Moment (!) erzeugen kann, aber wenn Amazon morgen entscheidet, das Format zu ändern und seine Reader darauf umstellt, kann es schwer bis unmöglich werden, Mobi/AZW auch unabhängig vom Kindle-Ökosystem (Kindlegen) zu erstellen. Aus diesem und aus anderen Gründen sind offene Standards grundsätzlich zu bevorzugen.
Oh, hängt euch doch an dem <i> im Editor auf. Sigil hat übrigens genaus das <i>-Tag gesetzt. Calibre setzt in der Konveriterung etc. aber gar keine direkten Formatierungen sondern CSS. Wüsste gerne mal welche Software hie besser sein soll. Jutoh lässt vermutlich auch <i>-Tag für kursiv setzen. Und da die Reader das offensichtlich schlucken scheint es okay zu sein. Und wenn einer meint, dass solle lieber <e> sein, kann er ja mal gerne den Calibre-Entwickler anschreiben. Hast du das gemacht? Bevor du hier im Forum rumeckerst?
Weder Calibre noch Sigil noch Jutoh noch sonst irgend eine Software auf der ganzen weiten Welt ist in der Lage, die fehlende Hinterlegung der Bedeutung irgendwie magisch zu erraten. Es gilt wie immer das Grundprinzip „garbage in, garbage out“ der theoretischen Informatik. Die reine Auslagerung von Direktformatierung nach CSS löst das Problem in keiner Weise, das Ergebnis wird allein deshalb noch lange nicht semantisch und qualitativ verbessert (mein Ansatz ist dementsprechend, vom Bedienkonzept her von vornherein die semantische Formatierung vorzugeben). Es gibt die offizielle Spezifikation der EPUB-Standards – wer sich nicht daran hält, darf auch nicht erwarten, dass seine EPUBs fehlerfrei oder gar überhaupt verarbeitet bzw. angezeigt werden (dieses Problem haben nicht wenige Leute). Ein Lesegerät oder Lesesoftware sollte so tolerant wie möglich mit den Eingaben umgehen, Konvertierprogramme müssen sich aber unbedingt an die Vorgaben halten, um diese Toleranz nicht auszureizen, auszuweiten oder zu übertreten (man denke nur mal an die Entwicklung von HTML im Browser). Und obwohl es überhaupt nichts zur Sache tut, weil das IDPF den EPUB-Standard definiert und nicht etwa Calibre oder Sigil, kannst du trotzdem mal, wenn du unbedingt willst, erst hier
und dann da
schauen. Wie man sieht, hatte ich sehr schnell keinen Bock mehr, mich länger mit diesem Unfug zu beschäftigen. Und ich will im Hinblick auf das Thema dieses Threads besonders darauf hinweisen, dass die Profis sich unter anderem gerade deshalb mit so etwas beschäftigen müssen, weil die vorhandene Auszeichnung im E-Book unbrauchbar ist.
