xdg-open vim statt LibreOffice für application/octet-stream

[Marco Moock]

Hallo zusammen,
einige Textdateien werden bei mir mit LibreOffice geöffnet, was mich
richtig nervt.

xdg-open scheint dafür verantwortlich zu sein.

Beispiel:

m@ryz:~$ xdg-open /tmp/mozilla_m0/sendmail-8.17.1/cf/README
Warning: unknown mime-type for "/tmp/mozilla_m0/sendmail-8.17.1/cf/README" -- using "application/octet-stream"

Dann startet LibreOffice, obwohl vim eingetragen ist in
~/.config/mimeapps.list.

[Added Associations]
application/octet-stream=vim.desktop;
[...]

[Default Applications]
application/octet-stream=vim.desktop

Wo könnte da die /rsache liegen?

--
Marco

[Jan Novak]

Am 27.09.22 um 07:50 schrieb Marco Moock:

Was passiert denn, wenn du in den Eigenschaften der Datei (z.B. unter
Nemo) "öffnen mit" den vim einträgst und als "default" anwendest?


Jan

[Marco Moock]

Am 27.09.2022 um 08:20:21 Uhr schrieb Jan Novak:

> Was passiert denn, wenn du in den Eigenschaften der Datei (z.B. unter
> Nemo) "öffnen mit" den vim einträgst und als "default" anwendest?

Ich habe hier nur pcmanfm, da wird dann der vim geöffnet, was er aber
auch schon vorher getan hat.
Das Problem tritt in Xarchiver auf und bei xdg-open (was der vermutlich
nutzt).

[Marco Moock]

Das Readme hat nen eigenen Typ...
Sichtbar an

Opening "/tmp/mozilla_m0/sendmail-8.17.1/cf/README" with LibreOffice
Writer (text/x-readme)


Das löst das Ganze:
xdg-mime default vim.desktop text/x-readme

[Sieghard Schicktanz]

Hallo Marco Moock,

Du schriebst am Tue, 27 Sep 2022 20:16:54 +0200:

> Das Readme hat nen eigenen Typ...
> Sichtbar an
>
> Opening "/tmp/mozilla_m0/sendmail-8.17.1/cf/README" with LibreOffice
> Writer (text/x-readme)
>
> Das löst das Ganze:
> xdg-mime default vim.desktop text/x-readme

Wer ist eigentlich auf diese Schnapsidee mit dem "xdg-open" gekommen?
Die versaut einem inzwischen alles mögliche an automatischen Aufrufen,
was früher problemlos gemäß den gemachten Einstellungen ging.
Sogar der sonst so universell konfigurierbare "mc" hat das inzwischen
eingebaut, was zur Folgee hat(te), daß etliche text- und einige andere
Dateiformate nicht mehr gingen, sondern mit irgendwelchen unerwarteten
Programmen aufgerufen wurden, vornehmlich solchen, die sich unbedingt
über's Netzwerk ("aka internet") ausbreiten zu müssen meinen. Da ging
nach einem Update auf einmal einiges nicht mehr mangels installierter
"erwarteter" Anwendung (was dann stundenlanges Rumgesuche provozierte)
oder es kam auf einmal der Firefox daher, um ein PDF anuzeigen, wozu
der aber überhaupt nicht geeignet ist (davon abgesehen, daß er endlos
zum Starten braucht).
Und nachdem das beim "mc" nichtmal anwenderspezifisch, in dessen home,
konfiguriert werden kann (wie u.a. Menu und Extension-Datei), ist man
nach jeder Aktualisierung wieder mit dieser Sauerei konfrontiert.
Wo wird dieser xdg-Kram eigentlich so dringend gebraucht, oder kann
man den einfach 'rausschmeißen?

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Tim Ritberg]

Am 28.09.22 um 20:31 schrieb Sieghard Schicktanz:
> Hallo Marco Moock,

> Wo wird dieser xdg-Kram eigentlich so dringend gebraucht, oder kann
> man den einfach 'rausschmeißen?

Sieht nicht so aus, der ist wohl "Standard":
https://wiki.ubuntuusers.de/xdg-utils/

Google Chrome läuft zB nicht ohne (unter Ubuntu).

Tim

[Marco Moock]

Am 28.09.2022 um 20:31:24 Uhr schrieb Sieghard Schicktanz:

> Wo wird dieser xdg-Kram eigentlich so dringend gebraucht, oder kann
> man den einfach 'rausschmeißen?

Bei mir würde es Claws Mail rauswerfen.

[Sieghard Schicktanz]

Hallo Tim Ritberg,

Du schriebst am Wed, 28 Sep 2022 22:39:02 +0200:

> > Wo wird dieser xdg-Kram eigentlich so dringend gebraucht, oder kann
> > man den einfach 'rausschmeißen?
> Sieht nicht so aus, der ist wohl "Standard":
> https://wiki.ubuntuusers.de/xdg-utils/

Schlechter Standard.

> Google Chrome läuft zB nicht ohne (unter Ubuntu).

Wer braucht "Google Chrome"?

[Sieghard Schicktanz]

Hallo Marco Moock,

Du schriebst am Thu, 29 Sep 2022 08:26:03 +0200:

> > Wo wird dieser xdg-Kram eigentlich so dringend gebraucht, oder kann
> > man den einfach 'rausschmeißen?
>
> Bei mir würde es Claws Mail rauswerfen.

Hatte ich mal am Laufen, bis es mir irgendwelche krummen Sachen gemacht
hat. Ich hab' jetzt wieder seinen "Stammvater" Sylpheed am Laufen, auch
wenn der auch ein paar unangenehme Eigenheiten hat.

Aber inzwischen habe ich dem "mc" den xdg-Mist abgewöhnt, und
anderweitig hat sich der bisher noch nicht lästig gezeigt. Muß ich halt
nach jeder Aktualisierung wieder neu umbauen, wozu gibt's Editoren und
Vergleichsprogramme.

Lästiger zeigt sich allmäählich der "dbus" oder "ibus" oder wie das Ding
richtig heißt. Von unsinnigen Meldungen bis zu kompletter
Ausführungsverweigerung bringt das Ding alle Lästigkeiten zustande.

[Tim Ritberg]

Am 29.09.22 um 20:49 schrieb Sieghard Schicktanz:

>> Google Chrome läuft zB nicht ohne (unter Ubuntu).
>
> Wer braucht "Google Chrome"?

Wer brauchst Libreoffice?

Tim

[Sieghard Schicktanz]

Hallo Tim Ritberg,

Du schriebst am Thu, 29 Sep 2022 22:43:01 +0200:

> > Wer braucht "Google Chrome"?
> Wer brauchst Libreoffice?

Z.B. die Schreiber von Dokumentation (Debian-Dokumentation?) in
lesbarer Form (d.h. PDF-Format)?

[Peter J. Holzer]

On 2022-09-30 18:30, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
> Du schriebst am Thu, 29 Sep 2022 22:43:01 +0200:

>> Wer brauchst Libreoffice?
>
> Z.B. die Schreiber von Dokumentation (Debian-Dokumentation?) in
> lesbarer Form (d.h. PDF-Format)?

