Ich interessiere mich sehr für die Schnittmenge aus E-Books, Sicherheit und dem LowJS Web, daher erscheint mir dieses Thema wichtig.
Ein portables E-Book-Format als einzelne Datei ist nötig, aber PDF ist nicht die Antwort, weil Text dort nicht neu umbrochen werden kann.
HTML+CSS im Jahr 2024 kann nahezu alle Printmedien nachbilden und gleichzeitig Text-Reflow ermöglichen.
Ich finde nicht, dass JavaScript zwingend erforderlich sein sollte. Ein E-Book sollte ein Buch sein, dessen Größe sich sinnvoll ändern lässt, und auch bei deaktiviertem JavaScript sollten die Grundfunktionen als Buch funktionieren. Für Interaktion oder Erweiterungen kann JavaScript genutzt werden, aber wenn es ohne JavaScript nicht als Buch funktioniert, sehe ich das als Bug.
Alle Styles inline unterzubringen halte ich für einen Fehler, weil das die CSP mancher Nutzer brechen kann. Styles sollten als Ressourcen mit relativen Pfaden ausgehend vom HTML ausgelagert werden, und E-Books sollten das Laden von Ressourcen von anderen Domains verbieten.
Schließlich kann man es einfach als zip-Datei ausliefern. Ich glaube, E-Books funktionieren ohnehin schon so.
„Ob E-Books ohnehin wie zip funktionieren“ stimmt bis zu einem gewissen Grad. Unzip-Tools können EPUB-Dateien entpacken, und wenn nötig kann man die Erweiterung von .epub in .zip ändern.
Umgekehrt gilt das aber nicht unbedingt. Selbst wenn dasselbe Dateibündel vor dem Entpacken ein gültiges EPUB war, kann es ungültig werden, wenn man es beliebig wieder als zip packt.
Die mimetype-Datei in einem EPUB-zip ist besonders: Sie muss der erste Eintrag im Archiv sein, ihr Inhalt darf nur application/epub+zip sein, und sie muss unkomprimiert gespeichert werden.
Überraschend viele zip-Tools machen das lästig, weil sie die Dateireihenfolge ändern oder es schwer machen, nur bestimmte Dateien unkomprimiert zu speichern. Mit dem zip-Programm auf der Kommandozeile geht es meist per Flag, aber mit zip-Bibliotheken ist es ziemlich schmerzhaft. Das sage ich aus Erfahrung mit der Entwicklung von EPUB-Erstellungssoftware.
Es ist wichtig, gewöhnliche zip-Dateien und E-Books zu unterscheiden. Als Erweiterung sollte man .epub verwenden.
Beschrieben wurde das ePub-Format, bei dem HTML-, CSS- und Bilddateien in einem zip-Archiv liegen.
Wie wäre es mit selbstentpackenden ZIPs? Zum Beispiel wie auf dieser Seite: https://gildas-lormeau.github.io/
Eine CSP, um es sicher zu machen, ist ebenfalls enthalten.
Ich mag den Ansatz, alles in zip zu packen, nicht besonders.
Was an den alten .doc-Dateien im Vergleich zu .docx angenehm war: In Ordnern mit Hunderten bis Tausenden Dateien konnte man sehr schnell nach einem bestimmten Wort suchen. Mit dem zip-Format geht das nicht.
Ich habe gerade etwas als .doc gespeichert und in einem Hex-Editor geöffnet; der eigentliche Inhalt lag tatsächlich im Klartext vor. zip-Formate oder PDF-Dateien sind mit grep schwer zu durchsuchen, und ich bezweifle, dass Kompression für Text von vielleicht ein paar Tausend Zeichen überhaupt nötig ist.
Wenn es darum geht, dass „HTML+CSS im Jahr 2024 nahezu alle Printmedien nachbilden kann“, ist auch das hier einen Blick wert: https://www.princexml.com/samples/
Das ist ein sehr gut strukturierter Artikel des Nota-Entwicklers, der versucht, das EPUB-Format auf eine Stufe mit PDF zu heben. Einen Viewer gibt es bereits, und der Artikel selbst wird in einem browserbasierten WASM-Port dieses Viewers angezeigt.
Eines der Probleme ist, wie exakt EPUB, das praktisch XHTML ist, Layouts reproduzieren kann. Der Maßstab des Originalartikels ist, dass ein Dokument „plausibel“ aussieht; um mit PDF gleichzuziehen, klingt es so, als bräuchte HTML zumindest beim Zeilenumbruch neue Layout-Funktionen.
Ich sehe zwei Wege voran. Einer ist, dass Browser mehr Typografie-Werkzeuge bereitstellen; text-wrap: pretty soll helfen, aber bei einem kurzen Test schien mir die Qualität der Zeilenumbrüche nicht besser zu werden. Der andere ist, Zeilenumbrüche vorab zu berechnen, was aber nur bei Fixed-Layout-Rendering möglich ist.
Außerdem erwähnt der Autor zwar Anmerkungen, aber ich bin mir nicht sicher, wie er sie umsetzen will.
Der Autor behandelt auch Fixed-Layout-EPUB. EPUB kann grundlegende Paginierung, Zeilenumbrüche, Schriftarten, Schriftgrößen, Seitengrößen, Bildpositionen usw. festlegen, sodass es überall gleich gerendert wird.
Das ist auch in EPUB3 bereits möglich, hat aber den Nachteil, dass es auf Bildschirmen wie Smartphones nicht gut aussieht. Je nach Reader können die Vorgaben überschrieben werden, aber dann muss man hoffen, dass der Reader das Dokument wieder ansprechend aufbereitet.
Eine Alternative wäre, dass ein EPUB mehrere Renderings für gängige Bildschirmtypen angibt. Das ist nicht perfekt, wirkt aber wie ein guter Kompromiss: Dokumentautoren liefern sinnvolle Defaults, und Nutzer können sie bei Bedarf überschreiben.
PDF hat keine Funktion für Zeilenumbruch. Es ist eher ein Bildformat ähnlich wie SVG und noch starrer, weshalb Dinge wie Text-Reflow nicht funktionieren.
Was ein E-Book-Format braucht, ist semantisches Markup, das sich an das Gerät anpasst, auf dem es gerendert wird. HTML+CSS wurde ursprünglich genau für diesen Zweck geschaffen.
Deshalb müssen Buchlayout-Ersteller bewusst einen Teil der Kontrolle darüber, wie ein Buch aussieht, an die Leser abgeben. Ein wenig visuelle Unvollkommenheit ist diesen Preis wert. Wenn visuelle Perfektion nötig ist, nimmt man PDF.
Natürlich wird es schwieriger, wenn interaktive Elemente hinzukommen. Große interaktive Elemente sollten bei Bedarf in einer eigenen Ansicht geöffnet werden, kleine interaktive Elemente sollten Reflow akzeptieren.
CSS unterstützt doch grundsätzlich Funktionen für Paged-Media-Layout, denke ich. Müsste ein EPUB-Reader nicht einfach nur einen traditionellen Anzeigemodus für „Druckvorschau“ implementieren?
Ironischerweise funktioniert gerade das Beispiel, das der Autor für Anmerkungen anführt, in meiner Umgebung nicht richtig. In Firefox auf einem Android-Touchscreen erscheint bei langem Drücken statt eines Popups ein Link.
Anmerkungen und Referenzen sind doch bereits Teil der EPUB-Spezifikation, vielleicht sogar der HTML-Spezifikation, denke ich.
Außerdem bin ich nicht einverstanden damit, dass langes Drücken für ein Popup besser sein soll als ein gewöhnlicher Hyperlink-Anker. Wenn die „Zurück“-Funktion des Readers ordentlich funktioniert oder bidirektionale Referenzen einen „Zurück“-Link haben, ist Navigation deutlich weniger störend.
Früher gab es etwas namens XSL Formatting Objects (XSL-FO). Es zielte auf etwas PDF-Ähnliches auf XML-Basis ab, war aber höher angesiedelt, sodass auch Text-Reflow möglich war.
Die Idee war, ein XML-Dokument zusammen mit einem XSL-Stylesheet auszuliefern, es für das Rendering in FO umzuwandeln und für dasselbe Dokument mehrere Stylesheets für verschiedene Zielgeräte oder Seitengrößen bereitzuhalten.
In Firefox nutze ich das SinglePage-Add-on, um das DOM der aktuellen Seite als eigenständige HTML-Datei zu speichern. Dabei werden CSS und data:-URLs für Bilder inline eingebettet, Abhängigkeiten und Skripte werden entfernt.
Perfekt ist das nicht, und ich vertraue nicht darauf, dass Browser immer abwärtskompatibel bleiben, aber ich bevorzuge es gegenüber dem Speichern einer Seite als PDF oder als mehrere Dateien.
Interessanterweise war einer der wenigen Fälle, in denen dieses Add-on versagte, ausgerechnet dieser Artikel über portable EPUBs. Offenbar steckt darin zu viel Magie, um die Formatierung hinzubekommen. Die gespeicherte Seite war zwar lesbar, sah stilistisch aber völlig anders aus als das Original.
Mir gefällt, dass fbreader unter Android alle Bücher gleich gemäß den App-Einstellungen darstellt, statt nach dem Stil der EPUB-Datei. Ich habe nie gesehen, dass es CSS anwendet oder versucht, in der Datei enthaltene Skripte auszuführen, und hoffe, dass das auch so bleibt. Externe Abhängigkeiten zu laden ist eine noch schlechtere Idee, und ich wusste nicht einmal, dass das überhaupt erlaubt ist.
Du meinst vermutlich SingleFile.
Apropos: Das Berechtigungssystem für Firefox-Add-ons ist seltsam. Um irgendetwas Interessantes zu tun, muss man praktisch alle Berechtigungen anfordern, und dadurch entsteht ein natürlicher Markt für böswillige Akteure, die nach Add-ons suchen, die sie übernehmen können.
Zum Beispiel braucht das SingleFile-Add-on natürlich Zugriff, weil es das gerenderte DOM inspizieren und in eine Datei speichern muss. Aber warum muss es auf alles zugreifen? Könnte man nicht nur Berechtigungen wie snapshot DOM once und write to a single file vergeben?
Einer meiner ersten Kommentare auf HN vor etwa zehn Jahren war, glaube ich, darüber, dass ich HTML-Webseiten nicht als PDF, sondern als HTML speichern wollte.
Damals konnte ich den Grund wohl weder gut erklären noch selbst richtig verstehen, und es wurde behandelt, als wäre es ein absurder Wunsch. Rückblickend scheint es, als hätte ich einfach ungefähr zehn Jahre neben der Zeit gelegen, was mich freut.
Warum diese Seite schwer zu parsen ist, hat ein anderer Kommentar gut erklärt. Es ist ein Beitrag des Nota-Entwicklers darüber, EPUB auf eine Stufe mit PDF zu bringen, und der Beitrag selbst wird in einem browserbasierten WASM-Viewer angezeigt.
FBReader verwendet standardmäßig das CSS des Dokuments. Wenn ich mich richtig erinnere, lässt sich das in etwa vier Schritten abschalten.
KOReader ist weniger benutzerfreundlich, bietet aber mehr Kontrolle. Man kann aus mehreren mitgelieferten CSS-Dateien eine bestimmte auswählen oder selbst eine schreiben.
Zu den Stärken von KOReader gehören außerdem die hervorragende OPDS-Unterstützung und ein einfach selbst zu hostender Synchronisationsserver.
In diesem Artikel gibt es einen Button zum Herunterladen des EPUB.
Mit dieser Funktion braucht man bei Seiten, die dieses System verwenden, kein SinglePage mehr.
Nachdem ich diese Stelle gesehen hatte, habe ich noch einmal genauer hingeschaut. Es geht um den Abschnitt: „Daher habe ich beschlossen, ein leichteres EPUB-Lesesystem namens Bene zu entwickeln. Das ist das, was Sie gerade verwenden. Dieses Dokument ist ein EPUB und kann über den Button oben rechts heruntergeladen werden.“
Beim Lesen im Desktop-Browser war mir das überhaupt nicht aufgefallen, bis ich direkt darauf hingewiesen wurde. Auf Mobilgeräten nimmt der Header mehr Bildschirmfläche ein und fällt dadurch stärker auf, ansonsten verhält es sich aber fast wie eine normale Webseite.
Wahrscheinlich ist das ein gutes Zeichen.
Anders als manche Kommentare hier sagen, habe ich beim ersten Laden des Dokuments keinen Spinner gesehen oder zumindest nicht bemerkt. Auf dem Smartphone war er zu sehen, verschwand aber ziemlich schnell. Ich weiß nicht, ob das das Laden des WASM-Programms war oder ob es nur beim ersten Laden passiert.
Worauf der Spinner hauptsächlich wartet, ist der Download der .epub-Datei. Diese Datei ist 4,77 MB groß, also ohne schnelle Verbindung ziemlich groß. Nach dem Entpacken entfällt der Großteil der Größe auf Bilder, etwa 99 %.
Anders als bei einer normalen Webseite oder einem PDF scheint das Rendering erst zu beginnen, wenn alle Assets, also das gesamte ePub, heruntergeladen wurden.
Ein Unterschied, den ich im Artikel erwartet hätte, der aber nicht behandelt wurde, ist die Performance. PDFs können so optimiert werden, dass Seiten weitgehend unabhängig sind, was progressives Rendering, wahlfreien Zugriff und starke Parallelisierung ermöglicht.
Auf dem Smartphone ist es mir überhaupt nicht aufgefallen, bevor ich den Artikel gelesen hatte. Ich dachte einfach, es sei eine normale Webseite, die das Projekt erklärt.
Schon allein die Tatsache, dass Browser EPUB nicht öffnen können, lässt das Projekt ein wenig wie zum Scheitern verurteilt wirken. Wenn man ein PDF verlinkt, gibt es zwar einen kleinen Kontextwechsel, aber der Browser öffnet und zeigt es an.
EPUB ist der Beschreibung nach im Grunde HTML; dass Browser es nicht öffnen, ist seltsam. Aber die Bürokraten bei Chrome/Mozilla davon zu überzeugen, dürfte nicht einfach sein.
Ein weiterer entmutigender Punkt ist, dass HTML und CSS so riesig und aufgebläht geworden sind, dass es kaum jemanden gibt, der einen „Reader“ für EPUB/HTML implementieren könnte. Im Grunde heißt das: „Implementiere einen neuen Browser.“ Ein einfach zu parsenden Markdown wie Djot zu nehmen und etwas Rendering daraufzusetzen, wirkt langfristig vielversprechender.
Mein persönlicher provisorischer Kompromiss ist, CSS, SVG, Skripte und sogar base64-Bilder komplett in eine einzige HTML-Datei zu packen. Das ist EPUB-ähnlich und etwas aufgebläht und hässlich, funktioniert aber mit ein wenig Sorgfalt, und Browser können es ganz natürlich öffnen.
Allerdings haben Nutzer keine Möglichkeit zu erkennen: „Diese Webseite kann ich herunterladen und offline aufbewahren.“ Eine Endung wie .htmls, die anzeigt, dass es HTML ohne externe Ressourcen ist, wäre wünschenswert.
Bis vor nicht allzu langer Zeit konnten Browser auch keine PDFs öffnen. Heute enthalten alle Browser einen in ASM/JS geschriebenen PDF-Reader.
Es gibt keinen offensichtlichen Grund, warum Browser bei EPUB nicht dasselbe tun könnten. Es gibt bereits Browser-Erweiterungen, die genau das machen. Die Frage ist, ob das EPUB-Format Popularität gewinnt.
HTML war ursprünglich Hypertext. Ein paar Links, Zeichnungen/Bilder und Tabellen, mehr nicht.
Dann wurden magazinartige Designs und Layouts „notwendig“, aber es blieb immer noch dokumentenbasiert und war ziemlich in Ordnung.
Später versuchte man, HTML mit Gewalt in eine Plattform zur Auslieferung von Anwendungen zu pressen. Das heutige CSS-Layout ist endlich näher an klassischen Layout-Engines für Anwendungen angekommen.
Die vergangenen 20 Jahre waren meiner Meinung nach zu einem großen Teil verschwendet, weil es keinen geeigneten Weg zur Cross-Platform-Auslieferung von Anwendungen gab. Von Java abgesehen.
Also scheint dieser Artikel selbst ein EPUB zu sein, das in einem WASM-EPUB-Viewer geöffnet wurde.
Das größte Hindernis scheint der Implementierungsumfang von HTML/CSS zu sein. Der Autor sagt: „Prinzip für die Erzeugung portablen HTMLs: Ein System, das portable EPUBs erzeugt, sollte möglichst portables HTML ausgeben“, aber das scheint nicht weit genug zu gehen.
Damit dieses Format überall reproduzierbar funktioniert, muss es standardisiert sein, und neue Rendering-Engine-Implementierungen müssen einfach sein. Sich auf WebViews zu verlassen, wirkt nicht wie der Weg nach vorn.
Das Schöne an PDF ist seine hohe Verlässlichkeit. Ein PDF von vor 10 Jahren wird heute genauso gerendert wie damals.
Damit ein solcher Ansatz Erfolg hat, müsste der Dokumentumfang wohl stark eingeschränkt werden. Die erlaubte XHTML-Teilmenge müsste sehr begrenzt sein, und die Fähigkeit, überall gleich auszusehen, müsste Vorrang haben. Zuerst ein festes Layout mit fester Seitengröße, danach reflow-fähige Dokumente. Außerdem bräuchte es einen Standard mit umfassenden Testdokumenten und Rendering-Ausgaben.
Browser bieten zwar keine bequeme UI zum Öffnen von EPUBs, sollten aber keine Probleme haben, die kapitelweisen HTML-Dateien darin zu rendern.
Wenn Browser-Unterstützung fehlt, wäre es serverseitig nicht besonders schwer, einen Proxy zu schreiben, der EPUBs in eine navigierbare Website umwandelt und Steuerelemente für Kapitelwechsel sowie einfache Layoutoptionen hinzufügt.
Allerdings dürfte die nötige DRM-Unterstützung, um mit so einem Proxy die meisten kommerziellen E-Books zu lesen, rechtlich sehr problematisch sein.
Wenn man darüber nachdenkt, wäre von Verlagen genehmigte DRM-EPUB-Unterstützung im Browser technisch nur einen halben Schritt von DRM-Unterstützung für normale Webseiten entfernt – eine ziemlich schreckliche Aussicht.
Ich halte PDF für ein furchtbares Legacy-Format mit unnötiger Komplexität. Da die meisten Einsatzbereiche von PDF nichts mit Drucken zu tun haben, überzeugt mich auch die Satzlogik nicht.
Für die meisten Use Cases ist es viel wichtiger, dass es auf Handy, Tablet und Computer gut lesbar ist.
Ich war überrascht, als der Autor schrieb, iBooks unterstütze keine Scroll-Ansicht, und habe es selbst überprüft. iBooks unter macOS unterstützt kein Scrollen von ePub-Dateien, unter iOS und iPadOS aber schon. Eine sehr merkwürdige Entscheidung von Apple. https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
Die PDF-Spezifikation ist lästig, aber es gibt schlicht keinen Ersatz dafür.
Ich habe noch nie erlebt, dass technische Dokumentation in einem Nicht-PDF-Format verteilt wurde und dabei angenehm zu lesen und zu durchsuchen war. Auch nicht auf dem Handy.
Ich will keine Dokumente, deren Aussehen sich je nach flüchtigem Zustand wie Lesegerät oder Fenstergröße ändert. Ich will Dokumente mit einem vom Autor gut gestalteten, festen Layout.
Auch beim Lesen auf kleinen Bildschirmen oder in kleinen Fenstern will ich – sofern es kein reines Textdokument ist – keinen Layoutwechsel, sondern einen intelligenten Reader mit schnellem Zoomen und Verschieben. Es sollte kein dummes Verhalten geben wie bei manchen Android-Readern, bei denen vertikales Scrollen oder Page Up/Page Down auch die horizontale Position verschiebt und damit das Lesen von Textspalten erschwert.
Schon die klassische Empfehlung für die maximale Breite von Textspalten reicht aus, um auf dem Handy bequem lesen zu können. Nur wenn Autoren übermäßig breite Spalten anlegen und klassische typografische Regeln brechen, wird das Lesen auf dem Handy unangenehm.
Der Grund, ein Dokument mit festem Layout zu wollen, ist nicht nur das Drucken. Es liegt daran, dass ein festes Dokumentlayout wichtiger ist als kleine Bildschirme.
Diesen speziellen Fall kenne ich nicht genau, aber manche Reader verhalten sich womöglich wegen der Konsistenz mit E-Ink-Geräten so. Bei E-Ink ist Scrollen wegen niedriger Bildwiederholrate, schwacher Prozessoren und Akkuschonung hardwareseitig eingeschränkt.
Deshalb scheint es eine schlechte Idee zu sein, einen einzigen Standard für alles schaffen zu wollen. Für digitale Dokumente wären zwei Standards besser: einer mit vollständigen Multimedia- und Interaktionsfunktionen, abgesehen von Networking, und ein anderer als Teilmenge davon, beschränkt auf Schwarzweiß, ohne Multimedia und mit Interaktion hauptsächlich in Form von Hyperlinks innerhalb des Dokuments.
Und im Grunde gibt es diese beiden Formate schon: HTML, MHTML=EML und EPUB.
Natürlich braucht man auch ein drittes Format für physische Archivierung und seltene digitale Dokumente mit festem Layout, und diese Rolle scheint PDF/A bereits ziemlich gut zu erfüllen.
Wenn man wirklich etwas drucken muss, ist PDF der verlässlichste und portabelste Weg.
Mehrseitiges SVG wäre vielleicht auch möglich, aber um mehrere Seiten korrekt zu drucken, müsste man es am Ende vermutlich erst nach PDF exportieren. Ich sage das mit Blick auf Inkscape.
Ich frage mich, was ein EPUB-Reader bietet, das ein Browser nicht hat. Im Moment sehe ich genau eine, eher nebensächliche Antwort: .epub-Dateien, also Zip-Dateien, wie Verzeichnisse behandeln zu können
Wenn der Unterschied zwischen einem EPUB-Reader und einer Browser-Teilmenge wirklich nur das ist, wäre der einfachste und aufwandsärmste Weg wohl dieser:
Bestehende Browser behandeln Zip-Dateien unter bestimmten Bedingungen wie Verzeichnisse
Man definiert eine mechanisch prüfbare HTML-Beschränkung, die vollständige lokale Assets garantiert, wie im Originalbeitrag beschrieben. Schon die Anforderung, dass alle URLs außer Links relative Pfade sein müssen, könnte ausreichen
Zip-Dateien, die diese Beschränkung erfüllen, werden als „portable EPUB“ deklariert
Alle dedizierten EPUB-Reader, ob bestehend oder neu, kann man vergessen
Stimme zu. Das klingt nach der eigentlichen Lösung
Für vollständig lokale Assets würde ich gern die Anforderung sehen, dass jedes Objekt eine lokal verfügbare Fallback-Option haben muss. Wenn die entsprechende Schriftart nicht geladen werden kann, nimmt man etwa eine Standardschrift. Es sieht dann nicht perfekt aus, sollte aber vernünftig funktionieren, solange man es auf den Fallback-Bereich beschränkt
Es gibt noch einen Fehlermodus, der bisher nicht ausreichend behandelt wurde: Bilder, die nicht richtig funktionieren. Grundsätzlich lassen sich Bilder nämlich nicht neu umbrechen. Ein großer Teil davon ließe sich wohl durch die Verwendung von SVG lösen, aber nicht, wenn es sich um echte Rasterbilder handelt. Am Ende bleibt vermutlich nur, mehrere Auflösungen bereitzustellen
Ich bin auch auf ein verwandtes Problem gestoßen, habe aber noch keine gute Antwort gesehen: ein SVG, das die Auflösung erkennt und bei ausreichend hoher Auflösung ein detailreicheres Bild lädt. Wenn man Subpixel-Linien zeichnet, werden sie unscharf, aber wenn man dasselbe Bild vergrößert, werden diese Linien nützlich. Windows-Icons erkennen das an, indem sie mehrere Auflösungen enthalten können und je nach Situation die passende verwenden
Der Autor ist Postdoc unter der Betreuung von Shriram Krishnamurthi. Shriram Krishnamurthi ist der Autor von Programming Languages: Application and Interpretation(PLAI) und einer der Autoren von Data-Centric Introduction to Computing(DCIC)
Ich lese gerade sowohl PLAI als auch DCIC und bin wirklich beeindruckt von der Sorgfalt bis ins Detail, die die Autoren investiert haben, um daraus didaktische Kunstwerke zu machen. Das ist echte Hingabe https://willcrichton.net/
PDF kann Schriftarten einbetten, tut das aber häufig nicht und verlässt sich auf Systemschriftarten. Ein Grund ist, dass das Einbetten von Schriftarten in ein PDF die Dateigröße stark erhöhen kann. In manchen Fällen kann eine einzelne Schriftart größer sein als der gesamte restliche Inhalt der Datei
Ich habe einmal Font-Embedding in Software implementiert, die PDFs erzeugt, und es war überraschend schwierig herauszufinden, wie man es zuverlässig zum Laufen bringt
Dass PDFs konsistent gerendert werden, stimmt auch nicht so sehr, wie man meint. Ich habe mehrmals erlebt, dass dasselbe PDF je nach verwendetem PDF-Viewer unterschiedlich gerendert wurde. Meist sind die Unterschiede subtil, aber manchmal gibt es Randfälle mit ziemlich großen Abweichungen. Ich habe sogar erlebt, dass dieselbe Version von Acrobat Reader ein PDF je nach Betriebssystem unterschiedlich rendert
Es gibt nur wenige Standard-Systemschriftarten, die in PDF-Dateien weggelassen werden dürfen, und das Dokument nimmt an, dass die fürs Rendering verwendeten Schriftarten dieselben Metriken haben wie die traditionellen Schriften Times, Helvetica und Courier
Wenn also kompatible Systemschriftarten verwendet werden, sollte sich das Layout des gerenderten Dokuments nicht ändern. Natürlich gibt es Fälle von Systemschriftarten, die als metrisch kompatibel mit alten Adobe-PostScript-Schriften beworben werden, aber subtile Unterschiede aufweisen
Abgesehen von den wenigen Standard-Systemschriftarten enthalten PDF-Dokumente normalerweise nicht die komplette Schriftart, sondern nur eine Glyphen-Teilmenge für die tatsächlich im Text verwendeten Zeichen
Über 20 Jahre lang dachte ich, PDFs würden konsistent gerendert, bis mir in einem Vorstellungsgespräch gesagt wurde, mein Dokument sehe seltsam aus, und ich erst dadurch erfuhr, dass Schriftarten fehlen können
Das war The Daily WTF im Alltag
Ich frage mich, ob es Software gibt, die Schriftarten minimiert, indem sie Codepoints entfernt, die im Dokument nicht verwendet werden
1 Kommentare
Meinungen auf Hacker News
Ich interessiere mich sehr für die Schnittmenge aus E-Books, Sicherheit und dem LowJS Web, daher erscheint mir dieses Thema wichtig.
Ein portables E-Book-Format als einzelne Datei ist nötig, aber PDF ist nicht die Antwort, weil Text dort nicht neu umbrochen werden kann.
HTML+CSS im Jahr 2024 kann nahezu alle Printmedien nachbilden und gleichzeitig Text-Reflow ermöglichen.
Ich finde nicht, dass JavaScript zwingend erforderlich sein sollte. Ein E-Book sollte ein Buch sein, dessen Größe sich sinnvoll ändern lässt, und auch bei deaktiviertem JavaScript sollten die Grundfunktionen als Buch funktionieren. Für Interaktion oder Erweiterungen kann JavaScript genutzt werden, aber wenn es ohne JavaScript nicht als Buch funktioniert, sehe ich das als Bug.
Alle Styles inline unterzubringen halte ich für einen Fehler, weil das die CSP mancher Nutzer brechen kann. Styles sollten als Ressourcen mit relativen Pfaden ausgehend vom HTML ausgelagert werden, und E-Books sollten das Laden von Ressourcen von anderen Domains verbieten.
Schließlich kann man es einfach als zip-Datei ausliefern. Ich glaube, E-Books funktionieren ohnehin schon so.
Umgekehrt gilt das aber nicht unbedingt. Selbst wenn dasselbe Dateibündel vor dem Entpacken ein gültiges EPUB war, kann es ungültig werden, wenn man es beliebig wieder als zip packt.
Die mimetype-Datei in einem EPUB-zip ist besonders: Sie muss der erste Eintrag im Archiv sein, ihr Inhalt darf nur
application/epub+zipsein, und sie muss unkomprimiert gespeichert werden.Überraschend viele zip-Tools machen das lästig, weil sie die Dateireihenfolge ändern oder es schwer machen, nur bestimmte Dateien unkomprimiert zu speichern. Mit dem zip-Programm auf der Kommandozeile geht es meist per Flag, aber mit zip-Bibliotheken ist es ziemlich schmerzhaft. Das sage ich aus Erfahrung mit der Entwicklung von EPUB-Erstellungssoftware.
Beschrieben wurde das ePub-Format, bei dem HTML-, CSS- und Bilddateien in einem zip-Archiv liegen.
Eine CSP, um es sicher zu machen, ist ebenfalls enthalten.
Was an den alten .doc-Dateien im Vergleich zu .docx angenehm war: In Ordnern mit Hunderten bis Tausenden Dateien konnte man sehr schnell nach einem bestimmten Wort suchen. Mit dem zip-Format geht das nicht.
Ich habe gerade etwas als .doc gespeichert und in einem Hex-Editor geöffnet; der eigentliche Inhalt lag tatsächlich im Klartext vor. zip-Formate oder PDF-Dateien sind mit grep schwer zu durchsuchen, und ich bezweifle, dass Kompression für Text von vielleicht ein paar Tausend Zeichen überhaupt nötig ist.
Das ist ein sehr gut strukturierter Artikel des Nota-Entwicklers, der versucht, das EPUB-Format auf eine Stufe mit PDF zu heben. Einen Viewer gibt es bereits, und der Artikel selbst wird in einem browserbasierten WASM-Port dieses Viewers angezeigt.
Eines der Probleme ist, wie exakt EPUB, das praktisch XHTML ist, Layouts reproduzieren kann. Der Maßstab des Originalartikels ist, dass ein Dokument „plausibel“ aussieht; um mit PDF gleichzuziehen, klingt es so, als bräuchte HTML zumindest beim Zeilenumbruch neue Layout-Funktionen.
Ich sehe zwei Wege voran. Einer ist, dass Browser mehr Typografie-Werkzeuge bereitstellen;
text-wrap: prettysoll helfen, aber bei einem kurzen Test schien mir die Qualität der Zeilenumbrüche nicht besser zu werden. Der andere ist, Zeilenumbrüche vorab zu berechnen, was aber nur bei Fixed-Layout-Rendering möglich ist.Außerdem erwähnt der Autor zwar Anmerkungen, aber ich bin mir nicht sicher, wie er sie umsetzen will.
Das ist auch in EPUB3 bereits möglich, hat aber den Nachteil, dass es auf Bildschirmen wie Smartphones nicht gut aussieht. Je nach Reader können die Vorgaben überschrieben werden, aber dann muss man hoffen, dass der Reader das Dokument wieder ansprechend aufbereitet.
Eine Alternative wäre, dass ein EPUB mehrere Renderings für gängige Bildschirmtypen angibt. Das ist nicht perfekt, wirkt aber wie ein guter Kompromiss: Dokumentautoren liefern sinnvolle Defaults, und Nutzer können sie bei Bedarf überschreiben.
Was ein E-Book-Format braucht, ist semantisches Markup, das sich an das Gerät anpasst, auf dem es gerendert wird. HTML+CSS wurde ursprünglich genau für diesen Zweck geschaffen.
Deshalb müssen Buchlayout-Ersteller bewusst einen Teil der Kontrolle darüber, wie ein Buch aussieht, an die Leser abgeben. Ein wenig visuelle Unvollkommenheit ist diesen Preis wert. Wenn visuelle Perfektion nötig ist, nimmt man PDF.
Natürlich wird es schwieriger, wenn interaktive Elemente hinzukommen. Große interaktive Elemente sollten bei Bedarf in einer eigenen Ansicht geöffnet werden, kleine interaktive Elemente sollten Reflow akzeptieren.
Anmerkungen und Referenzen sind doch bereits Teil der EPUB-Spezifikation, vielleicht sogar der HTML-Spezifikation, denke ich.
Außerdem bin ich nicht einverstanden damit, dass langes Drücken für ein Popup besser sein soll als ein gewöhnlicher Hyperlink-Anker. Wenn die „Zurück“-Funktion des Readers ordentlich funktioniert oder bidirektionale Referenzen einen „Zurück“-Link haben, ist Navigation deutlich weniger störend.
Die Idee war, ein XML-Dokument zusammen mit einem XSL-Stylesheet auszuliefern, es für das Rendering in FO umzuwandeln und für dasselbe Dokument mehrere Stylesheets für verschiedene Zielgeräte oder Seitengrößen bereitzuhalten.
In Firefox nutze ich das SinglePage-Add-on, um das DOM der aktuellen Seite als eigenständige HTML-Datei zu speichern. Dabei werden CSS und
data:-URLs für Bilder inline eingebettet, Abhängigkeiten und Skripte werden entfernt.Perfekt ist das nicht, und ich vertraue nicht darauf, dass Browser immer abwärtskompatibel bleiben, aber ich bevorzuge es gegenüber dem Speichern einer Seite als PDF oder als mehrere Dateien.
Interessanterweise war einer der wenigen Fälle, in denen dieses Add-on versagte, ausgerechnet dieser Artikel über portable EPUBs. Offenbar steckt darin zu viel Magie, um die Formatierung hinzubekommen. Die gespeicherte Seite war zwar lesbar, sah stilistisch aber völlig anders aus als das Original.
Mir gefällt, dass fbreader unter Android alle Bücher gleich gemäß den App-Einstellungen darstellt, statt nach dem Stil der EPUB-Datei. Ich habe nie gesehen, dass es CSS anwendet oder versucht, in der Datei enthaltene Skripte auszuführen, und hoffe, dass das auch so bleibt. Externe Abhängigkeiten zu laden ist eine noch schlechtere Idee, und ich wusste nicht einmal, dass das überhaupt erlaubt ist.
Apropos: Das Berechtigungssystem für Firefox-Add-ons ist seltsam. Um irgendetwas Interessantes zu tun, muss man praktisch alle Berechtigungen anfordern, und dadurch entsteht ein natürlicher Markt für böswillige Akteure, die nach Add-ons suchen, die sie übernehmen können.
Zum Beispiel braucht das SingleFile-Add-on natürlich Zugriff, weil es das gerenderte DOM inspizieren und in eine Datei speichern muss. Aber warum muss es auf alles zugreifen? Könnte man nicht nur Berechtigungen wie
snapshot DOM onceundwrite to a single filevergeben?Damals konnte ich den Grund wohl weder gut erklären noch selbst richtig verstehen, und es wurde behandelt, als wäre es ein absurder Wunsch. Rückblickend scheint es, als hätte ich einfach ungefähr zehn Jahre neben der Zeit gelegen, was mich freut.
KOReader ist weniger benutzerfreundlich, bietet aber mehr Kontrolle. Man kann aus mehreren mitgelieferten CSS-Dateien eine bestimmte auswählen oder selbst eine schreiben.
Zu den Stärken von KOReader gehören außerdem die hervorragende OPDS-Unterstützung und ein einfach selbst zu hostender Synchronisationsserver.
Mit dieser Funktion braucht man bei Seiten, die dieses System verwenden, kein SinglePage mehr.
Nachdem ich diese Stelle gesehen hatte, habe ich noch einmal genauer hingeschaut. Es geht um den Abschnitt: „Daher habe ich beschlossen, ein leichteres EPUB-Lesesystem namens Bene zu entwickeln. Das ist das, was Sie gerade verwenden. Dieses Dokument ist ein EPUB und kann über den Button oben rechts heruntergeladen werden.“
Beim Lesen im Desktop-Browser war mir das überhaupt nicht aufgefallen, bis ich direkt darauf hingewiesen wurde. Auf Mobilgeräten nimmt der Header mehr Bildschirmfläche ein und fällt dadurch stärker auf, ansonsten verhält es sich aber fast wie eine normale Webseite.
Wahrscheinlich ist das ein gutes Zeichen.
Anders als manche Kommentare hier sagen, habe ich beim ersten Laden des Dokuments keinen Spinner gesehen oder zumindest nicht bemerkt. Auf dem Smartphone war er zu sehen, verschwand aber ziemlich schnell. Ich weiß nicht, ob das das Laden des WASM-Programms war oder ob es nur beim ersten Laden passiert.
Anders als bei einer normalen Webseite oder einem PDF scheint das Rendering erst zu beginnen, wenn alle Assets, also das gesamte ePub, heruntergeladen wurden.
Ein Unterschied, den ich im Artikel erwartet hätte, der aber nicht behandelt wurde, ist die Performance. PDFs können so optimiert werden, dass Seiten weitgehend unabhängig sind, was progressives Rendering, wahlfreien Zugriff und starke Parallelisierung ermöglicht.
Schon allein die Tatsache, dass Browser EPUB nicht öffnen können, lässt das Projekt ein wenig wie zum Scheitern verurteilt wirken. Wenn man ein PDF verlinkt, gibt es zwar einen kleinen Kontextwechsel, aber der Browser öffnet und zeigt es an.
EPUB ist der Beschreibung nach im Grunde HTML; dass Browser es nicht öffnen, ist seltsam. Aber die Bürokraten bei Chrome/Mozilla davon zu überzeugen, dürfte nicht einfach sein.
Ein weiterer entmutigender Punkt ist, dass HTML und CSS so riesig und aufgebläht geworden sind, dass es kaum jemanden gibt, der einen „Reader“ für EPUB/HTML implementieren könnte. Im Grunde heißt das: „Implementiere einen neuen Browser.“ Ein einfach zu parsenden Markdown wie Djot zu nehmen und etwas Rendering daraufzusetzen, wirkt langfristig vielversprechender.
Mein persönlicher provisorischer Kompromiss ist, CSS, SVG, Skripte und sogar base64-Bilder komplett in eine einzige HTML-Datei zu packen. Das ist EPUB-ähnlich und etwas aufgebläht und hässlich, funktioniert aber mit ein wenig Sorgfalt, und Browser können es ganz natürlich öffnen.
Allerdings haben Nutzer keine Möglichkeit zu erkennen: „Diese Webseite kann ich herunterladen und offline aufbewahren.“ Eine Endung wie
.htmls, die anzeigt, dass es HTML ohne externe Ressourcen ist, wäre wünschenswert.Es gibt keinen offensichtlichen Grund, warum Browser bei EPUB nicht dasselbe tun könnten. Es gibt bereits Browser-Erweiterungen, die genau das machen. Die Frage ist, ob das EPUB-Format Popularität gewinnt.
Dann wurden magazinartige Designs und Layouts „notwendig“, aber es blieb immer noch dokumentenbasiert und war ziemlich in Ordnung.
Später versuchte man, HTML mit Gewalt in eine Plattform zur Auslieferung von Anwendungen zu pressen. Das heutige CSS-Layout ist endlich näher an klassischen Layout-Engines für Anwendungen angekommen.
Die vergangenen 20 Jahre waren meiner Meinung nach zu einem großen Teil verschwendet, weil es keinen geeigneten Weg zur Cross-Platform-Auslieferung von Anwendungen gab. Von Java abgesehen.
Damit dieses Format überall reproduzierbar funktioniert, muss es standardisiert sein, und neue Rendering-Engine-Implementierungen müssen einfach sein. Sich auf WebViews zu verlassen, wirkt nicht wie der Weg nach vorn.
Das Schöne an PDF ist seine hohe Verlässlichkeit. Ein PDF von vor 10 Jahren wird heute genauso gerendert wie damals.
Damit ein solcher Ansatz Erfolg hat, müsste der Dokumentumfang wohl stark eingeschränkt werden. Die erlaubte XHTML-Teilmenge müsste sehr begrenzt sein, und die Fähigkeit, überall gleich auszusehen, müsste Vorrang haben. Zuerst ein festes Layout mit fester Seitengröße, danach reflow-fähige Dokumente. Außerdem bräuchte es einen Standard mit umfassenden Testdokumenten und Rendering-Ausgaben.
Wenn Browser-Unterstützung fehlt, wäre es serverseitig nicht besonders schwer, einen Proxy zu schreiben, der EPUBs in eine navigierbare Website umwandelt und Steuerelemente für Kapitelwechsel sowie einfache Layoutoptionen hinzufügt.
Allerdings dürfte die nötige DRM-Unterstützung, um mit so einem Proxy die meisten kommerziellen E-Books zu lesen, rechtlich sehr problematisch sein.
Wenn man darüber nachdenkt, wäre von Verlagen genehmigte DRM-EPUB-Unterstützung im Browser technisch nur einen halben Schritt von DRM-Unterstützung für normale Webseiten entfernt – eine ziemlich schreckliche Aussicht.
Ich halte PDF für ein furchtbares Legacy-Format mit unnötiger Komplexität. Da die meisten Einsatzbereiche von PDF nichts mit Drucken zu tun haben, überzeugt mich auch die Satzlogik nicht.
Für die meisten Use Cases ist es viel wichtiger, dass es auf Handy, Tablet und Computer gut lesbar ist.
Ich war überrascht, als der Autor schrieb, iBooks unterstütze keine Scroll-Ansicht, und habe es selbst überprüft. iBooks unter macOS unterstützt kein Scrollen von ePub-Dateien, unter iOS und iPadOS aber schon. Eine sehr merkwürdige Entscheidung von Apple.
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
Ich habe noch nie erlebt, dass technische Dokumentation in einem Nicht-PDF-Format verteilt wurde und dabei angenehm zu lesen und zu durchsuchen war. Auch nicht auf dem Handy.
Ich will keine Dokumente, deren Aussehen sich je nach flüchtigem Zustand wie Lesegerät oder Fenstergröße ändert. Ich will Dokumente mit einem vom Autor gut gestalteten, festen Layout.
Auch beim Lesen auf kleinen Bildschirmen oder in kleinen Fenstern will ich – sofern es kein reines Textdokument ist – keinen Layoutwechsel, sondern einen intelligenten Reader mit schnellem Zoomen und Verschieben. Es sollte kein dummes Verhalten geben wie bei manchen Android-Readern, bei denen vertikales Scrollen oder Page Up/Page Down auch die horizontale Position verschiebt und damit das Lesen von Textspalten erschwert.
Schon die klassische Empfehlung für die maximale Breite von Textspalten reicht aus, um auf dem Handy bequem lesen zu können. Nur wenn Autoren übermäßig breite Spalten anlegen und klassische typografische Regeln brechen, wird das Lesen auf dem Handy unangenehm.
Deshalb scheint es eine schlechte Idee zu sein, einen einzigen Standard für alles schaffen zu wollen. Für digitale Dokumente wären zwei Standards besser: einer mit vollständigen Multimedia- und Interaktionsfunktionen, abgesehen von Networking, und ein anderer als Teilmenge davon, beschränkt auf Schwarzweiß, ohne Multimedia und mit Interaktion hauptsächlich in Form von Hyperlinks innerhalb des Dokuments.
Und im Grunde gibt es diese beiden Formate schon: HTML, MHTML=EML und EPUB.
Natürlich braucht man auch ein drittes Format für physische Archivierung und seltene digitale Dokumente mit festem Layout, und diese Rolle scheint PDF/A bereits ziemlich gut zu erfüllen.
Mehrseitiges SVG wäre vielleicht auch möglich, aber um mehrere Seiten korrekt zu drucken, müsste man es am Ende vermutlich erst nach PDF exportieren. Ich sage das mit Blick auf Inkscape.
Vor 8 Tagen gab es „Portable Web Documents – An Alternative to PDF Based on HTML5 (2019)“, das 134 Punkte bekam
https://news.ycombinator.com/item?id=39036774
https://news.ycombinator.com/item?id=39037135
Ich frage mich, was ein EPUB-Reader bietet, das ein Browser nicht hat. Im Moment sehe ich genau eine, eher nebensächliche Antwort: .epub-Dateien, also Zip-Dateien, wie Verzeichnisse behandeln zu können
Wenn der Unterschied zwischen einem EPUB-Reader und einer Browser-Teilmenge wirklich nur das ist, wäre der einfachste und aufwandsärmste Weg wohl dieser:
Bestehende Browser behandeln Zip-Dateien unter bestimmten Bedingungen wie Verzeichnisse
Man definiert eine mechanisch prüfbare HTML-Beschränkung, die vollständige lokale Assets garantiert, wie im Originalbeitrag beschrieben. Schon die Anforderung, dass alle URLs außer Links relative Pfade sein müssen, könnte ausreichen
Zip-Dateien, die diese Beschränkung erfüllen, werden als „portable EPUB“ deklariert
Alle dedizierten EPUB-Reader, ob bestehend oder neu, kann man vergessen
Für vollständig lokale Assets würde ich gern die Anforderung sehen, dass jedes Objekt eine lokal verfügbare Fallback-Option haben muss. Wenn die entsprechende Schriftart nicht geladen werden kann, nimmt man etwa eine Standardschrift. Es sieht dann nicht perfekt aus, sollte aber vernünftig funktionieren, solange man es auf den Fallback-Bereich beschränkt
Es gibt noch einen Fehlermodus, der bisher nicht ausreichend behandelt wurde: Bilder, die nicht richtig funktionieren. Grundsätzlich lassen sich Bilder nämlich nicht neu umbrechen. Ein großer Teil davon ließe sich wohl durch die Verwendung von SVG lösen, aber nicht, wenn es sich um echte Rasterbilder handelt. Am Ende bleibt vermutlich nur, mehrere Auflösungen bereitzustellen
Ich bin auch auf ein verwandtes Problem gestoßen, habe aber noch keine gute Antwort gesehen: ein SVG, das die Auflösung erkennt und bei ausreichend hoher Auflösung ein detailreicheres Bild lädt. Wenn man Subpixel-Linien zeichnet, werden sie unscharf, aber wenn man dasselbe Bild vergrößert, werden diese Linien nützlich. Windows-Icons erkennen das an, indem sie mehrere Auflösungen enthalten können und je nach Situation die passende verwenden
Der Autor ist Postdoc unter der Betreuung von Shriram Krishnamurthi. Shriram Krishnamurthi ist der Autor von Programming Languages: Application and Interpretation(PLAI) und einer der Autoren von Data-Centric Introduction to Computing(DCIC)
Ich lese gerade sowohl PLAI als auch DCIC und bin wirklich beeindruckt von der Sorgfalt bis ins Detail, die die Autoren investiert haben, um daraus didaktische Kunstwerke zu machen. Das ist echte Hingabe
https://willcrichton.net/
https://rust-book.cs.brown.edu/
PDF kann Schriftarten einbetten, tut das aber häufig nicht und verlässt sich auf Systemschriftarten. Ein Grund ist, dass das Einbetten von Schriftarten in ein PDF die Dateigröße stark erhöhen kann. In manchen Fällen kann eine einzelne Schriftart größer sein als der gesamte restliche Inhalt der Datei
Ich habe einmal Font-Embedding in Software implementiert, die PDFs erzeugt, und es war überraschend schwierig herauszufinden, wie man es zuverlässig zum Laufen bringt
Dass PDFs konsistent gerendert werden, stimmt auch nicht so sehr, wie man meint. Ich habe mehrmals erlebt, dass dasselbe PDF je nach verwendetem PDF-Viewer unterschiedlich gerendert wurde. Meist sind die Unterschiede subtil, aber manchmal gibt es Randfälle mit ziemlich großen Abweichungen. Ich habe sogar erlebt, dass dieselbe Version von Acrobat Reader ein PDF je nach Betriebssystem unterschiedlich rendert
Wenn also kompatible Systemschriftarten verwendet werden, sollte sich das Layout des gerenderten Dokuments nicht ändern. Natürlich gibt es Fälle von Systemschriftarten, die als metrisch kompatibel mit alten Adobe-PostScript-Schriften beworben werden, aber subtile Unterschiede aufweisen
Abgesehen von den wenigen Standard-Systemschriftarten enthalten PDF-Dokumente normalerweise nicht die komplette Schriftart, sondern nur eine Glyphen-Teilmenge für die tatsächlich im Text verwendeten Zeichen
Das war The Daily WTF im Alltag