133 Antworten in diesem Thema

[My.]

Da Kursiv die einzige zulässige Auszeichnung im normalen Text ist (bei meinem Verleger), ...

My.

[methom]

Hey Leute, die Leser zahlen Geld für eBooks, da kann man doch als Kunde genausoviel Sorgfalt erwarten wie bei gedruckten Büchern!!!

Amen!

[Valerie J. Long]

Hey Leute, die Leser zahlen Geld für eBooks, da kann man doch als Kunde genausoviel Sorgfalt erwarten wie bei gedruckten Büchern!!!

Amen!

Ja, natürlich, und nein, natürlich nicht.

Sorgfalt in Bezug auf Schusterjungen und Hurenkinder ist beim E-Buch ebenso verschwendet wie subtile Veränderungen der Laufweite. Umso mehr Rücksicht muss man auf das nehmen, was beim Leser ankommt.

[Ernst Wurdack]

Sorgfalt in Bezug auf Schusterjungen und Hurenkinder ist beim E-Buch ebenso verschwendet

Ich hatte weiter oben schon drauf hingewiesen: Mit dem Tag widow kann man das zumindest beim ePub steuern. Es steht also keine einzelne Zeile irgendwo einsam auf dem Display rum. Wird interessant, wenn auf der letzten Seite eines Abschnitts ein Kapitelbreak folgt. Und das tag wird nur aktiv, wenn nötig. Bei einer Vergrößerungsstufe brauchte es das, bei einer anderen Stufe wieder nicht, je nach Zeilenumbruch.
Sorgfalt ist nie verschwendete Zeit. Das Resultat sind nämlich schöne Bücher.

[jeamy]

Ich hatte weiter oben schon drauf hingewiesen: Mit dem Tag widow kann man das zumindest beim ePub steuern.

schon, aber welcher reader kann das?
standardwert von widows und orphans ist 2 zeilen, daher müsste es ohnehin überall passen, wenn die reader es berücksichtigen würden.

Sorgfalt ist nie verschwendete Zeit. Das Resultat sind nämlich schöne Bücher.

ja, ich versuceh jeden fehler zu korrigieren, wenn mich jemand darauf aufmerksam macht. man lernt immer was neues.

Bearbeitet von jeamy, 12 Dezember 2012 - 13:55.

[Valerie J. Long]

Ich hatte weiter oben schon drauf hingewiesen: Mit dem Tag widow kann man das zumindest beim ePub steuern. Es steht also keine einzelne Zeile irgendwo einsam auf dem Display rum. Wird interessant, wenn auf der letzten Seite eines Abschnitts ein Kapitelbreak folgt. Und das tag wird nur aktiv, wenn nötig. Bei einer Vergrößerungsstufe brauchte es das, bei einer anderen Stufe wieder nicht, je nach Zeilenumbruch.
Sorgfalt ist nie verschwendete Zeit. Das Resultat sind nämlich schöne Bücher.

Sorgfalt muss an der richtigen Stelle investiert werden. Werden meine E-Bücher schöner, wenn ich jedes einzelne paarweise Kerning in meiner Papier-Korrekturfahne nachmesse? Werden deine dadurch schöner?

Ich lerne gerne hinzu, und die widows-Eigenschaft kannte ich tatsächlich noch nicht.

Quelle: http://www.w3.org/TR...ml#break-inside

'widows'
Value:   <integer> | inherit
Initial:   2

Nein, wenn der Standardwert schon "2" ist, gewinne ich nichts, wenn ich sorgfältig von Hand meinen XHTML-Code nachbessere.
Das ist keine echte Sorgfalt, sondern ein Placebo.

Ganz ehrlich: In meinen Augen wirkt dieses Argument nicht professionell, sondern eher ausgrenzend. Bei mir kommt an: "Seht her, der echte Profi ist besser als all die schlampigen Dilettanten da draußen" - und dann sehe ich im Standard nach und stelle fest, oh, der Mann hat keine Ahnung.
Es täte mir leid, wenn dieser Eindruck zuträfe, denn bisher kam es mir anders vor.

[Valerie J. Long]