Kann man auch mit LaTeX schreiben. Oder mit DocBook. Oder heutzutage
wahrscheinlich eher mit Markdown und Pandoc oder ähnlichem.

hp (der sich gerade fragt, wo der Thread abgebogen ist)

[Laurenz Trossel]

On 2022-09-30, Peter J. Holzer <hjp-u...@hjp.at> wrote:

> Kann man auch mit LaTeX schreiben. Oder mit DocBook. Oder heutzutage
> wahrscheinlich eher mit Markdown und Pandoc oder ähnlichem.

Nachdem HTML deutlich verschlankt wurde (Verzicht auf unnötige schliessende
Tags oder head und body), schreibt sich das auch gut flüssig und
übersichtlich und ist weitgehend portabel auf allen Geräten.

> hp (der sich gerade fragt, wo der Thread abgebogen ist)

"Wer braucht schon X" ist eine Frage, mit der man ausgerechnet im Usenet
vorsichtig sein sollte.

[Peter J. Holzer]

On 2022-09-30 21:30, Laurenz Trossel <m...@example.invalid> wrote:
> On 2022-09-30, Peter J. Holzer <hjp-u...@hjp.at> wrote:
>> Kann man auch mit LaTeX schreiben. Oder mit DocBook. Oder heutzutage
>> wahrscheinlich eher mit Markdown und Pandoc oder ähnlichem.
>
> Nachdem HTML deutlich verschlankt wurde (Verzicht auf unnötige schliessende
> Tags oder head und body),

Das war in HTML immer schon so (jedenfalls seit HTML 2.0, das war glaube
ich die erste Version mit einer formalen Grammatik).

> schreibt sich das auch gut flüssig und übersichtlich und ist
> weitgehend portabel auf allen Geräten.

Ja, aber Sieghard hat explizit das Erzeugen von PDFs[1] angesprochen.

Und da kenne ich keine Toolchain, die befriedigende Ergebnisse liefern
würde. Ist zwar schon wieder ein paar Jährchen her, dass ich mir das
angeschaut habe, aber insbesondere auf Grund der recht raschen
Weiterentwicklung von CSS in den letzten Jahren bezweifle ich, dass die
Situation besser geworden ist.

hp

[1] Seine Gleichsetzung von PDFs und lesbar finde ich zwar etwas seltsam.
Was macht der Mensch im Usenet, wenn er text/plain unlesbar findet?

[Thomas Hochstein]

Laurenz Trossel schrieb:

> On 2022-09-30, Peter J. Holzer <hjp-u...@hjp.at> wrote:
>
>> Kann man auch mit LaTeX schreiben. Oder mit DocBook. Oder heutzutage
>> wahrscheinlich eher mit Markdown und Pandoc oder ähnlichem.
>
> Nachdem HTML deutlich verschlankt wurde (Verzicht auf unnötige schliessende
> Tags oder head und body), schreibt sich das auch gut flüssig und
> übersichtlich und ist weitgehend portabel auf allen Geräten.

Die nötigen schließenden Tags machen HTML sehr viel aufwendiger beim
Schreiben und Lesenm als - bspw. - Markdown, mit in der Regel sehr, sehr
überschaubarem Gewinn.

[Peter J. Holzer]

Markdown hat allerdings (wie die ganze Klasse der "Wiki-Syntaxen") den
Nachteil, dass es nur sehr beschränkt für komplexe Strukturen geeignet
ist bzw. für alles eine ad-hoc-Syntax benötigt. Das ist fein, wenn man
eh nur das übliche braucht (also in >> 90% aller Fälle), aber in den
paar Fällen, wo man etwas komplexeres braucht, steht man dann an.

HTML ist etwas unnötig verbose, was die End-Tags betrifft. SGML würde es
z,B. erlauben, den Namen im End-Tag wegzulassen und bei
unverschachtelten Elementen gibt es sogar eine Kurz-Syntax:

<aside>
<p>Das ist der <em/erste/ Absatz.
<p>Und hier ist der zweite.
<table>
<tr><th>Spalte 1<th>Spalte 2
<tr><td>Wert 1<td>Wert 2
<tr><td>Wert 3<td>Wert 4
</>
</>

Aber das hat meines Wissens nie einer der verbreiteten Browser
implementiert und in HTML 5 ist es ganz weggefallen.

