Wie erzeugen Profis EPUBs von Manuskripten

Hallo zusammen,


kennt jemand den Workflow von Profis, um aus Manuskripten letztlich optimale epubs zu erzeugen?


Ich habe von einem freiberuflichen Lektor eine haarsträubende Verkettung von Word mit Sigil/Calibre und vor und zurück geschildert bekommen und kann nicht glauben, dass man so arbeiten möchte.
Wichtig scheint wohl zu sein, dass Autoren und Lektoren Formate sauber austauschen können, deshalb wohl Word ?!
Ist das denn dann überhaupt ordentlich weiterzuverarbeiten?
Und dann Sigil oder Callibre zur Generierung? Hört sich für mich nur nach dem halben Weg an, oder?


Vielleicht kennt ja einer einen besseren/anderen Weg, vielleicht sogar ohne das volle Programmpaket von Adobe ... 🙄


Gruss und ein schönes Wochenende
Georg
 

ingmar

New member
Kennt jemand den Workflow von Profis, um aus Manuskripten letztlich optimale epubs zu erzeugen?

Nicht aus eigene Erfahrung, aber es gibt da mW durchaus brauchbare Software. Zumindest im semiprofessionellen Bereich angesiedelt ist
Um den Link zu sehen, bitte Anmelden oder Registrieren
.


Ich habe von einem freiberuflichen Lektor eine haarsträubende Verkettung von Word mit Sigil/Calibre und vor und zurück geschildert bekommen und kann nicht glauben, dass man so arbeiten möchte.

Ich auch nicht. Ich verstehe überhaupt nicht, warum ein Verlag das selber machen wollen. Damals, als es noch \"echte\" Bücher gab, hat man auch bloß das fertige Manuskript zum Setzen und Umbrechen in die Druckerei geschickt. Es gibt auch beim E-Publishing fähige Dienstleister.


Wichtig scheint wohl zu sein, dass Autoren und Lektoren Formate sauber austauschen können, deshalb wohl Word ?!

Word wohl, weil die meisgten Autoren ihr Manuskript als .doc abliefern...
 

Der Hansi

New member
Word ist bestimmt nicht das Schlechteste. Anschließend das viele hin und her zwischen den Tools kann vermutlich ziemlich unübersichtlich werden und is bestimmt nicht das Beste für den HTML-Code.


Ich habe mich in letzter Zeit mal ein wenig in Sigil (ebenfalls Calibre und die Struktur von eBooks) eingefixt, da ich früher einige Webseiten programmiert habe, habe ich glücklicherweise alles recht schnell verstanden.
:cool:
Von Sigil war ich eigentlich begeistert, aber aber an manchen Punkten etwas unzufrieden. Soweit ich weiss, wird Sigil aber leider nicht weiterentwickelt, so dass sich das nicht ändern wird. Aber immerhin, schlecht ist die Suite auch nicht. Nützlich auf jeden Fall und dazu auch noch gratis!
:o
Gerade wenn es um mehr Zugriff auf die Dateistruktur geht, ist Sigil brauchbarer als Calibre - zuviel Automatismen.


Da eBooks generell nur ganz simple Webseiten sind (HTML mit Fließtext als Inhalt + CSS, das sind Webdesign Basics!) könnte man theoretisch mit jedem guten HTML Editor das Grundgerüst für eBooks bauen, man muss nur anschließend ein Tool haben, was das Ganze verifiziert und in ein ePub verpacken kann.


Ich glaube ein Problem der Profis ist, dass Verleger keine Webdesigner sind. Ich habe zumindest in einigen eBooks dermaßen viel überflüssigen Code gefunden, dass es scheppert. Das passiert, wenn man per Editor viel automatisch machen lässt und dann anschließend nicht mehr drüber kuckt. Funktionieren tut es, aber wenn man den ganzen Kram entrümpeln würde, wäre das eBook merkbar kleiner. Da eBooks aber generell Leichtgewichte sind, dürfte der Unterschied aber auch erst bei großen Massen von eBooks wirklich ernst werden. Aber für die Weiterverarbeitung ist redundanter Code eigentlich Mist.


Aber um wieder auf die Frage zurück zu kommen, ich weiss zwar leider nicht direkt von den Vorgängen der Profis, aber so wie ich das sehe, wurschteln die sich das teilweise halt nur zurecht, bis es passt. 😉
Wobei das aber bestimmt in dem einen eBook besser und in dem anderen schlechter ist.