Ein wirklich schönes E-Buch würde wohl auch auf meinem Kindle so aussehen wie Cornelia Funkes "Drachenreiter" - Mit kleinen Bildern bei jedem Kapitelbeginn und auch mal zwischendurch. (Zu sehen in der Amazon-Vorschau, aus rechtlichen Gründen verzichte ich auf einen Schnappschuss.)

[Ernst Wurdack]

Vielleicht hast du mich falsch vestanden. Es nützt ja erstmal nichts, wenn der Standard in einer Spezifikation 2 ist. Der Reader muss ja wissen, dass du dieses "widows" anwenden möchtest, sonst tut er nichts. Der Sony kann es, aber nur, wenn man es ihm via CSS auch eindeutig sagt. Sonst geschieht nämlich - nichts.

[Valerie J. Long]

Vielleicht hast du mich falsch vestanden. Es nützt ja erstmal nichts, wenn der Standard in einer Spezifikation 2 ist. Der Reader muss ja wissen, dass du dieses "widows" anwenden möchtest, sonst tut er nichts.
Der Sony kann es, aber nur, wenn man es ihm via CSS auch eindeutig sagt. Sonst geschieht nämlich - nichts.

Dann habe ich es tatsächlich falsch verstanden, Entschuldigung!
Das muss ich ausprobieren.

Es passt an diese Stelle: Bedauerlicherweise kann WORD außer einem Häkchen bei "Widow/Orphan control" mit dem Thema genauso wenig anfangen wie mit Guillemets - im Gegensatz zu einem StarOffice/OpenOffice im Stand von vor acht Jahren.

[Ernst Wurdack]

Genau das ist (hoffentlich nicht mehr lange) das Problem bei den derzeitigen Readern. Sie halten sich einfach nicht an Standards. Jeder Hersteller kocht sein eigenes Süppchen. Und plötzlich stellt man fest, dass man deswegen im Quelltext wieder nachbessern muss. Small-Caps sind auch so eine Sache, über die ich kürzlich gestolpert bin. Das geht z.B. beim Kindle nur über Umwege. Beim Kindle Fire muss ich es noch testen. Und dann ist da immer noch die Frage offen, warum der Kindle zwischendrin manchmal streckenweise keinen Blocksatz liefert, sondern so etwas wie Flattersatz. Für diesbezügliche Hinweise bin ich dankbar.

[Valerie J. Long]

Small-Caps sind auch so eine Sache, über die ich kürzlich gestolpert bin. Das geht z.B. beim Kindle nur über Umwege. Beim Kindle Fire muss ich es noch testen.

Mein Workaround sind echte Großbuchstaben, die ich dann 2pt verkleinere - zum Glück brauche ich das nur ganz selten. (Wenn dann die Schriftgröße nicht zieht, habe ich Versalien, die sich immer noch vom Rest des Textes abheben. Das geht.)

Und dann ist da immer noch die Frage offen, warum der Kindle zwischendrin manchmal streckenweise keinen Blocksatz liefert, sondern so etwas wie Flattersatz.

Ah - und auch das ist abhängig von der Schriftgröße und kommt im Previewer nicht vor. Ich habe so etwas auch schon bei E-Büchern großer Verlage gesehen.
Ich vermute stark, dass der Trenn- und Umbruch-Algorithmus kapituliert und als Rückzugsposition auf Flattersatz umstellt. Die Lösung dürfte sein, auf lange Kompositworte zu verzichten....

Bearbeitet von Valerie J. Long, 12 Dezember 2012 - 15:42.

[Guido Seifert]

Und dann ist da immer noch die Frage offen, warum der Kindle zwischendrin manchmal streckenweise keinen Blocksatz liefert, sondern so etwas wie Flattersatz.
Für diesbezügliche Hinweise bin ich dankbar.

Ich vermute stark, dass der Trenn- und Umbruch-Algorithmus kapituliert und als Rückzugsposition auf Flattersatz umstellt. Die Lösung dürfte sein, auf lange Kompositworte zu verzichten....

