wegus
MU Team
- Dabei seit
- 13.09.2004
- Beiträge
- 19.695
- Reaktionspunkte
- 7.547
Webseite inkl. aller Bilder als "Single-HTML-File" speichern - nicht als MHTML
T
thulium
Aktives Mitglied
Thread Starter
- Dabei seit
- 12.11.2011
- Beiträge
- 3.651
- Reaktionspunkte
- 390
@wegus
Danke! Klappte einwandfrei.
@warnochfrei
Sehr coole Sache! Danke für das Skript : )
Eigentlich erstaunlich, dass diese Methode nicht in jedem Browser fest integriert ist.
Einen Webinhalt archivieren zu können ist ja in zig Situationen eine feine Sache.
Zu schade, dass man mit dem Skript keine lokal gespeicherte oder lokal im Browser geöffnete Webseite umwandeln kann.
Sollte Dir dazu später nochmal eine Lösung einfallen, lasse es mich bitte wissen
Danke! Klappte einwandfrei.
@warnochfrei
Sehr coole Sache! Danke für das Skript : )
Eigentlich erstaunlich, dass diese Methode nicht in jedem Browser fest integriert ist.
Einen Webinhalt archivieren zu können ist ja in zig Situationen eine feine Sache.
Zu schade, dass man mit dem Skript keine lokal gespeicherte oder lokal im Browser geöffnete Webseite umwandeln kann.
Sollte Dir dazu später nochmal eine Lösung einfallen, lasse es mich bitte wissen
Difool
MU Team
- Dabei seit
- 18.03.2004
- Beiträge
- 20.393
- Reaktionspunkte
- 15.746
@thulium
Das geht schon, wenn man bsw. ein CMS benutzt, welches bsw. mit GitHub Sync (git-sync Plugin) kommunizieren kann.
Dann kannst du lokal arbeiten und die Dateien werden via Repository versioniert und via "git-sync Plugin" automatisch live geschaltet.
Für reine "manuelle sites" (php,html,css…etc.) ist das sicherlich auch so machbar.
Das geht schon, wenn man bsw. ein CMS benutzt, welches bsw. mit GitHub Sync (git-sync Plugin) kommunizieren kann.
Dann kannst du lokal arbeiten und die Dateien werden via Repository versioniert und via "git-sync Plugin" automatisch live geschaltet.
Für reine "manuelle sites" (php,html,css…etc.) ist das sicherlich auch so machbar.
W
warnochfrei
unregistriert
- Dabei seit
- 02.03.2019
- Beiträge
- 2.594
- Reaktionspunkte
- 1.299
Ersteres könnte man. Ich müsste das aber mal testen.
T
thulium
Aktives Mitglied
Thread Starter
- Dabei seit
- 12.11.2011
- Beiträge
- 3.651
- Reaktionspunkte
- 390
Laut
<https://stackoverflow.com/questions/695151/data-protocol-url-size-limitations>
dürfen Data-URLs nicht größer als 2MB sein.
Mein Test mit einem 23MB großen Dokument, durch Dein Skript erzeugt, lief jedoch sowohl auf FF und Chrome erfolgreich. Beides sind die aktuellsten Versionen.
Wenn Data-URLs jedoch auf älteren Browsern, anderen Plattformen Probleme machen, dann könnte man die Idee mit Base64 beerdigen.
<https://stackoverflow.com/questions/695151/data-protocol-url-size-limitations>
dürfen Data-URLs nicht größer als 2MB sein.
Mein Test mit einem 23MB großen Dokument, durch Dein Skript erzeugt, lief jedoch sowohl auf FF und Chrome erfolgreich. Beides sind die aktuellsten Versionen.
Wenn Data-URLs jedoch auf älteren Browsern, anderen Plattformen Probleme machen, dann könnte man die Idee mit Base64 beerdigen.
W
warnochfrei
unregistriert
- Dabei seit
- 02.03.2019
- Beiträge
- 2.594
- Reaktionspunkte
- 1.299
Das freut mich! Aber das war doch dann bestimmt mehr als nur ein Bild?
Ich hoffe, dass die wenigsten Bilder im Web 2 MB überschreiten. Alternativen kenne ich nicht.
W
warnochfrei
unregistriert
- Dabei seit
- 02.03.2019
- Beiträge
- 2.594
- Reaktionspunkte
- 1.299
Zum Thema lokale Dateien: prüf mal, ob mein Script das mit „file://-URLs“ hinbekommt. (Ich kann gerade nicht.)
T
thulium
Aktives Mitglied
Thread Starter
- Dabei seit
- 12.11.2011
- Beiträge
- 3.651
- Reaktionspunkte
- 390
Diese Seite habe ich gewählt:
https://borumat.de/iphone-zur-kommunikation-im-notfall-fuer-senioren
Ja, es sind mehrere Bilder
Darauf kann man sich heute nicht mehr verlassen.
Wenn die Aussage von Stackoverflow stimmt, muss ich eine andere Lösung suchen.
Die Lösung muss völlig frei von Huddel und Widrigkeiten für den Empfänger sein.
Dann bliebe wohl nur EPUB als Format, weil es ein Container ist, der Bilder (und andere einzubettende Objekte) enthalten kann.
W
warnochfrei
unregistriert
- Dabei seit
- 02.03.2019
- Beiträge
- 2.594
- Reaktionspunkte
- 1.299
Wäh...
Aber: "Although Firefox supports data URLs of essentially unlimited length, browsers are not required to support any particular maximum length of data." Das heißt: Wenn du Firefox nutzt, ist das Problem für dich erst mal gelöst. (Voll gut, diese portablen Webdinge... viel geiler als Desktop... konnte nicht widerstehen.)
Nimm doch PDF. Das ist portabler. (Daher der Name.)
T
thulium
Aktives Mitglied
Thread Starter
- Dabei seit
- 12.11.2011
- Beiträge
- 3.651
- Reaktionspunkte
- 390
PDF passt sich nicht an Bildschirmbreiten an, daher ist es völlig ungeeignet für das Lesen an (schmalen) Displays.
W
warnochfrei
unregistriert
- Dabei seit
- 02.03.2019
- Beiträge
- 2.594
- Reaktionspunkte
- 1.299
Stimmt, das hatte ich nicht bedacht. Ich nehme es zurück.
T
thulium
Aktives Mitglied
Thread Starter
- Dabei seit
- 12.11.2011
- Beiträge
- 3.651
- Reaktionspunkte
- 390
Kein Problem : ) Wenn man hauptsächlich an großen Displays arbeitet fallen die Nachteile von PDFs nicht so in's Gewicht. Aber schon auf einem Tablet kann man PDFs völlig knicken. Verstärkt gilt das für Menschen, die eine Sehschwäche haben und größere Schriften brauchen, wie z.B. viele Ältere.
Aus meiner Sicht ist es sehr schräg, dass trotz aller Rufe nach "papierlos" und "Digitalisierung" immer noch PDF als Austauschformat so populär ist. Nervt mich seit Jahrzehnten.
Zurück zu möglichen Lösungen:
Testweise habe ich mal den Online-Konvertierungdienst https://convertio.co/de/ ausprobiert, mit einer in Firefox als "komplett" gespeicherten Webseite (dabei wird ein Ordner mit allen eingebetteten Inhalten angelegt) plus HTML-Seite.
Resultat:
Da kommt Mist raus. Zum Beispiel werden die ganzen Menüs der Webseite vollständig an den Anfang gesetzt. Für eine sinnvolle Umwandlung in ePub wäre eben eine sinnvolle Interpretation des CSS nötig (über Heuristiken?).
Ein weitere Ansatz, den ich jedoch noch nicht verfolgt habe:
Es gibt Aggregatoren für Inhalte (gedacht für ein späteres Lesen). Die hatten meiner Erinnerung nach exzellente Heuristiken und haben gestalterischen CSS-Mist exzellent herausgekickt. Aber vermutlich funktionieren Sie nur mit URLs, also nicht bei Bezahlschranken.
Es sieht also ganz danach aus, dass die Aufgabe unlösbar bleiben wird
Aus meiner Sicht ist es sehr schräg, dass trotz aller Rufe nach "papierlos" und "Digitalisierung" immer noch PDF als Austauschformat so populär ist. Nervt mich seit Jahrzehnten.
Zurück zu möglichen Lösungen:
Testweise habe ich mal den Online-Konvertierungdienst https://convertio.co/de/ ausprobiert, mit einer in Firefox als "komplett" gespeicherten Webseite (dabei wird ein Ordner mit allen eingebetteten Inhalten angelegt) plus HTML-Seite.
Resultat:
Da kommt Mist raus. Zum Beispiel werden die ganzen Menüs der Webseite vollständig an den Anfang gesetzt. Für eine sinnvolle Umwandlung in ePub wäre eben eine sinnvolle Interpretation des CSS nötig (über Heuristiken?).
Ein weitere Ansatz, den ich jedoch noch nicht verfolgt habe:
Es gibt Aggregatoren für Inhalte (gedacht für ein späteres Lesen). Die hatten meiner Erinnerung nach exzellente Heuristiken und haben gestalterischen CSS-Mist exzellent herausgekickt. Aber vermutlich funktionieren Sie nur mit URLs, also nicht bei Bezahlschranken.
Es sieht also ganz danach aus, dass die Aufgabe unlösbar bleiben wird