Ich würde von einem Word Manuskript bestimmt recht leicht ein ordentliches eBook (ePub) bauen können. Würde den Klartext zu Sigil kopieren, den Klartext mit HTML Formaten versehen - so wie im Manuskript (oder kucken was für ein HTML mir Word exportiert und das anschließend aufräumen), Bilder rein und ein wenig formatieren. CSS Finetuning. Joar das wars eigentlich schon, Fleißarbeit ist es dennoch und wenn man nicht ganz so viel Erfahrung mit HTML etc. hat, bestimmt erstmal recht fordernd oder verwirrend.
 
Zuletzt bearbeitet von einem Moderator:

alexbloggt

Blogger
Finde die Frage sehr interessant!


Man findet ja viele Möglichkeiten im Netz, wie man selbst epubs erstellen kann, aber den professionellen Worklow habe ich auf die Schnelle zumindest nicht gefunden.
Für Libreoffice gibt es ein Plugin zum Erzeugen von epubs, bei Pages sollte es von Hause aus gehen und mit InDesign ebenso. Zum Validieren der erzeugten Datei gibt es auch hilfreiche Tools wie \"epubcheck\".
Wie die Arbeitsschritte in \"großen\" Verlagen zum Erstellen von eBooks aussieht und ob dort wirklich \"professionell\" im Sinne von gemäß der Spezifikation gearbeitet wird, frage ich mich auch.
Die InDesign-Variante erscheint mir fast am professionelsten und da Firmen gerne auf kommerzielle Lösungen setzen auch als die wahrscheinlichste Variante zum Erstellen der Dateien.


Update:
Um den Link zu sehen, bitte Anmelden oder Registrieren
btw. ein Handbuch zum Workflow mit InDesign. Interessant in der Beschreibung ist die Zielgruppe:

InDesign-Anwender- Verlagshersteller, Satzbetriebe, Agenturen- Studierende und Auszubildende
 
Zuletzt bearbeitet von einem Moderator:

Der Hansi

New member
Wenn der Verlag sowieso die Adobe Suite benutzt, ist das bestimmt ne hervorragende Lösung - die Software ist ja auch teuer genug. 😉 Als Author wird man aber verutlich dennoch das Skript als Word- oder OpenOffice/Writer-Datei abliefern. Und da frage ich mich noch, ob der Export, bzw. und die Konvertierung eigentlich ordentlich abläuft oder der Schriftsetzer des Verlags anschließend das gesamte Buch, sozusagen im schlimmsten Fall Absatz für Absatz, per Hand formatieren muss.
:eek:



Auch nicht uninteressant ist übrigens der Wikipedia Artikel über ePub, der verweist am Ende auch auf Fachliteratur von 2010. In Folge dessen habe ich auch ein neueres Buch über ePub3 gefunden.
 

ebooker

New member
Naja ist halt die Frage was man unter Profis versteht. Wenn man das im Sinne, von Leute die damit Geld verdienen meint, dann sind die nicht unbedingt ein Vorbild. Ich gehe alle Ebooks mit dem Calibre-Editor durch und prüfe die. Was da zu Tage kommt ist wirklich großer Schrott. Ja auch von Verlagen. Von den ganz großen und den ganz kleinen.


Indesign bringt katasprophale EPUBs, das sagt zumindest der Setzer Rainer Zenz der professionell Ebooks erstellt. Er nimmt Jutuh. Naja auch da bin ich nicht so begeistertet es macht auch nicht unbedingt so gute Ebooks aber wesentlich besser als Insdesign. Gute Ebooks lassen sich halt nicht automatisch erstellen...
 
Zuletzt bearbeitet von einem Moderator:

skreutzer

New member
Die Profis schimpfen regelmäßig über genau dieses Problem und haben eine Liste an manuellen Arbeitsschritten, um so viel wie möglich der vorhandenen Formatierung beizubehalten, aber u.U. reicht das nicht aus und erhöht auch nicht zwangsläufig die semantische Qualität des EPUBs. Ich persönlich würde erstmal sämtliche Formatierung bis auf den rohen Text hinunter verwerfen und den Text dann in neue semantische Auszeichnung einkleiden, da es schon von vornherein ein Fehler ist, im Manuskript Print- oder E-Book-Satz vornehmen zu wollen. Microsoft Word ist da ganz maßgeblich mitbeteiligt infolge des Default-Bedienkonzeptes der Direktformatierung, die für den Mengensatz ungeeignet ist, und der HTML-Export ist miserabel, sodass dafür ein zusätzliches Plugin benötigt wird. Calibre legt keinen großen Wert auf EPUB-Gültigkeit, sollte ebenfalls werden.