Eine Worttrennfunktion gibt es ja beim Kindle gar nicht, und da eben scheint mir das Problem zu liegen - zumindest habe ich bislang keine Worttrennungen auf dem Kindle gesehen (mit Ausnahme jener Komposita, die mit Bindestrichen gebildet werden). Die Kindle-Software ist zwar auf Blocksatz ausgerichtet, geht aber - so will es mir scheinen - Kompromisse ein, sobald der Umbruch dazu führt, dass die in einer Zeile vorhandenen Zeichen eine definierte Untergrenze unterschreiten. In diesem Fall würde der Blocksatz die in der Zeile vorhandenen Wörter unschön auseinanderziehen. Somit macht der Kindle - das vermute ich - aus einem Mangel eine Tugend, denn ein leichter Flattersatz wirkt auf das Auge angenehmer als auffällig große Wortabstände. Dennoch handelt es sich natürlich um einen Mangel: Beherrschte der Kindle die Worttrennung, so wäre auch perfekter Blocksatz möglich (sofern man nicht eine sehr große Type einstellte).

[My.]

@ Valerie: Nur der Vollständigkeit halber (weil ich denke, dass du das nicht andeuten wolltest) sei zu erwähnen, dass die Tatsache, dass man mit der einen oder anderen aus dem Printbereich bekannten Problemstellung auf einem eBook eh nichts anfangen kann, weil das da nicht relevant ist oder schlicht nicht geht, natürlich nicht bedeutet, dass man gar keine Sorgfalt walten lassen muss. Ganz im Gegenteil. Mich stört bei eBooks z.B. der Versuch, Blocksatz zu erzeugen. Ich halte das nicht nur für überflüssig, sondern auch schädlich, spätestens dann, wenn mangels Trennmöglichkeiten Zeilen aufreißen, oder der Blocksatz sogar ganz verloren geht (was ich bei einigen meiner bisher gelesenen eBooks, die von großen Verlagen stammten, unangenehm bemerkt habe). Und eben so Sachen wie: Rechtschreibung, Tippfehler, Trennleichen usw. usf. Umso weniger man beim eBook mit dem Layout und der Optik protzen kann, weil man sie nicht endgültig beeinflussen kann, umso mehr muss man auf andere Dinge achten. My.

[Valerie J. Long]

@ Valerie: Nur der Vollständigkeit halber (weil ich denke, dass du das nicht andeuten wolltest) sei zu erwähnen, dass die Tatsache, dass man mit der einen oder anderen aus dem Printbereich bekannten Problemstellung auf einem eBook eh nichts anfangen kann, weil das da nicht relevant ist oder schlicht nicht geht, natürlich nicht bedeutet, dass man gar keine Sorgfalt walten lassen muss. Ganz im Gegenteil.

Richtig. Die Sorgfalt muss nur an der richtigen Stelle investiert werden.

Mich stört bei eBooks z.B. der Versuch, Blocksatz zu erzeugen. Ich halte das nicht nur für überflüssig, sondern auch schädlich, spätestens dann, wenn mangels Trennmöglichkeiten Zeilen aufreißen, oder der Blocksatz sogar ganz verloren geht (was ich bei einigen meiner bisher gelesenen eBooks, die von großen Verlagen stammten, unangenehm bemerkt habe). Und eben so Sachen wie: Rechtschreibung, Tippfehler, Trennleichen usw. usf.
Umso weniger man beim eBook mit dem Layout und der Optik protzen kann, weil man sie nicht endgültig beeinflussen kann, umso mehr muss man auf andere Dinge achten.

Genau!
Trennleichen sollte es gar nicht geben, bedingte Trenn-ungen müssen raus.
Was den Blocksatz angeht, verstehe ich deine Einstellung, nur - ich kann schlecht eine Version für Blocksatzfans und eine für Flattersatzfans erstellen. Das sprengt doch ein wenig meine zeitlichen Möglichkeiten. Ab und zu muss ich ja auch mal was schreiben...

[My.]

Ich bin eigentlich Blocksatzfreund, aber bei eBooks halte ich den Flattersatz für besser, unkritischer, einfacher, (scheinbar) fehlerfreier. My.

[methom]

Ja, natürlich, und nein, natürlich nicht.

