1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › PDF: Vernichtendes Urteil von…

Suche

  1. Thema

Neues Thema Ansicht wechseln


  1. Suche

    Autor: -Jake- 11.08.20 - 12:20

    ...ist für mich ein Vorteil von PDFs. Wie soll das bei HTML Webseiten die in zig Dateien aufgeteilt sind funktionieren? Alles erst herunterladen und lokal grep -r (oder Ähnliches) laufen lassen ist ja auch nicht praktikabel. Man kann natürlich auf Google etc. zurückgreifen, es dauert aber deutlich länger erst die Suche zu laden, die Seite zu finden und danach trotzdem noch Strg+F zu nutzen um die genaue Stelle zu finden. Außerdem ist dort oft nicht alles im Index.
    Noch schwieriger ist es wenn die Website nur aus JS besteht und der eigentliche Inhalt erst dynamisch nachgeladen wird, dann ist suchen fast schon unmöglich.

    Bei rein informativen Dokumenten mit zusammenhängenden Inhalt sehe ich keinen Vorteil für HTML. Man braucht nicht immer mehrere MB an Javascript um alles interaktiv und animiert darzustellen, das lenkt beim lesen eher ab. Genauso wie die Ladezeit nach jeder Seite.
    Jedes ordentlich erstellte PDF enthält auch ein Inhaltsverzeichnis und interne Links sind auch möglich (aber relativ selten nötig). Hat Alles seine Daseinsberechtigung.

  2. Re: Suche

    Autor: TheUnichi 11.08.20 - 16:29

    -Jake- schrieb:
    --------------------------------------------------------------------------------
    > ...ist für mich ein Vorteil von PDFs. Wie soll das bei HTML Webseiten die
    > in zig Dateien aufgeteilt sind funktionieren? Alles erst herunterladen und
    > lokal grep -r (oder Ähnliches) laufen lassen ist ja auch nicht praktikabel.

    Warum ist das nicht praktikabel? Wie ist das bei deiner PDF, die musst du nicht vorher irgendwo abspeichern, bevor du sie durchsuchen kannst? Du kannst einfach so online ein Repository von PDFs durchsuchen?

    Warum soll eine HTML-Datei potenziell weniger Inhalt haben müssen als eine PDF-Datei?

    > Man kann natürlich auf Google etc. zurückgreifen, es dauert aber deutlich
    > länger erst die Suche zu laden, die Seite zu finden und danach trotzdem
    > noch Strg+F zu nutzen um die genaue Stelle zu finden. Außerdem ist dort oft
    > nicht alles im Index.

    Wenn du in deinem Unternehmen entscheidest, HTML für Dokumente zu nutzen, kann man sich auch zusätzliche Suchsysteme dazuinstallieren (ES-Server, Lucene shit, eigene Indexer. Wenn man es braucht, Systeme können halt auch Volltext-Suche, etwas was bei PDF nur im unkomprimierten Zustand überhaupt möglich ist, bei HTML einfach nativ.

    > Noch schwieriger ist es wenn die Website nur aus JS besteht und der
    > eigentliche Inhalt erst dynamisch nachgeladen wird, dann ist suchen fast
    > schon unmöglich.

    Ja, genau. Man will sich ja auch üblicherweise ganze Web-Apps als Dokument abspeichern, nicht _ein Dokument_.

    Wenn eine Website dir ein Dokument generiert, kannst du zu 100% davon ausgehen, dass da weder JS noch irgendwelche UI-Libraries zwischen hängen. Mal davon abgesehen, dass es einfach unsinnig ist, wäre es auch viel zu umständlich.

    Viele UI-Systeme, z.B. React, beherrschen auch SSR oder können auch clientseitig direkt HTML rendern, da hast du sehr wohl strukturiertes HTML mit sauberem Inhalt.

    > Bei rein informativen Dokumenten mit zusammenhängenden Inhalt sehe ich
    > keinen Vorteil für HTML. Man braucht nicht immer mehrere MB an Javascript
    > um alles interaktiv und animiert darzustellen, das lenkt beim lesen eher
    > ab. Genauso wie die Ladezeit nach jeder Seite.

    Das durchschnittliche HTML-Dokument ist definitiv nicht größer als die durchschnittliche PDF. Komprimierung passiert auf Protokoll-Ebene (PDF = Zip, HTML üblicherweise Gzip oder deflate/zip). Vor allem einmal in 300 DPI, eingescannt, wieder als PDF abgespeichert, schon hast du nur noch einen riesigen, 300MB großen Binär-Blob bestehend aus Pixel-Daten anstatt sauber strukturierte Informationen. Danach ist auch mit Suchen vorbei. Sehr gut!

    Für Animationen brauchst du....3 Zeilen CSS (animations) oder 1 Zeile (transitions) und für Charts etc. kann man Inline-SVG verwenden, die sich vollständig durch CSS animieren lassen. Da ist so erst mal nicht eine Zeile JS für notwendig, aber schön, dass du auf dem neuesten Stand bleibst. Bessert deine Diskussionsgrundlage sicherlich enorm.

    > Jedes ordentlich erstellte PDF enthält auch ein Inhaltsverzeichnis und
    > interne Links sind auch möglich (aber relativ selten nötig). Hat Alles
    > seine Daseinsberechtigung.

    Kannst du aus HTML auch generieren (H1-H6, funktioniert in PDF nicht anders) und Interne Links sind in HTML durch URL-Fragmente genau so möglich. Was ist das für ein Argument?



    3 mal bearbeitet, zuletzt am 11.08.20 16:33 durch TheUnichi.

  3. Re: Suche

    Autor: -Jake- 11.08.20 - 21:22

    TheUnichi schrieb:
    --------------------------------------------------------------------------------
    > Warum soll eine HTML-Datei potenziell weniger Inhalt haben müssen als eine
    > PDF-Datei?

    Weil das die Konvention ist, vergleiche mal Dokumentationen in HTML und PDF. Keiner schreibt lange HTML Seiten, wäre auch bad practice.
    Bei PDF sind hunderte Seiten in einem Dokument nicht unüblich. Bitte auch mal den Artikel lesen, dort wurde auch explizit gefordert: "entsprechend in viele Dateien aufgeteilt ist und viele Hypertext-Links enthält"

    > > Man kann natürlich auf Google etc. zurückgreifen, es dauert aber
    > deutlich
    > > länger erst die Suche zu laden, die Seite zu finden und danach trotzdem
    > > noch Strg+F zu nutzen um die genaue Stelle zu finden. Außerdem ist dort
    > oft
    > > nicht alles im Index.
    >
    > Wenn du in deinem Unternehmen entscheidest, HTML für Dokumente zu nutzen,
    > kann man sich auch zusätzliche Suchsysteme dazuinstallieren (ES-Server,
    > Lucene shit, eigene Indexer. Wenn man es braucht, Systeme können halt auch
    > Volltext-Suche, etwas was bei PDF nur im unkomprimierten Zustand überhaupt
    > möglich ist, bei HTML einfach nativ.
    Das funktioniert nur so lange alle Ressourcen im eigenen System hinterlegt sind, wenn man auf Daten eines Partners zugreift ist man darauf angewiesen das dieser auch einen Indexer installiert und Zugriff darauf gibt. Warum sich das Alles antun, wenn es nicht sein muss?

    > Das durchschnittliche HTML-Dokument ist definitiv nicht größer als die
    > durchschnittliche PDF. Komprimierung passiert auf Protokoll-Ebene (PDF =
    > Zip, HTML üblicherweise Gzip oder deflate/zip). Vor allem einmal in 300
    > DPI, eingescannt, wieder als PDF abgespeichert, schon hast du nur noch
    > einen riesigen, 300MB großen Binär-Blob bestehend aus Pixel-Daten anstatt
    > sauber strukturierte Informationen. Danach ist auch mit Suchen vorbei. Sehr
    > gut!
    Es geht nicht um die absolute Größe, ein Request mit einer größeren Datei ist einfach schneller als hunderte kleine. Außerdem muss man beim erstmaligen Laden nicht zusehen und wird dann nicht mehr unterbrochen.
    Das Problem mit Scans hat nichts mit PDF zu tun, HTML mit dem ganzen Inhalt in <img> ist genauso schlimm, sieht man sogar ab und zu...

    > Für Animationen brauchst du....3 Zeilen CSS (animations) oder 1 Zeile
    > (transitions) und für Charts etc. kann man Inline-SVG verwenden, die sich
    > vollständig durch CSS animieren lassen. Da ist so erst mal nicht eine Zeile
    > JS für notwendig, aber schön, dass du auf dem neuesten Stand bleibst.
    > Bessert deine Diskussionsgrundlage sicherlich enorm.
    Genau das mache ich bei meinen Websites bereits, pure CSS Animationen, nur minimal JS. Aber danke für die Unterstellung das ich nicht auf dem neusten Stand bin. Ändert nichts daran das der Trend zu immer mehr JS geht und SSR wird auch oft nicht implementiert.

    > > Jedes ordentlich erstellte PDF enthält auch ein Inhaltsverzeichnis und
    > > interne Links sind auch möglich (aber relativ selten nötig). Hat Alles
    > > seine Daseinsberechtigung.
    >
    > Kannst du aus HTML auch generieren (H1-H6, funktioniert in PDF nicht
    > anders) und Interne Links sind in HTML durch URL-Fragmente genau so
    > möglich. Was ist das für ein Argument?
    Habe ich je behauptet das es in HTML nicht geht? Mein Kommentar bezieht sich auf den Artikel bzw. die Aussagen von Herr Nielsen, das angeblich in PDF Links nicht funktionieren und sie schlecht zu navigieren sind. Es geht eben doch, daher sehe ich für den Leser keinen wirklichen für Vorteil von HTML. Ich bin übrigens überhaupt nicht gegen HTML, z.B. wenn mehrere in einem Wiki beitragen funktioniert es besser in einer Website. Es spricht aber auch nichts dagegen eine finale Doku als PDF auszuliefern, die zusätzlichen Web Features braucht man dort nicht unbedingt.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Fraunhofer-Institut für Integrierte Schaltungen IIS, Erlangen
  2. Statistisches Bundesamt, Wiesbaden
  3. PSI Software AG Geschäftsbereich PSI Energie EE, Aschaffenburg
  4. ALDI International Services GmbH & Co. oHG, Mülheim an der Ruhr

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)
  2. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


SSD vs. HDD: Die Zeit der Festplatte im Netzwerkspeicher läuft ab
SSD vs. HDD
Die Zeit der Festplatte im Netzwerkspeicher läuft ab

SSDs in NAS-Systemen sind lautlos, energieeffizient und schneller: Golem.de untersucht, ob es eine neue Referenz für Netzwerkspeicher gibt.
Ein Praxistest von Oliver Nickel

  1. Firecuda 120 Seagate bringt 4-TByte-SSD für Spieler

Energiewende: Wie die Begrünung der Stahlindustrie scheiterte
Energiewende
Wie die Begrünung der Stahlindustrie scheiterte

Vor einem Jahrzehnt suchte die europäische Stahlindustrie nach Technologien, um ihren hohen Kohlendioxid-Ausstoß zu reduzieren, doch umgesetzt wurde fast nichts.
Eine Recherche von Hanno Böck

  1. Wetter Warum die Klimakrise so deprimierend ist

Yakuza und Dirt 5 angespielt: Xbox Series X mit Rotlicht und Rennstrecke
Yakuza und Dirt 5 angespielt
Xbox Series X mit Rotlicht und Rennstrecke

Abenteuer im Rotlichtviertel von Yakuza und Motorsport in Dirt 5: Golem.de konnte zwei Starttitel der Xbox Series X ausprobieren.
Von Peter Steinlechner

  1. Next-Gen GUI der PS5 mit höherer Auflösung als Xbox Series X/S
  2. Xbox Series X Zwei Wochen mit Next-Gen auf dem Schreibtisch
  3. Next-Gen PS5 und neue Xbox wollen Spieleklassiker aufhübschen