Ich hatte mal eine weniger verbose Syntax entworfen
(https://www.hjp.at/projekte/faxe/). Das hatte ich sogar implementiert,
aber die Vorteile gegenüber HTML haben sich dann doch in Grenzen
gehalten - tatsächlich verwendet habe ich es kaum.

hp

[Sieghard Schicktanz]

Hallo Peter J. Holzer,

Du schriebst am Sat, 1 Oct 2022 11:32:18 +0200:

> [1] Seine Gleichsetzung von PDFs und lesbar finde ich zwar etwas
> seltsam. Was macht der Mensch im Usenet, wenn er text/plain unlesbar
> findet?

Findet er auch nicht, diese Deine "Schlußfolgerung" ist genauso
voreilig wie falsch. Was er findet, ist, daß HTML "nicht" lesbar ist.
Es ist zwar möglich, so gesetzte Texte zu lesen, aber deren Darstellung
ist undefiniert, und, was schlimmer ist, sie sind im allgemeinen so
erstellt, daß man sie ausschließlich on-line wirklich lesen kann.
D.h. um Lesen eines solchen Textes muß man seine Maschine der
"Öffentlichkeit" (bzw. schlimmer, dem internet-Zugang) preisgeben.

[Peter J. Holzer]

On 2022-10-01 18:02, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
> Hallo Peter J. Holzer,
> Du schriebst am Sat, 1 Oct 2022 11:32:18 +0200:
>
>> [1] Seine Gleichsetzung von PDFs und lesbar finde ich zwar etwas
>> seltsam. Was macht der Mensch im Usenet, wenn er text/plain unlesbar
>> findet?
>
> Findet er auch nicht, diese Deine "Schlußfolgerung" ist genauso
> voreilig wie falsch.

Die war auch nicht ernst gemeint.

> Was er findet, ist, daß HTML "nicht" lesbar ist. Es ist zwar möglich,
> so gesetzte Texte zu lesen, aber deren Darstellung ist undefiniert,

Das stimmt zwar für reines HTML, aber nicht für die Kombination von HTML
und CSS, bei der man sehr genau festlegen kann, wie der Output aussehen
soll. Sinnvollerweise tut man das allerdings nicht exakt, sondern lässt
dem Rendering Device gewisse Freiheiten, damit der Text z.B. an die
Größe des Bildschirms angepasst werden kann.

Das ist m.E. genau die Schwäche von PDF: Das gibt eine gewisse
Output-Größe vor, und wenn das Device nicht groß genug ist, eine ganze
Seite auf einmal darstellen zu können, wird das Lesen mühsam bis
unmöglich.

> und, was schlimmer ist, sie sind im allgemeinen so erstellt, daß man
> sie ausschließlich on-line wirklich lesen kann.

Das "H" in "HTML" steht für Hypertext, ja. Es ist daher nicht
verwunderlich, dass HTML häufig für Hypertexts (also mehrere
untereinander verlinkte Dokumente) verwendet wird. Aber nichts in HTML
erzwingt das: Du kannst ein HTML-File schreiben, das vollkommen
stand-alone ist. Tatsächlich sind ePubs nichts anderes als Zip-Files,
die ein HTML-File und optional weitere Resourcen (CSS, Bilder, Fonts)
enthalten. Und wenn Du alle verlinkten Dokumente lokal vorliegen hast
(und die Links relativ sind), dann kannst Du auch Hypertexts lokal
lesen, ganz ohne Internet.

(Die Unart, dass manche Webserver ein leeres HTML-File ausliefern, das
dann erst mittels JavaScript befüllt wird, möchte ich hier ausklammern,
weil das wirklich nichts mit HTML als Format zu tun hat.)

hp

[Peter J. Holzer]

On 2022-10-01 18:02, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:

> Hallo Peter J. Holzer,
> Du schriebst am Sat, 1 Oct 2022 11:32:18 +0200:
>> [1] Seine Gleichsetzung von PDFs und lesbar finde ich zwar etwas
>> seltsam.
>

> Was er findet, ist, daß HTML "nicht" lesbar ist.

Einen Aspekt habe ich noch vergessen: HTML und PDF sind nicht wirklich
vergleichbar, weil sie unterschiedliche Rollen haben: PDF ist ein reines
Output-Format. Niemand schreibt PDF, Das wird immer aus anderen Formaten
erzeugt (MS Word, LibreOffice, LaTeX, Markdown, ...) oder aus anderen
Daten generiert.

HTML hingegen ist (auch) ein Quell-Format. Das kann man entweder mit
einem einfachen Text-Editor oder mit einem spezialisierten HTML-Editor
erstellen, editieren, etc. (Man kann es natürlich auch generieren und
das wird auch oft gemacht. Aber das gilt auch z.B. für Word-Files)

hp

[Stefan Froehlich]

On Sat, 01 Oct 2022 11:32:18 Peter J. Holzer wrote:
> On 2022-09-30 21:30, Laurenz Trossel <m...@example.invalid> wrote:

>> schreibt sich [HTML] auch gut flüssig und übersichtlich und ist

>> weitgehend portabel auf allen Geräten.

Ich finde HTML großartig, um maschinengestützt attraktive
Ausgabeformate zu generieren. Für eigene Texte käme ich nicht auf
die Idee, HTML zu verwenden, egal ob mit oder ohne schließenden
Tags. Das ist, wenigstens für mich, ungleich mühsamer als z.B. TeX,
bietet aber gleichzeitig, und ganz sicher nicht nur für mich,
ungleich weniger Funktionalität.

> Ja, aber Sieghard hat explizit das Erzeugen von PDFs[1] angesprochen.

> Und da kenne ich keine Toolchain, die befriedigende Ergebnisse
> liefern würde. Ist zwar schon wieder ein paar Jährchen her, dass
> ich mir das angeschaut habe, aber insbesondere auf Grund der recht
> raschen Weiterentwicklung von CSS in den letzten Jahren bezweifle
> ich, dass die Situation besser geworden ist.

Die Frage ist immer, was man als "befriedigend" empfindet. Ich
erzeuge maschinengenerierte PDFs einerseits aus TeX (pdflatex, eh
klar) andererseits aus HTML (dompdf), beides mit für den jeweiligen
Zweck IMO sehr brauchbaren Ergebnissen.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - die zarteste Entscheidung der Nacht!
(Sloganizer)

[Peter J. Holzer]

On 2022-10-02 09:00, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> On Sat, 01 Oct 2022 11:32:18 Peter J. Holzer wrote:
>> On 2022-09-30 21:30, Laurenz Trossel <m...@example.invalid> wrote:
>>> schreibt sich [HTML] auch gut flüssig und übersichtlich und ist
>>> weitgehend portabel auf allen Geräten.
>
> Ich finde HTML großartig, um maschinengestützt attraktive
> Ausgabeformate zu generieren. Für eigene Texte käme ich nicht auf
> die Idee, HTML zu verwenden, egal ob mit oder ohne schließenden
> Tags. Das ist, wenigstens für mich, ungleich mühsamer als z.B. TeX,
> bietet aber gleichzeitig, und ganz sicher nicht nur für mich,
> ungleich weniger Funktionalität.

Ich habe (La)TeX früher sehr viel verwendet, über die letzten 20 Jahre
allerdings zunehmend weniger. Der Grund ist einfach, dass LaTeX dafür
optimiert ist, Papers und Bücher zu schreiben. Wenn man das will und mit
dem Default-Layout (oder einem der Packages, die jemand geschrieben
hat), zufrieden ist, ist es ganz toll. Aber das ist nicht, was ich
brauche: Fast alles, was ich schreibe, ist "web first" - Ausdruck auf
Papier ist meistens bestenfalls "nice to have". Und die
Styling-Möglichkeiten in HTML/CSS sind um vieles komfortabler als in
LaTeX. Ja, plain TeX ist turing-vollständig, aber es ist auch sehr
schmerzhaft. Und das meiste habe ich auch schon wieder vergessen.

>> Ja, aber Sieghard hat explizit das Erzeugen von PDFs[1] angesprochen.
>
>> Und da kenne ich keine Toolchain, die befriedigende Ergebnisse
>> liefern würde. Ist zwar schon wieder ein paar Jährchen her, dass
>> ich mir das angeschaut habe, aber insbesondere auf Grund der recht
>> raschen Weiterentwicklung von CSS in den letzten Jahren bezweifle
>> ich, dass die Situation besser geworden ist.
>
> Die Frage ist immer, was man als "befriedigend" empfindet.

Die wichtigsten Kriterien wären für mich:

* HTML und CSS weitgehend implementiert (wenn ein paar obskure
CSS-Properties fehlen, ist das kein Problem, aber wenn ich 50% von
meinen Kenntnissen nicht anwenden kann, ist es eines - das ist dann
eine andere Sprache)
* Angepasst an das Ausgabemedium (Papier hat keine Scroll-Balken)
* Keine offensichtlichen Renderfehler in Standard-Situationen (ein
Programm hat beim Seitenumbruch Zeilen horizontal geteilt - sowas darf
einfach nicht passieren.)
* PDF sollte durchsuch- und kopierbaren Text enthalten.

Nicht ganz essentiell, aber für längere Texte auch wichtig, wäre eine
Möglichkeit, Kopf- und Fußzeilen, Inhaltsverzeichnis, Index, etc. zu
generieren. Dafür bräuchte man vermutlich Erweiterungen von HTML
und/oder CSS.

> Ich erzeuge maschinengenerierte PDFs einerseits aus TeX (pdflatex, eh
> klar) andererseits aus HTML (dompdf), beides mit für den jeweiligen
> Zweck IMO sehr brauchbaren Ergebnissen.

Dompdf sagt mir jetzt nichts. Wenn es damals bei den Programmen dabei
war, die ich getestet habe, hat es jedenfalls keinen bleibenden Eindruck
hinterlassen. Danke für den Tipp, ich werde es mir ansehen.

hp

[Peter J. Holzer]

Aha. Das ist eine PHP-Library, kein (Commandline-)Tool. Da müsste ich
zumindest noch ein Wrapper-Script schreiben, um das verwenden zu können.

hp

[Stefan Froehlich]

On Sun, 02 Oct 2022 12:21:22 Peter J. Holzer wrote:
> On 2022-10-02 09:00, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
>> Für eigene Texte käme ich nicht auf die Idee, HTML zu verwenden,
>> egal ob mit oder ohne schließenden Tags. Das ist, wenigstens für
>> mich, ungleich mühsamer als z.B. TeX, bietet aber gleichzeitig,
>> und ganz sicher nicht nur für mich, ungleich weniger
>> Funktionalität.

> Ich habe (La)TeX früher sehr viel verwendet, über die letzten 20
> Jahre allerdings zunehmend weniger. Der Grund ist einfach, dass
> LaTeX dafür optimiert ist, Papers und Bücher zu schreiben.

Wenn ich händisch etwas schreibe (und da kam die Diskussion ja her),
dann hat das meist auch genau diesen Charakter. Dinge, die in erster
Linie für den Bildschirm gedacht sind, werden allesamt maschinell
erzeugt; da spielt der Overhead von HTML dann keine Rolle.

> Wenn man das will und mit dem Default-Layout (oder einem der
> Packages, die jemand geschrieben hat), zufrieden ist, ist es ganz
> toll.

Wie gesagt: Manuell passiert genau das, maschinell verwende ich
LaTeX eigentlich nur noch für meine Rechnungen, weil das Template
dafür halt schon seit 2 Jahrzehnten existiert und es wenig
Motivation gibt, daran etwas zu ändern.

>>> Ja, aber Sieghard hat explizit das Erzeugen von PDFs[1]
>>> angesprochen.

>>> Und da kenne ich keine Toolchain, die befriedigende Ergebnisse
>>> liefern würde. Ist zwar schon wieder ein paar Jährchen her, dass
>>> ich mir das angeschaut habe, aber insbesondere auf Grund der
>>> recht raschen Weiterentwicklung von CSS in den letzten Jahren
>>> bezweifle ich, dass die Situation besser geworden ist.

>> Die Frage ist immer, was man als "befriedigend" empfindet.

> Die wichtigsten Kriterien wären für mich:

> * HTML und CSS weitgehend implementiert (wenn ein paar obskure
> CSS-Properties fehlen, ist das kein Problem, aber wenn ich 50% von
> meinen Kenntnissen nicht anwenden kann, ist es eines - das ist
> dann eine andere Sprache)

Hängt immer davon ab, was man als obskur definiert, aber CSS2.1 ist
so gut wie komplett abgedeckt. Da ich einen Hang zu basisnaher
Auszeichung habe (alles andere merke ich mir schlicht nicht), ist
das für mich locker ausreichend.

> * Angepasst an das Ausgabemedium (Papier hat keine Scroll-Balken)

Sollte gehen.

> * Keine offensichtlichen Renderfehler in Standard-Situationen (ein
> Programm hat beim Seitenumbruch Zeilen horizontal geteilt - sowas
> darf einfach nicht passieren.)

Ist mir zumindestens noch nicht passiert. A

> * PDF sollte durchsuch- und kopierbaren Text enthalten.

Hm. Habe ich noch nie darauf geachtet, sieht mir allerdings nicht
danach aus. Ich weiss aber nicht, ob das z.B. von der verwendeten
Schriftart abhängt.

> Nicht ganz essentiell, aber für längere Texte auch wichtig, wäre
> eine Möglichkeit, Kopf- und Fußzeilen, Inhaltsverzeichnis, Index,
> etc. zu generieren. Dafür bräuchte man vermutlich Erweiterungen
> von HTML und/oder CSS.

Definitiv ja. Das geht alles nicht und ist z.B. einer der Vorteile
von LaTeX.

>> Ich erzeuge maschinengenerierte PDFs einerseits aus TeX
>> (pdflatex, eh klar) andererseits aus HTML (dompdf), beides mit
>> für den jeweiligen Zweck IMO sehr brauchbaren Ergebnissen.
>
> Dompdf sagt mir jetzt nichts. Wenn es damals bei den Programmen
> dabei war, die ich getestet habe, hat es jedenfalls keinen
> bleibenden Eindruck hinterlassen. Danke für den Tipp, ich werde es
> mir ansehen.

Wie Du im Folgeposting angemerkt hast, es ist PHP-Software. Für
einen Aufruf von der cli sollte aber 6 Zeilen Code ausreichen, siehe
Readme.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Mächtig bleibt mächtig: Stefan!
(Sloganizer)

[Sieghard Schicktanz]

Hallo Peter J. Holzer,

Du schriebst am Sat, 1 Oct 2022 23:12:36 +0200:

> > Was er findet, ist, daß HTML "nicht" lesbar ist. Es ist zwar
> > möglich, so gesetzte Texte zu lesen, aber deren Darstellung ist
> > undefiniert,
>
> Das stimmt zwar für reines HTML, aber nicht für die Kombination von
> HTML und CSS, bei der man sehr genau festlegen kann, wie der Output
> aussehen soll. Sinnvollerweise tut man das allerdings nicht exakt,

Ja, schön. Das wäre kein Problem, wenn man die CSS-Files einfach
kriegen könnte, die scheinen zumindest aber oft als proprietätrs Gut
angesehen und daher extern und nicht (ohne weiteres) abrufbar zu sein.
Dann ist das, evtl. sogar mit angepassten Links, heruntergeladene File
halt nur eine "Textwüste" oder noch schlimmer, eine Textlawine.
(Nicht daß PDF da nichts entsprechendes zu bieten hätte - aus schön
formatierten Tabellen herauskopierter und in ein ASCII-File eingebauter
Text kann oft recht "unerwartet" aussehen...)

> sondern lässt dem Rendering Device gewisse Freiheiten, damit der Text
> z.B. an die Größe des Bildschirms angepasst werden kann.

Was zwar der originalen Intention entspricht, aber "manchmal" von den
Erstellern mancher Web-Seiten etwas zu heftig unterbunden wird.

> Das ist m.E. genau die Schwäche von PDF: Das gibt eine gewisse
> Output-Größe vor, und wenn das Device nicht groß genug ist, eine ganze
> Seite auf einmal darstellen zu können, wird das Lesen mühsam bis
> unmöglich.

Das ist aber genau die Intention bei PDF: Das Ergebnis soll unabhängig
vom darstellenden Medium immer genau gleich aussehen. Das intendierte
"darstellende Medium" dafür ist in sicher >99% der Fälle halt ein
Stapel Papierblätter, vorzugsweise beidseitig bedruckt, auch bekannt
als "Buch" oder "Heft".

> > und, was schlimmer ist, sie sind im allgemeinen so erstellt, daß man
> > sie ausschließlich on-line wirklich lesen kann.
>
> Das "H" in "HTML" steht für Hypertext, ja. Es ist daher nicht

Aber nicht dafür, daß alles mögliche von anderen Stellen _benötigt_
wird, um die Seite überhaupt darzuzstellen. Die originale Intention war
AFAIR die Möglichkeit, Referenzen auf _weiterführende_ Informationen
einbinden zu können, die _bei Bedarf_ darüber erreicht werden können.
Nicht dafür, gleich mal die Schriften zu laden, jedes Kapitel von wo
anders abzukupfern und evtle. Bilder möglichst noch kopiergeschützt von
wieder anderswoher.

> verwunderlich, dass HTML häufig für Hypertexts (also mehrere
> untereinander verlinkte Dokumente) verwendet wird. Aber nichts in HTML

Nein, das ist richtig, angesichts der Verhaltensweisen der Hauptnutzer,
kommerzieller Einrichtungen, Werbeunternehmen u.ä., ist es nicht
verwunderlich, wie HTML inzwischen benutzt wird. Nur sind damit die
Ergebnisse halt kaum noch benutzbar.

...

> enthalten. Und wenn Du alle verlinkten Dokumente lokal vorliegen hast
> (und die Links relativ sind), dann kannst Du auch Hypertexts lokal
> lesen, ganz ohne Internet.

Und damit die Links relativ sein können, muß ggfs. schon einiges an
"Detektivarbeit" hineingesteckt werden - der Firefox oder wget bieten
sowas ja an, aber es gibt "nicht wenige" Fälle, wo das nicht klappt.
Und ein weiteres kleines Problemchen kommt ggfs. mit Rückwärts- und
rekursiven Links dazu - damit haben diese Programme dann oft verloren.

> (Die Unart, dass manche Webserver ein leeres HTML-File ausliefern, das
> dann erst mittels JavaScript befüllt wird, möchte ich hier
> ausklammern, weil das wirklich nichts mit HTML als Format zu tun hat.)

Ja, das gehört auch eher in die Kategorie "Mißbrauch".


Du schriebst am Sun, 2 Oct 2022 00:29:50 +0200:

> Einen Aspekt habe ich noch vergessen: HTML und PDF sind nicht wirklich
> vergleichbar, weil sie unterschiedliche Rollen haben: PDF ist ein

Durchaus. Der Anlaß zum Vergleich kommt aber daher, daß sie öfters für
_äquivalente_ Zwecke benutzt werden. Gerätebeschreibungen z.B., oder
Programmdokumentation.

> reines Output-Format. Niemand schreibt PDF, Das wird immer aus
> anderen Formaten erzeugt (MS Word, LibreOffice, LaTeX, Markdown, ...)
> oder aus anderen Daten generiert.

Das stimmt zwar, ist aber weitgehend irrelevant, weil inzwischen die
Erstellung recht einfach geworden ist. Sogar MS Word kann das
inzwischen.

> HTML hingegen ist (auch) ein Quell-Format. Das kann man entweder mit

Inzwischen nicht mehr so sehr - _gerade_ die CSS-Formatierung verbirgt
soviel, daß der potentielle Schreiber zu viel auswendig lernen muß, was
er nur für seine direkte Umebung brauchen kann. Andere Umgebung
bedeutet komplett umzulernen. Und einfacher ist HTML mit den neuen
Versionen auch nicht gerade geworden.
Ja, und ein wichtiger Punkt ist auch noch:
Bei PDF hast Du für ein bestimmtes Thema _eine_ Datei, in der alles
enthalten ist.
Bei HTML hast Du, auch wenn selber erzeugt, einen ganzen Schwarm von
Dateien, sofern das Endergebnis nicht nur ein banaler Fließtext ist.
Schon ein einziges Bild, ein Style-Sheet oder eine (mitzuliefernde)
Schriftart sorgen für eine Aufsplitterung. Der Firefox konnte mal
zumindest eine Web-Seite als Einzeldatei abspeichern. Ich weiß grade
nicht, ob das noch geht, das habe ich schon länger nicht benutzt, weil
es oft dann doch nicht funktionierte. Wahrscheinlich war das dann eine
Sequenz irgendwie codierter Bilddateien, so sah das beim Versuch, das
direkt anzuschauen, AFAIR jedenfalls aus.

> einem einfachen Text-Editor oder mit einem spezialisierten HTML-Editor
> erstellen, editieren, etc. (Man kann es natürlich auch generieren und
> das wird auch oft gemacht. Aber das gilt auch z.B. für Word-Files)

Aus denen sich auch (meist schlechtes) HTML, aber auch PDF erzeugen
läßt. (Mit Libre/Open Office auch)

[Thomas Hochstein]

Peter J. Holzer schrieb:

> Markdown hat allerdings (wie die ganze Klasse der "Wiki-Syntaxen") den
> Nachteil, dass es nur sehr beschränkt für komplexe Strukturen geeignet
> ist bzw. für alles eine ad-hoc-Syntax benötigt. Das ist fein, wenn man
> eh nur das übliche braucht (also in >> 90% aller Fälle), aber in den
> paar Fällen, wo man etwas komplexeres braucht, steht man dann an.

Das ist richtig, aber man kann - geeignetes Parsing-Tool vorausgesetzt,
natürlich - Markdown mit HTML mischen. (Oft genügt schon ein erweiterter
Markdown-Doalekt) Dann kann man für 90% der Fälle einfachen und gut
lesbaren Quelltext schreiben und komplexeres Markup in HTML machen. Für
Inhalte benötigt man das allerdings fast nie. Für die Grundstruktur, d.h.
Templates, kann man natürlich HTML verwenden, wobei ich HAML vorziehe.

> Ich hatte mal eine weniger verbose Syntax entworfen
> (https://www.hjp.at/projekte/faxe/). Das hatte ich sogar implementiert,
> aber die Vorteile gegenüber HTML haben sich dann doch in Grenzen
> gehalten - tatsächlich verwendet habe ich es kaum.

Ich schätze es sehr, kein HTML schreiben zu müssen.

-thh
--
Do not go gentle into that good night.
Rage, rage against the dying of the light.

[Peter J. Holzer]

On 2022-10-02 18:46, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
> Hallo Peter J. Holzer,
> Du schriebst am Sat, 1 Oct 2022 23:12:36 +0200:
>
>> > Was er findet, ist, daß HTML "nicht" lesbar ist. Es ist zwar
>> > möglich, so gesetzte Texte zu lesen, aber deren Darstellung ist
>> > undefiniert,
>>
>> Das stimmt zwar für reines HTML, aber nicht für die Kombination von
>> HTML und CSS, bei der man sehr genau festlegen kann, wie der Output
>> aussehen soll. Sinnvollerweise tut man das allerdings nicht exakt,
>
> Ja, schön. Das wäre kein Problem, wenn man die CSS-Files einfach
> kriegen könnte, die scheinen zumindest aber oft als proprietätrs Gut
> angesehen und daher extern und nicht (ohne weiteres) abrufbar zu sein.

Zumindest Firefox hat seit Ewigkeiten die Funktion "Save Page As .. Web
page complete", die alle eingebundenen Resourcen (also auch CSS-Files)
in einem Subdirectory ablegt und die Links entsprechend anpasst, dass
man das File danach lokal öffnen kann. Das funktioniert nicht immer,
hauptsächlich weil der Browser natürlich JavaScript nicht umschreiben
kann, aber für CSS und Images ist das ziemlich problemlos. Verwende ich
oft, wenn ich eine Website analysieren will.

Und abrufen kann man die CSS-Files natürlich immer - tut der Browser ja
auch.

Dass die "extern" (ich nehme an, Du meinst über <link rel="stylesheet">
eingebunden und nicht als <style>...</style> Element) sind, hat nichts
mit "proprietär" zu tun, sondern ist einfach eine Anwendung des DRY
(Don't Repeat Yourself) Prinzips. Einerseits macht das Änderungen
einfacher (man muss nur an einer Stelle was ändern und nicht an
siebentausendfünfhundertsechsunddreißig), andererseit spart es
Bandbreite, sobald der User mehr als eine Seite anschaut.

>> sondern lässt dem Rendering Device gewisse Freiheiten, damit der Text
>> z.B. an die Größe des Bildschirms angepasst werden kann.
>
> Was zwar der originalen Intention entspricht, aber "manchmal" von den
> Erstellern mancher Web-Seiten etwas zu heftig unterbunden wird.

Ja. Ich habe noch mit Grausen die "Optimized for 800x600"-Seiten im
Kopf. Ist besser geworden (hauptsächlich durch die Verbreitung von
Handys), aber manche sogenannten Web-Developer (oder ihre Auftraggeber)
können sich offensichtlich vom Ideal des "pixelgenauen" fixen Layouts
nicht lösen. Die wollen eigentlich Hochglanzbroschüren auf Papier.

>> Das ist m.E. genau die Schwäche von PDF: Das gibt eine gewisse
>> Output-Größe vor, und wenn das Device nicht groß genug ist, eine ganze
>> Seite auf einmal darstellen zu können, wird das Lesen mühsam bis
>> unmöglich.
>
> Das ist aber genau die Intention bei PDF: Das Ergebnis soll unabhängig
> vom darstellenden Medium immer genau gleich aussehen. Das intendierte
> "darstellende Medium" dafür ist in sicher >99% der Fälle halt ein
> Stapel Papierblätter, vorzugsweise beidseitig bedruckt, auch bekannt
> als "Buch" oder "Heft".

Eben, und das ist halt oft nicht die Art, wie ich das dann lesen will.
Die Intention des Erstellers geht an den Bedürfnissen des Users vorbei.
Daher halte ich PDF sehr oft (nicht immer) für ungeeignet.

HTML hingegen wäre prinzipiell auch für Papier geeignet, aber da gibt es
halt keine Toolchain in die jemand auch nur annähernd soviel Arbeit
gesteckt hätte wie in die Browser (die das Ausdrucken eher
stiefmütterlich behandeln). [dompdf habe ich immer noch nicht
ausprobiert. Aber das README stimmt mich nicht besonders optimistisch.]

>> > und, was schlimmer ist, sie sind im allgemeinen so erstellt, daß man
>> > sie ausschließlich on-line wirklich lesen kann.
>>
>> Das "H" in "HTML" steht für Hypertext, ja. Es ist daher nicht
>
> Aber nicht dafür, daß alles mögliche von anderen Stellen _benötigt_
> wird, um die Seite überhaupt darzuzstellen. Die originale Intention war
> AFAIR die Möglichkeit, Referenzen auf _weiterführende_ Informationen
> einbinden zu können, die _bei Bedarf_ darüber erreicht werden können.
> Nicht dafür, gleich mal die Schriften zu laden, jedes Kapitel von wo
> anders abzukupfern und evtle. Bilder möglichst noch kopiergeschützt von
> wieder anderswoher.

Was die Kapitel betrifft: Das ist IMHO einfach praktischer. Wenn ich die
Wahl zwischen "HTML, single file" und "HTML, one file per chapter" habe
(die Wahl hat man bei Online-Doku oft, vor allem, wenn das HTML aus
einem anderen Format generiert wurde), wähle ich praktisch immer
letzteres (und wenn es als dritte Möglichkeit "PDF" gibt, das nur, wenn
ich es ausdrucken will, oder wenn das autogenerierte HTML schwere Fehler
enthält). Da findet man sich einfach leichter zurecht. Und das
funktioniert natürlich auch lokal.

Das Einbinden von Resourcen (CSS, Bilder, Schriftarten, ...) aus anderen
Files war zwar nicht in HTML 1.0 vorgesehen (tatsächlich gab es damals
noch nicht mal Bilder, die hat erst Mosaic eingeführt), machte aber das
Erstellen von HTML-Files um vieles einfacher, als man das noch
größtenteils von Hand machte. Mittlerweile ist das technisch nicht mehr
so notwendig, aber immer noch angenehm. Und in der Benutzung sehe ich da
kein Problem. Wenn ich HTML-Files herunterlade, lädt der Browser diese
Resourcen mit, und wenn ich HTML-Doku oder sonstige HTML-Reports (z.B.
den Output eines Coverage-Tools oder Profilers) lokal lese, dann stimmen
die Links ohnehin.

>> verwunderlich, dass HTML häufig für Hypertexts (also mehrere
>> untereinander verlinkte Dokumente) verwendet wird. Aber nichts in HTML
>
> Nein, das ist richtig, angesichts der Verhaltensweisen der Hauptnutzer,
> kommerzieller Einrichtungen, Werbeunternehmen u.ä., ist es nicht
> verwunderlich, wie HTML inzwischen benutzt wird. Nur sind damit die
> Ergebnisse halt kaum noch benutzbar.

We will have to agree to disagree here.

Ich halte HTML für sehr nutzbar.

> Du schriebst am Sun, 2 Oct 2022 00:29:50 +0200:
>
>> Einen Aspekt habe ich noch vergessen: HTML und PDF sind nicht wirklich
>> vergleichbar, weil sie unterschiedliche Rollen haben: PDF ist ein
>
> Durchaus. Der Anlaß zum Vergleich kommt aber daher, daß sie öfters für
> _äquivalente_ Zwecke benutzt werden. Gerätebeschreibungen z.B., oder
> Programmdokumentation.

Wenn ich die Gerätebeschreibung oder Programmdokumentation auf meinem
Handy lesen möchte, will ich die ganz sicher nicht als PDF (außer das
PDF ist für DIN-A6 formatiert, aber dann möchte ich es nicht
ausdrucken).

>> reines Output-Format. Niemand schreibt PDF, Das wird immer aus
>> anderen Formaten erzeugt (MS Word, LibreOffice, LaTeX, Markdown, ...)
>> oder aus anderen Daten generiert.
>
> Das stimmt zwar, ist aber weitgehend irrelevant, weil inzwischen die
> Erstellung recht einfach geworden ist. Sogar MS Word kann das
> inzwischen.
>
>> HTML hingegen ist (auch) ein Quell-Format. Das kann man entweder mit
>
> Inzwischen nicht mehr so sehr - _gerade_ die CSS-Formatierung verbirgt
> soviel, daß der potentielle Schreiber zu viel auswendig lernen muß, was
> er nur für seine direkte Umebung brauchen kann.

Ganz im Gegenteil. Mit CSS kann man Inhalt und Formatierung sauber
trennen. (Dass es CSS-Frameworks gibt, die das Gegenteil machen, steht
auf einem anderen Blatt)

> Und einfacher ist HTML mit den neuen Versionen auch nicht gerade
> geworden.

Das stimmt natürlich. 30 Jahre Entwicklung (mit ein paar Umwegen) führen
nicht unbedingt zu einer einfachen Spezifikation. Aber ich habe die 30
Jahre halt mitgemacht. Word ist auch nicht einfach. Da stoße ich sehr
schnell an meine Grenzen, und schreibe dann einfach HTML und ein
bisschen CSS, da komme ich schneller und mit viel weniger Fluchen zum
Ziel (oder wenn's unbedingt Word sein muss, gebe ich den Roh-Text
unserem Word-Guru, der soll das dann so formatieren, dass es hübsch
(FSVO) aussieht).

> Ja, und ein wichtiger Punkt ist auch noch:
> Bei PDF hast Du für ein bestimmtes Thema _eine_ Datei, in der alles
> enthalten ist.
> Bei HTML hast Du, auch wenn selber erzeugt, einen ganzen Schwarm von
> Dateien, sofern das Endergebnis nicht nur ein banaler Fließtext ist.

Kann man vermeiden, wenn einen das stört. Mich stört es nicht.

> Schon ein einziges Bild, ein Style-Sheet oder eine (mitzuliefernde)
> Schriftart sorgen für eine Aufsplitterung.

Style-Sheets und Bilder kann man direkt einbinden (style-Element bzw.
data:-URLs). Ist zwar hässlich, funktioniert aber. Bei Schriftarten bin
ich mir nicht sicher. Ich sehe keinen Grund, warum es nicht gehen
sollte, aber ich habe es noch nie probiert.

hp

[Peter J. Holzer]

On 2022-10-07 13:34, Thomas Hochstein <t...@thh.name> wrote:
> Peter J. Holzer schrieb:
>> Markdown hat allerdings (wie die ganze Klasse der "Wiki-Syntaxen") den
>> Nachteil, dass es nur sehr beschränkt für komplexe Strukturen geeignet
>> ist bzw. für alles eine ad-hoc-Syntax benötigt. Das ist fein, wenn man
>> eh nur das übliche braucht (also in >> 90% aller Fälle), aber in den
>> paar Fällen, wo man etwas komplexeres braucht, steht man dann an.
>
> Das ist richtig, aber man kann - geeignetes Parsing-Tool vorausgesetzt,
> natürlich - Markdown mit HTML mischen. (Oft genügt schon ein erweiterter
> Markdown-Doalekt)

Eigentlich braucht man einen unerweiterten Markdown-Dialekt, denn das
ist Teil der Basis-Spezifikation.

Aber manche der erweiterten Dialekte erlauben das nicht.

Und da sind wir bei einem weiteren Problem: Die Implementationen
unterscheiden sich alle ein bisschen. In der einen geht das, in der
anderen jenes. Wenn man dann mit drei oder vier Markdown-Dialekten
arbeitet, kommt man rasch durcheinander (insbesondere, wenn man ReST,
MediaWiki, Textile, etc. auch noch verwendet - die schauen auch
irgendwie ähnlich aus und können ähnliches, aber halt wieder ein
bisschen anders).

Ich verwende Markdown viel und gerne. Aber der Wildwuchs von "einfachen"
Sprachen macht mein Leben nicht unbedingt einfacher.

hp

[Thomas Hochstein]

Peter J. Holzer schrieb:

> On 2022-10-07 13:34, Thomas Hochstein <t...@thh.name> wrote:
>> Peter J. Holzer schrieb:
>>> Markdown hat allerdings (wie die ganze Klasse der "Wiki-Syntaxen") den
>>> Nachteil, dass es nur sehr beschränkt für komplexe Strukturen geeignet
>>> ist bzw. für alles eine ad-hoc-Syntax benötigt. Das ist fein, wenn man
>>> eh nur das übliche braucht (also in >> 90% aller Fälle), aber in den
>>> paar Fällen, wo man etwas komplexeres braucht, steht man dann an.
>>
>> Das ist richtig, aber man kann - geeignetes Parsing-Tool vorausgesetzt,
>> natürlich - Markdown mit HTML mischen. (Oft genügt schon ein erweiterter
>> Markdown-Doalekt)
>
> Eigentlich braucht man einen unerweiterten Markdown-Dialekt, denn das
> ist Teil der Basis-Spezifikation.
>
> Aber manche der erweiterten Dialekte erlauben das nicht.

Ja, das war schlecht formuliert.

Gemeint war: Mit erweiterten Markdown-Dialekten lassen sich durchaus auch
komplexere Aufgaben abdecken, ggf. sogar Tabellen und natürlich die
Zuweisung von IDs und Klassen.

Wenn auch das nicht langt, kann man notfall noch HTML verwenden.

> Und da sind wir bei einem weiteren Problem: Die Implementationen
> unterscheiden sich alle ein bisschen. In der einen geht das, in der
> anderen jenes. Wenn man dann mit drei oder vier Markdown-Dialekten
> arbeitet, kommt man rasch durcheinander (insbesondere, wenn man ReST,
> MediaWiki, Textile, etc. auch noch verwendet - die schauen auch
> irgendwie ähnlich aus und können ähnliches, aber halt wieder ein
> bisschen anders).

Yep. Das ist nachvollziehbar.

[Sieghard Schicktanz]

Hallo Peter J. Holzer,

Du schriebst am Sat, 8 Oct 2022 22:29:28 +0200:

> > Ja, schön. Das wäre kein Problem, wenn man die CSS-Files einfach
> > kriegen könnte, die scheinen zumindest aber oft als proprietätrs Gut

...

> Zumindest Firefox hat seit Ewigkeiten die Funktion "Save Page As ..
> Web page complete", die alle eingebundenen Resourcen (also auch
> CSS-Files) in einem Subdirectory ablegt und die Links entsprechend
> anpasst, dass man das File danach lokal öffnen kann. Das funktioniert

Meistens - die Web-Seiten-Ersteller sind da recht phantasievoll im
Erfinden von Methoden, das zu hintertreiben.

> nicht immer, hauptsächlich weil der Browser natürlich JavaScript

Ein gerne benutztes "Ablankungsmittel".

> nicht umschreiben kann, aber für CSS und Images ist das ziemlich
> problemlos. Verwende ich oft, wenn ich eine Website analysieren will.

Auch dann, wenn das CSS-File so aussieht?
---------------------------
@import url("modernized-common.css");
@import url("debwiki.css");
---------------------------
Die referenzierten Files sind "natürlich" nicht im Download enthalten.

> Und abrufen kann man die CSS-Files natürlich immer - tut der Browser
> ja auch.

Offensichtlich eben _nicht_ "immer".

...

> >> sondern lässt dem Rendering Device gewisse Freiheiten, damit der
> >> Text z.B. an die Größe des Bildschirms angepasst werden kann.
> >
> > Was zwar der originalen Intention entspricht, aber "manchmal" von
> > den Erstellern mancher Web-Seiten etwas zu heftig unterbunden wird.
>
> Ja. Ich habe noch mit Grausen die "Optimized for 800x600"-Seiten im
> Kopf. Ist besser geworden (hauptsächlich durch die Verbreitung von
> Handys), aber manche sogenannten Web-Developer (oder ihre

Die "Händies" (das ist schließlich ein ur-deutscher Ausdruck) haben
dafür ganz andere Unsitten provoiert, wie fast leere Seiten mit
riesigen Schriften, kaum bestückte Menüs, in alle Richtingen rein- und
rauswischende Elemente u.v.m.

> Auftraggeber) können sich offensichtlich vom Ideal des "pixelgenauen"
> fixen Layouts nicht lösen. Die wollen eigentlich Hochglanzbroschüren
> auf Papier.

Eine _technische_ Beschreibung (um die es mir hier im wesentlichen
geht) _braucht_ meistens ein definiertes Lay-Out, damit man auch die
richtige Zuordnung erkennnt. Ein Roman kommt ohne sowas aus.

> >> Das ist m.E. genau die Schwäche von PDF: Das gibt eine gewisse
> >> Output-Größe vor, und wenn das Device nicht groß genug ist, eine
> >> ganze Seite auf einmal darstellen zu können, wird das Lesen mühsam
> >> bis unmöglich.

Das ist eben der Sinn und Zweck des "Lay-Out"s - den Inhalt so auf eine
Grundstruktur zu aufzuteilen, daß er übersichtlich und erkennbar
bleibt. HTML hat - im Grunde - kein Lay-Out, das wirft alles dorthin,
wo es grade Platz hat. Und wenn der Ersteller dem entgegenwirkt, sind
abhängig vom "Darstellungsmedium" (das hier fest voreingestellt ein
Bildschirm ist) oft "interessante Effekte" die Folge.

> > Das ist aber genau die Intention bei PDF: Das Ergebnis soll
> > unabhängig vom darstellenden Medium immer genau gleich aussehen.
> > Das intendierte "darstellende Medium" dafür ist in sicher >99% der
> > Fälle halt ein Stapel Papierblätter, vorzugsweise beidseitig
> > bedruckt, auch bekannt als "Buch" oder "Heft".
>
> Eben, und das ist halt oft nicht die Art, wie ich das dann lesen will.
> Die Intention des Erstellers geht an den Bedürfnissen des Users

- _dieses_ Users -

> vorbei. Daher halte ich PDF sehr oft (nicht immer) für ungeeignet.

> HTML hingegen wäre prinzipiell auch für Papier geeignet, aber da gibt

Nein, ist es prinzipiell nicht. Um es auf ein festes Medium zuz
übertragen, muß erst noch der Zwischenschritt "Lay Out" gemacht werden.

> es halt keine Toolchain in die jemand auch nur annähernd soviel Arbeit
> gesteckt hätte wie in die Browser (die das Ausdrucken eher
> stiefmütterlich behandeln). [dompdf habe ich immer noch nicht
> ausprobiert. Aber das README stimmt mich nicht besonders
> optimistisch.]

Bezüglich der Browser-Ausdrucke kann man dem nur uneingeschränkt
zustimmen. Es ist ja nichtmal sinnvoll möglich, ein definiertes
Web-Formular so - auch in ein PDF - auszudrucken, daß man damit noch
was anfangen kann. Ergebnis: solche Web-Seiten bieten oft eine extra
"Druckansicht", die für den Zweck erstellt ist und die man dafür nutzen
kann (z.B. unser beliebtes Finanzamt). oftmals unnütze Doppelarbeit.

...

> >> Das "H" in "HTML" steht für Hypertext, ja. Es ist daher nicht

> > Aber nicht dafür, daß alles mögliche von anderen Stellen _benötigt_
> > wird, um die Seite überhaupt darzuzstellen. Die originale Intention
> > war AFAIR die Möglichkeit, Referenzen auf _weiterführende_
> > Informationen einbinden zu können, die _bei Bedarf_ darüber

...

> Was die Kapitel betrifft: Das ist IMHO einfach praktischer. Wenn ich

Nur für den Ersteller - der Nutzer wird damit am Netzanschluß
festgebunden (und muß damit, wenn per internet, sozusagen "seine Hautür
sperrangelweit aufreißen"), und einen kompletten Download eines solchen
Werks kann man i.a. vergessen - zuviel Aufwand. Da hilft oft nichtmal
ein Batch-Downloader (URX, Neu-DAMIsch in Reinstform...), weil die
Tiefe der Links nicht steuerbar ist. Ich hab' mir mit sowasschon auch
mal die Inhalte mehrerer Server eingefangen, die mit dem Anlaß
überhaupt nix zu tun hatten, bloß weil da ein Link auf ein Detail
irgendwo stand, der dann den kompletten Inhalt mitzog. Mag zwar sein,
daß das eine Gehässigkeit des Betreibers war, es ist aber trotzdem
ärgerlich bis evtl. sogar gefährlich.

> die Wahl zwischen "HTML, single file" und "HTML, one file per
> chapter" habe (die Wahl hat man bei Online-Doku oft, vor allem, wenn
> das HTML aus einem anderen Format generiert wurde), wähle ich

Leider nicht immer, und beides ist unangenehm. "Single File", weil eine
unstrukturierte "Textwüste", kapitelweise wegen der zerfledderten
Dateistruktur und der Notwendigkeit des on-line-Lesens.

> praktisch immer letzteres (und wenn es als dritte Möglichkeit "PDF"
> gibt, das nur, wenn ich es ausdrucken will, oder wenn das
> autogenerierte HTML schwere Fehler enthält). Da findet man sich
> einfach leichter zurecht. Und das funktioniert natürlich auch lokal.

Nur dann, wenn die Links nicht aus dem PDF stammen, sondern nachher
erst eingeflickt wurden.

> Das Einbinden von Resourcen (CSS, Bilder, Schriftarten, ...) aus
> anderen Files war zwar nicht in HTML 1.0 vorgesehen (tatsächlich gab
> es damals noch nicht mal Bilder, die hat erst Mosaic eingeführt),

CSS, Schriftarten u.ä. auch nicht.

...

> > Nein, das ist richtig, angesichts der Verhaltensweisen der
> > Hauptnutzer, kommerzieller Einrichtungen, Werbeunternehmen u.ä.,
> > ist es nicht verwunderlich, wie HTML inzwischen benutzt wird. Nur
> > sind damit die Ergebnisse halt kaum noch benutzbar.
>
> We will have to agree to disagree here.

Na schön, gerne. Ich bin halt nicht so der Werbe-Banner-Fan.

[Peter J. Holzer]

On 2022-10-10 19:02, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>> We will have to agree to disagree here.
>
> Na schön, gerne. Ich bin halt nicht so der Werbe-Banner-Fan.

Plonk.

hp