Sorgfalt in Bezug auf Schusterjungen und Hurenkinder ist beim E-Buch ebenso verschwendet wie subtile Veränderungen der Laufweite. Umso mehr Rücksicht muss man auf das nehmen, was beim Leser ankommt.

Ich würde dir insofern recht geben, dass man (gerade als "amtlicher" Verlag) die Wirtschaftlichkeit im Auge behalten muss. Nicht umsonst gibt es die 80:20-Regel, nach der 80 Prozent des Aufwandes von den letzten 20 Prozent bis zum perfekten Ergebnis verursacht werden. Aber es sollte eine ganz bewusste Entscheidung sein, zu sagen: so weit und nicht weiter. Das Ergebnis sollte keinesfalls das sein, was Amazon (oder vergleichbare Anbieter) zufällig daraus machen, wenn ich ihnen mein unvorbereiteten Text vorwerfe.

Und weil ich hier ein, zwei Mal etwas im Sinne von "das habe ich sogar in E-Books großer Verlage gesehen": die sind meines Erachtens oftmals deutlich weniger sorgfältig hergestellt als die aus den kleinen Verlagen. Insbesondere wenn es sich um Titel aus dem Backkatalog handelt. Teilweise wirken die wie eingescannt und durch eine Texterkennung gejagt. Da wird aus der "Waffe" schon mal die "Watte".

[Valerie J. Long]

Das Ergebnis sollte keinesfalls das sein, was Amazon (oder vergleichbare Anbieter) zufällig daraus machen, wenn ich ihnen mein unvorbereiteten Text vorwerfe.

Uh, nein. Der Text muss so gut wie möglich vorbereitet sein - und zwar auf den Prozess hin vorbereitet, den der Anbieter vorgesehen hat.
Amazon KDP: "HTML gefiltert" aus WORD exportiert - taugt nur was, wenn man ordentlich mit Formatvorlagen umgehen kann und ein Inhaltsverzeichnis mit Hyperlinks erstellt hat. (Und vieles andere mehr, z.B. keine Kopf/Fußzeilen, keine Seitennummern etc etc)
Smashwords: WORD, aber mit Leerzeilen statt Abstand vor/nach Absatz und sehr bescheidenen Einflussmöglichkeiten.
POD-Dienstleister: PDF nach Adobe-Standard mit eingebetteten Schriften - hier ist die Investition in Satz und Textbild gefordert, hier lohnt sich Kerning, hier sind schöne Schriften mit echter Kursivschrift (z.B. am g/g erkennbar) gefragt, usw...

[Naut]

So, ich habe jetzt ein völlig neues Backend programmiert, das ein 100% Kindle-konformes XHTML ausspuckt. Das Ergebnis ist eine vollautomatische Pipe, die es mir erlaubt eine Kurzgeschichtenanthologie aus meinem Fundus innerhalb von 1-2 Minuten zusammenzustellen und als MOBI zu kompilieren. Es gibt jetzt einen ordentlichen Erstzeileneinzug, der natürlich im jeweils ersten Absatz eines Kapitels oder nach Absatz unterdrückt wird. Der Amazon Blick-ins-Buch sieht aber immer noch komisch aus. Der Grund ist, dass Amazon zu blöd ist, sich an seine eigenen Standards zu halten und einfach alle Seitenumbrüche ignoriert. Vermutlich muss man dazu den Schrott tatsächlich als Word-Doc hochladen, dazu werde ich mich aber nicht herablassen, denn das E-Book sieht nach wie vor perfekt aus und validiert sogar nach dem ePub-Standard. Zu den Details: Seitenumbrüche kann man mittels CSS-Attribut "page-break-after/before" einstellen. Allerdings ignoriert z.B. der Calibre-Reader inline-styles, daher muss das ganze über eine eigene Klasse (etwa <div class="break" />) geschehen. Meine Toolchain ist jetzt: nautml -> kindlegen -> MOBI, bzw. nautml -> zip -> ePub nautml erzeugt selbsttätig aus einer Strukturbeschreibung alle notwendigen Dateien für ein ePub, was letztlich auch die Voraussetzung für Kindlegen ist.

Bearbeitet von Naut, 19 Dezember 2012 - 08:09.