Und ja, man kann qualitative E-Books vollautomatisch erzeugen, und als Bonus purzelt dabei zusätzlich gleich auch noch das dazugehörige PDF hinten heraus, idealerweise unter Mitwirkung des Autors bei Manuskript-Erstellung.


Noch ein kleiner Hinweis: ein gewisser Teil der professionellen E-Book-Produzenten sind genau deshalb professionell (hat nichts mit der Qualität, sondern mit berufsmäßiger Ausübung zu tun) im Geschäft, weil man sie in genau denjenigen Fällen für eine manuelle Korrektur bezahlt, wo jemand anders weiter vorne in der Kette Mist gebaut hat, der entweder schwer zu beheben ist oder wo niemand freiwillig Bock darauf hat, sich damit zu beschäftigen, sodass Geld ein wenig nachhelfen muss, um über die Mühen und Strapazen etwas besser hinwegsehen zu können.
 
Zuletzt bearbeitet von einem Moderator:

ebooker

New member
Und ja, man kann qualitative E-Books vollautomatisch erzeugen, und als Bonus purzelt dabei zusätzlich gleich auch noch das dazugehörige PDF hinten heraus, idealerweise unter Mitwirkung des Autors bei Manuskript-Erstellung.

Ja, wenn die Ebooks nur Fließtext enthalten und alle gleich aussehen sollen. Es gibt aber halt auch andere Bücher da funktioniert das eben nicht so. So wie es kein vollautomatisches Lektorat und Korrektorat gibt.
 

Der Hansi

New member
Calibre macht auch teilweise ziemlich merkwürdige Konvertierungen, wie ich heraus gefunden habe. Hatte spaßeshalber aus einer kurzen Leseprobe im PDF Format ein kleines ePub erzeugt und mein CSS war höchstens 20 zeilig. Dann das Ganze zu AZW3 in Calibre konvertiert, wurde aus der CSS Datei ein 100 Zeiler und im HTML Text wurde praktisch jedes Tag mit Klassen versehen, welches dann in CSS definiert wurde, zB. aus einem <i></i> Tag wurde <i class=\"calibre5\"></i> und zusätzlich im CSS: #calibre5 { font-style: italic; }. Das AZW war im Vergleich zum ePub 30kb größer.


Woran liegt das? Kann der Kindle wirklich keine simpelsten HTML Tags ohne CSS interpretieren? Würde <em> ohne CSS kursiv dargestellt werden? (Btw, es gibt sowohl in Sigil, als auch Calibre nur <i> Schnellformat-Buttons.) Wäre meine Formatierung meines Ausgangs-ePubs überhaupt in gängigen ePub Readern lesbar oder brauchen die auch für jedes Format-Tag eine CSS-Definition?


Dann habe ich entdeckt, dass CSS Verschachtelungen wie zB. h2 + * durch Calibre bei der Konvertierung komplett umgeschrieben werden, so dass für jedes verschachtelte Element eine neue Klasse angelegt wird, welche widerum komplett neu definiert wird. Ist verschachteltes CSS etwa zu rechenintensiv, so dass es Reader verlangsamen könnte?


Und wie erstellen Selfpublisher, bzw. Verlage bei Amazon eigentlich ihre AZW\'s? Da muss Amazon doch irgendein Tool anbieten?
 
Zuletzt bearbeitet von einem Moderator:

ebooker

New member
Woran liegt das? Kann der Kindle wirklich keine simpelsten HTML Tags ohne CSS interpretieren?

Ich halte generell nichts von direkten Formatierungen in Ebooks. Alles gehört ins CSS. Wenn man dann etwas ändern möchte kann man es zentral am CSS vornehmen und muss nicht die einzelnen HMTL-Tags bearbeiten. Hat man z.B. die Wörter mit man Kursiv machen will mit HTML-Tags ausgezeichnet und möchte die jetzt noch Fett oder unterstrichen? Was macht man dann? Jede Stelle von Hand ändern? RegEx und Suchen&ersetzen? Viel zum kompliziert. Ist eine CSS-Klasse dafür vergeben. Ändern man einfach einmal dies Definition dieser Klasse. Fertig. Und das CSS auch nicht in die einzelnen Dateien, sondern in eine Extra-Datei die dann in die XHTML-Dateien eingebunden wird.
 

ingmar

New member
Ist eine CSS-Klasse dafür vergeben. Ändern man einfach einmal dies Definition dieser Klasse. Fertig.

Am semantischen Sinn von (X)HTML geht das dann aber vorbei. Styling-Information gehört natürlich ins CSS (wie soll ich \"emphasized\" darstellen?), aber dass ein bestimmter Textabschnitt wichtig ist, sollte mE im HTML selbst definiert sein.
 

skreutzer

New member
Würde <em> ohne CSS kursiv dargestellt werden?

„em“ steht für „emphasis“, eine Hervorhebung. Meistens wird eine solche fett dargestellt, da es sich aber um eine semantische Auszeichnung handelt, ist die optische Repräsentation undefiniert.


es gibt sowohl in Sigil, als auch Calibre nur <i> Schnellformat-Buttons

Wenn wirklich ein <i> ins EPUB geschrieben wird, wenn man den Schnellformat-Knopf drückt, dann macht dies ein EPUB2 ungültig und hat in EPUB3 nichts mehr mit „italic“, kursiv, zu tun. Bei Calibre ist genau das der Fall, und da Calibre kein EPUB3 unterstützt, ist Calibre eine weit verbreitete Quelle für ungültige EPUBs, die den Leuten das Leben schwer machen. Kovid Goyal, der Haupt-Entwickler von Calibre, hält nichts von Standards, sondern stattdessen soll lieber der Rest der Welt fehlertolerante Software schreiben.


Wäre meine Formatierung meines Ausgangs-ePubs überhaupt in gängigen ePub Readern lesbar oder brauchen die auch für jedes Format-Tag eine CSS-Definition?

Validier das EPUB doch einfach, und wenn es gültig ist, dann obliegt es dem Reader, es lesbar anzuzeigen (außer natürlich, wenn mit CSS so richtig kranker Kram angestellt wird).


Ich halte generell nichts von direkten Formatierungen in Ebooks. Alles gehört ins CSS

Richtig.


Hat man z.B. die Wörter mit man Kursiv machen will mit HTML-Tags ausgezeichnet und möchte die jetzt noch Fett oder unterstrichen?

Falsch, und zwar wegen


Am semantischen Sinn von (X)HTML geht das dann aber vorbei.

Im HTML einer Webseite wie im HTML eines EPUBs ist es wichtig, dass die verwendeten Elemente nicht das Aussehen deklarieren, sondern die Struktur und Bedeutung. Struktur und Bedeutung kann dann hinterher immer noch eine Gestaltung zugewiesen werden (per CSS), beide Komponenten sind aber völlig getrennt voneinander zu betrachten. Semantische Auszeichnung ist dafür gedacht, maschinenlesbar zu sein, also z.B. von Software. Ein Mensch kann vielleicht unter Berücksichtigung des Kontextes und der optischen Darstellung erraten, was die Bedeutung eines Gestaltungselements sein soll, ein Computer ist aber furchtbar schlecht im Raten und unintelligent, weshalb man ihm ausdrücklich die Bedeutung von Datenschnipseln mitteilen muss, damit er diese auch verarbeiten kann. So wird die optische Hochstellung von Text verwendet, um Fußnotennummern im Text unterzubringen, um die Dimension von Maßeinheiten anzugeben oder um die Auflage eines Buches zu spezifizieren. Wenn jetzt eine Verarbeitungssoftware aus einem nicht-semantischen Quell-Dokument ein Zielformat erzeugen soll, wo alle Fußnoten übergangen werden, weil das Zielformat die Anzeige von Fußnoten nicht unterstützt, gibt es keine Möglichkeit, die hochgestellten Fußnotennummern von den hochgestellten Exponenten an den Maßeinheiten zu unterscheiden, womit man das gesamte Dokument also doch wieder von Hand komplett überarbeiten muss (und dieses Mal dann hoffentlich richtig). Informationen, die man nicht encodiert, also nicht hinterlegt und abspeichert, stehen anschließend eben auch nicht zur Verfügung. Für normalen Fließtext wie den eines Buches halten sich die Vorteile der semantischen Auszeichnung noch etwas in Grenzen (wobei sehr viele Leute dann doch darüber stolpern, indem sie die Arbeit für E-Book-Erzeugung und Print-PDF-Erzeugung dann doppelt machen müssen, und zwar manuell), man kann mit dieser Methode aber auch sehr komplexe Datenbestände für computergestützte Verarbeitung abbilden, sodass es unzählig viele Encodierungs-Vokabular-Definitionen für die unterschiedlichsten Zwecke gibt (HTML ist eins davon), worauf die verarbeitenden Programme dann abgestimmt werden können.


Dementsprechend empfiehlt es sich, nur die XHTML-Elemente zu verwenden und diese mit id- und class-Attributen zu versehen, deren visuelle Gestaltung dann per CSS vorgenommen wird. Ziemlich witzlos ist dann aber trotzdem, einen Style „italic“ zu definieren und den dann kursiv zu machen, weil hier dann ganz genauso jeglicher Hinweis auf den Grund, weshalb man überhaupt zur kursiven Hervorhebung gegriffen hat und was man damit bezwecken möchte, als explizit encodierte Information verloren geht.
 
Zuletzt bearbeitet von einem Moderator:

ebooker

New member
Weil es kein Epub 3 unterstützt ist es gegen den Standard? Quatsch. Epub2 ist auch ein Standard.


Gesendet mit meinem C64
 

skreutzer

New member
Falls du von Calibre redest: EPUB3 unterstützt Calibre nicht (bisher nicht angedacht), und die EPUB2-Ausgabe von Calibre ist regelmäßig ungültig.
 
Zuletzt bearbeitet von einem Moderator:

Der Hansi

New member
ebooker: Ich glaube er meint damit nur, dass <i> weder in EPUB2 und erst recht nicht in EPub3 verloren hat, da es gegen die Richtlinien ist, physiche Formatierungen zu verwenden. Und deshalb der Programmierer offenbar nichts von Standards hält.


Tatsache ist, dass physische Formatierungen wie <i> (italic= kursiv) als veraltet gelten, da sie eine konkrete Darstellung definieren und stattdessen logische Formatierungen wie <em> (emphasis=hervorgehoben) empfohlen werden und das übrigens bereits seit geraumer Zeit (im Web-Bereich).
Der Vorteil ist, dass die logische Auszeichnung auch zB. für automatische Sehbehinderten-Vorlesegeräte/Blindenreader logisch übertragen werden kann. Deshalb der Terz. Die physikalische Formatierung kann ja eigentlich nur für den Druckbereich gelten und ist insofern zwar bei einem eBook-Reader mit einem Display noch \"logisch\", aber wenn der Text von anderen Geräten interpretiert werden soll, nicht mehr logisch. (Hää? Wie soll ich denn kursiv vorlesen? 😉 )


<em> wird übrigens weit verbreitet als kursiv in Browsern dargestellt, sofern nicht anderes definiert wird und stellt laut Definition eine geringere Form von <strong> dar, welches sich normalerweise als Bold zeigt. Aber es ist natürlich richtig, definiert ist es eigentlich nicht. Aber deshalb meine Frage, was die Reader eigentlich damit anstellen, falls man es nicht näher in CSS beschreibt.
:o



skreutzer: Danke für den Tip mit dem Validieren. Bin anscheinend immer noch zu stark am Orientieren an den Fehlern der Darsteller, als an den Standards. Interessanterweise fehlte nur das <dc:language>de</dc:language> Element, ansonsten hab ich alles richtig gemacht.
Krankes CSS Zeug ist eigentlich nicht drin, die Verschachtelung gibts schon seit CSS2.
Werde irgendwann mal das ePub durch den Kindlegen jagen und kucken, was das Tool dann an Code ausspuckt.
:o
 

skreutzer

New member
Jupp, dem kann ich eigentlich nur noch eine kleine Anmerkung hinzufügen, dass <i> wohl offenbar in HTML5 und damit auch in EPUB3 wieder zugelassen ist (nachdem es in XHTML und damit in EPUB2 verworfen wurde, und es zwar auch ein XHTML5 gibt, welches aber (noch?) keinen Eingang in EPUB3 gefunden hat), mittlerweile aber keine kursive Darstellung mehr garantiert, sondern eher ähnlich wie <em> als eine Art Hervorhebung benutzt werden soll.


Zu Mobi/AZW kann und will ich nichts sagen, da kann dir leider niemand helfen, nur Amazon.
 

Der Hansi

New member
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).


Und ich hoffe doch, dass noch jemand außer Amazon sich mit AZWs beschäftigt, wir sind doch hier um Erfahrungen auszutauschen, oder? :p
Die Unterschiede, die mir bei AZW aufgefallen waren, sind, dass die Dateien kryptischer benannt werden (Dateien sind nur Nummernfolgen) und dass statt einer Titelwebseite nur das Cover.jpg (als 123456.jpg) lose im Container liegt, aber in den Metadaten darauf gezeigt wird. Ansonsten siehts verdammt ähnlich aus wie ePub und ist vermutlich auch nur geringfügig anders. Aber ich habe noch keinen echten 1:1 Vergleich gemacht und bisher AZWs auch nur in Calibre geöffnet, welches, wie erwähnt, sich teilweise scheinbar etwas unlogisch verhält, aber immerhin kann es AZWs komplett verarbeiten, Mobipocket will es nämlich nicht zum Bearbeiten öffnen.
Werde ggfls. berichten, wenn sich mir da neue Erkenntnisse oder Abgründe auftun.
 
Oben