[jeamy]

So, ich habe jetzt ein völlig neues Backend programmiert, das ein 100% Kindle-konformes XHTML ausspuckt. Das Ergebnis ist eine vollautomatische Pipe, die es mir erlaubt eine Kurzgeschichtenanthologie aus meinem Fundus innerhalb von 1-2 Minuten zusammenzustellen und als MOBI zu kompilieren. Es gibt jetzt einen ordentlichen Erstzeileneinzug, der natürlich im jeweils ersten Absatz eines Kapitels oder nach Absatz unterdrückt wird.

das klingt nach viel arbeit und ist cool. gratuliere!

Der Amazon Blick-ins-Buch sieht aber immer noch komisch aus. Der Grund ist, dass Amazon zu blöd ist, sich an seine eigenen Standards zu halten und einfach alle Seitenumbrüche ignoriert.

für jeden seitenumbruch eine neue (x)html datei. das sollte überall funktioniert. hat bei älteren readern auch den vorteil, dass die seiten schneller laden. einzelne seiten sind nie gut.

[Naut]

das klingt nach viel arbeit und ist cool. gratuliere!

Och nö, das waren so um die 7 h Arbeit. Das geht noch so nebenbei beim Fernsehen. Für mich ist das weniger Arbeit, als den ganzen Kram in Word zu konvertieren (und da womöglich noch per Hand ein Inhaltsverzeichnis bauen zu müssen *grusel*, das macht nautml automatisch).

für jeden seitenumbruch eine neue (x)html datei. das sollte überall funktioniert. hat bei älteren readern auch den vorteil, dass die seiten schneller laden. einzelne seiten sind nie gut.

Danke für den Tipp! Das habe ich vermutet. Werde ich als nächstes ausprobieren. Evtl. geht auch das nicht-standard Element <mbp:pagebreak />, aber damit dürfte man dann wohl die ePub-Kompatibilität schrotten.

[Valerie J. Long]

Word-Doc? Die KDP-Anleitung empfiehlt "Webseite gefiltert", d.h. HTML mit eingebettetem CSS. Die Angabe "page-break-before:always;" zum Überschriften-Style scheint zu funktionieren. [edit] Meine Antwort hat zu lange gedauert...

Bearbeitet von Valerie J. Long, 19 Dezember 2012 - 08:31.

[jeamy]

Och nö, das waren so um die 7 h Arbeit. Das geht noch so nebenbei beim Fernsehen. Für mich ist das weniger Arbeit, als den ganzen Kram in Word zu konvertieren (und da womöglich noch per Hand ein Inhaltsverzeichnis bauen zu müssen *grusel*, das macht nautml automatisch).

ja, das hat was. einmal mehr zeit investieren und dann nie wieder kopfschmerzen. sollte mir auch was überlegen. wenn ich zeit hab, nach dem nächsten roman.

Evtl. geht auch das nicht-standard Element <mbp:pagebreak />, aber damit dürfte man dann wohl die ePub-Kompatibilität schrotten.

die befürchtung hätte ich auch. und man weiß nie, was amazon dann in den mobi- und azw3-dateien wirklich damit anstellt und wie es dann auf den verschiedenen emulationen aussieht (android, ipad, pc, mac, ...).

Bearbeitet von jeamy, 19 Dezember 2012 - 08:35.

[Naut]

Word-Doc? Die KDP-Anleitung empfiehlt "Webseite gefiltert", d.h. HTML mit eingebettetem CSS.
Die Angabe "page-break-before:always;" zum Überschriften-Style scheint zu funktionieren.


[edit] Meine Antwort hat zu lange gedauert...

Interessante Variante. Offenbar wertet der Amazon-Voransichtenparser das page-break-Attribut nur für bestimmte Elemente aus: Ein kurzes Experiment mit Word/Filtered-HTML ergab, dass Page-Breaks dort als <br> mit eben diesem Attribut exportiert werden. Das wäre bequemer als das zum <h1> zu packen, weil dann break und Überschrift trennbar wären.

Btw.: Was Word unter "filtered" versteht, ist immer noch noch gruselig, so vom semantischen Standpunkt aus.

Edit: Valerie, bei Deinem E-Book "Die Flügel der Löwin" ist die Blick-ins-Buch-Voransicht aber auch nicht korrekt auf page-breaks formatiert. Auch da batscht Amazon alles in einen Fließtext, insofern vermute ich mal, dass deren Parser einfach Schrott ist.

Bearbeitet von Naut, 19 Dezember 2012 - 08:58.

[Naut]

So, ich habe jetzt die definitive Sicherheit, dass Amazons Blick-ins-Buch absolut keine Seitenumbrüche beherrscht. http://kdp.amazon.co...=74419&tstart=0
Das nur, um das Thema endlich abschließen zu können. Geht nicht. Punkt. Kann es nicht.

Die Frage, warum z.B. die Nova 20 ganz akzeptabel aussieht, erklärt sich leicht damit, dass die ersten Seiten relativ gut gefüllt sind. Damit entsteht zumindest der Eindruck, eines gleichmäßigen Seitenflusses. Man kann so etwas also mit viel Whitespacing hinschummeln, aber ehrlich gesagt: Wenn Amazon das nicht fixen will, so wichtig ist es offenbar auch nicht. Hauptsache, das Buch sieht im Reader gut aus.

[Valerie J. Long]

So, ich habe jetzt die definitive Sicherheit, dass Amazons Blick-ins-Buch absolut keine Seitenumbrüche beherrscht. http://kdp.amazon.co...=74419&tstart=0
Das nur, um das Thema endlich abschließen zu können. Geht nicht. Punkt. Kann es nicht.

Puh - und ich dachte schon, es läge an mir - ich habe meinen Kindle gerade nicht dabei und hätte das Endergebnis dort nicht prüfen können. In der App geht's nämlich...

Bearbeitet von Valerie J. Long, 19 Dezember 2012 - 12:52.

[lapismont]

Formatiere es als ePub, ich rate zu Sigil. Mit diesen Programm kannst du auch prüfen, ob Syntax, CSS und Identifier etc. valide sind. Ziehe das ePub dann auf den Kindle-Previewer und wenn es korrekt formatiert ist, bekommst du automatisch das Mobi geliefert, das du bei Amazon hochladen kannst. Alle Fehler, ob kritisch oder nicht, werden dir angezeigt. Sachen wie Page-Definitionen kann Kindle z.B. nicht, egal, sie werden ingnoriert. Vergiss Kindlegen. Es. Ist. Einfach. So lange das CSS stimmt. Mein Workflow: Adobe InDesign 5.5 --> Sigil --> Kindle Previewer --> KDP oder --> ePup-Plattformen InDesign deshalb, weil ich da meine Printdateien, die ich schon mit InDesign erstellt habe, schnell in ein rohes ePub bringen kann. Man kann aber auch mit Word starten: Word --> speichern als Webseite ohne Wordspezifische Tags --> öffnen in Sigil --> die korrekt benannten Word Formatvorlagen in der CSS durch valide CSS-Definitionen ersetzen. Fertig. Arbeitsaufwand etwa 7-12 Stunden für einen Roman - je nach Umfang.

Vielen Dank Ernst!

Ich hab jetzt erste Erfahrungen gesammelt und Dein Workflow war sehr hilfreich!

Gewöhnungsbedürftig für mich war, dass Sigil ständig selber Code generiert und verändert. Da ich lieber im Code arbeite, hat mich das zu Beginn ganz fuchtig gemacht. Aber zumindest bekommt man dadurch Hinweise, wie man es auch machen kann.

[Naut]

Gewöhnungsbedürftig für mich war, dass Sigil ständig selber Code generiert und verändert. Da ich lieber im Code arbeite, hat mich das zu Beginn ganz fuchtig gemacht. Aber zumindest bekommt man dadurch Hinweise, wie man es auch machen kann.

Nimm doch epubcheck, der sagt Dir auch, was falsch ist, und das, ohne an Deinem Code herumzupfuschen.

[lapismont]

Werd ich mir auch mal ansehen, Danke Niklas.

[Valerie J. Long]

Mein Lieblingswerkzeug für Feinarbeiten ist Notepad.