[epdf] - Markdown, LaTeX + Convertertools

[Beta-User]

Hallo zusammen,

ich trenne mal diesen Teil der Fragen rund um die "Einsteiger-Doku 2020" hierher ab.
(Kann man nur verstehen, wenn man den Quelltext kennt, bitte also hier nur Kommentare dazu von denen, die Zugriff haben oder eine besonders gute Glaskugel).

Meine aktuelle Verständnis:

* pandoc und Co.
"pandoc" transferiert (im Standard) alles zunächst in eine "Großfile" und entfernt dabei (fast) alle "html"-Formatierungen (oder ignoriert sie). Einzige Ausnahme, die mir bisher aufgefallen ist, war das "width"-Element, das es immerhin (via .css) in's pdf geschafft hat (aber beim epub ignoriert wird).
Man kann das umgehen, wenn man ein anderes Zwischenformat wählt (getestet bisher html via wkhtmltopdf); das generiert dann aber wieder Links, die entweder gar nicht funktionieren (direkt via pandoc) oder teilweise in die Irre gehen (von Schotty berichtet: Github Wikito Converter).
Im Moment _glaube ich_, mit pandoc am Ende besser bedient zu sein, allerdings gehe ich davon aus, dass dafür einige Tweaks am LaTeX-Ende erforderlich sind (die leider sehr schwer nachzuvollziehen sind, wenn man nicht eine volle LaTeX-Installation (oder wenigstens die passenden Pakete) hat...).

Außerdem scheinen bestimmte LaTeX-Anweisungen (/footnotesize) nicht den Weg in's epub gefunden zu haben (minor issue), was aber darauf hindeutet, dass man sowas für den epub-Pfad vermutlich über html-Ersetzungen in tex-File lösen muß? (Dafür klappen aber Emoji's (Beispiel: ":+1:") direkt im epub, die pdf-Konvertierung meckert über das fehlende Unicode-Zeichen (=> andere Schriftart verwenden?)...)

* Bilder:
- Da wir (auch) ins Wiki wollen, scheint es mir sinnvoll, alle Bilder direkt da reinzuladen und dann darauf zu referenzieren. Korrekt?
- Die Skaliererei machen pdf und epub sehr unterschiedlich. Ich würde das eigentlich ungern über die in dem jeweiligen Bild hinterlegte Größe (teilweise?) lösen. Ergo wäre die Frage, ob es Sinn macht, je eine eigene, zentrale Referenzierungsfile für pdf und epub zu pflegen (im ebub gehen html-Anweisungen, oder?).
- \wrapfigure hatte ich ausgetestet, aber dabei passen die Seitenumbrüche nicht wirklich gut. Ich vermute, dass es auch da einen Trick gibt, und das dann der beste Weg wäre, die Bilderpositionierung im pdf zu fixen? (Irritierenderweise vermute ich, dass ausgerechnet das .css die richtige Stelle ist, um die \wrapfigure-Anweisungen zentral reinzumischen, ohne alle Mitautoren mit allzuviel LeTeX-Gewusel zu irritieren; korrekt?)

* Fußzeile: Wäre nett...

* Deckblatt@pdf: notfalls händisch, aber auch dafür gibt es einen Weg, oder?

* Doppelte Frontpage@epub: Wie abschalten/wo kommt das her, wie bekommt man tatsächlich ein Bild/"echtes Deckblatt" (automatisiert?) auf die allererste Seite?

Grüße, Beta-User

[andies]

Ich habe zweimal Bücher von latex in epub konvertiert und es war jedes mal eine Qual. Es gibt da keine vernünftigen Tools. Dann aber zwei Texte gleichzeitig zu pflegen, macht wesentlich mehr Arbeit.

BoD hat so eine Art epub-pdf. Die ist nicht skalierbar. Aber vielleicht wäre das die Lösung?

[xenos1984]

Wenn es darum geht, einen gemeinsamen Quelltext in mehrere verschiedene Formate zu wandeln, ist Pandoc mein persönlicher Favorit. Allerdings habe ich damit bisher nur nach PDF (über LaTeX), HTML5 und Plain Text konvertiert, und Bilder nur in der HTML Konvertierung benutzt. Mit EPUB und Bildern in anderen Formaten habe ich dagegen keine Erfahrung, auch Emojis habe ich bisher nicht benutzt.

Generell kann man in Pandoc eine ganze Reihe von Erweiterungen an- und abschalten. Dazu gehören LaTeX im Markdown, was dann aber nur im LaTeX / PDF Format berücksichtigt wird, und HTML im Markdown, das dann aber nur z.B. in EPUB und HTML berücksichtigt wird, nicht im PDF. Wenn man beides will, bleibt nur reines Markdown als "kleinster gemeinsamer Nenner", oder man muss beides einbauen, was aber gerade einem gemeinsamen Quellenformat widerspricht.

[Schotty]

Generell kann man in Pandoc eine ganze Reihe von Erweiterungen an- und abschalten. Dazu gehören LaTeX im Markdown, was dann aber nur im LaTeX / PDF Format berücksichtigt wird, und HTML im Markdown, das dann aber nur z.B. in EPUB und HTML berücksichtigt wird, nicht im PDF. Wenn man beides will, bleibt nur reines Markdown als "kleinster gemeinsamer Nenner", oder man muss beides einbauen, was aber gerade einem gemeinsamen Quellenformat widerspricht.

Genau deshalb hatte ich u.a. hier (https://forum.fhem.de/index.php/topic,109982.msg1039802.html#msg1039802) eine weitere Möglichkeit ins Spiel gebracht, die aus dem md-files sowohl html (als Vorstufe für die epub-Generierung) als auch PDF erstellt (entspr Beispielfiles siehe im Anhang des verlinkten Beitrags). Da ist nur eben das Thema mit den teilweise nicht funktionierenden internen Links ein Problem, aber vielleicht könnte da ein Experte ja eine Lösung finden.

[Beta-User]

So,

vielleicht mal an der Stelle ein paar Bausteinchen mehr zu dem, was hinter der Umstrukturierung hin zu "refs_pdf.md" gestern steckt.

Vorab:
- Ob das der Weisheit letzter Schluß war, weiß ich auch noch nicht, denn dass das die Preview-Möglichkeiten incl. Bilder zerschießt, war klar. Vorher hatte ich das jeweils am Dokument-Ende zusammengefasst, weiß aber nicht, ob damit alle Viewer umgehen könnten.
- Der "look" weder des pdf noch des epub sind bisher optimal. Die pdf-Fassung, die wikito-converter erzeugt, sieht auch imo besser aus, aber kaputte interne Links "gehen gar nicht". epub ist im Moment wie gesagt aber eigentlich eher von untergeordneter Bedeutung, aber auch da hatte ich ein "Schlüsselerlebnis", das vermutlich auch und v.a. bei der Mediawiki-Konvertierung helfen könnte...

Wegen der kaputten internen Links: Vor allem deswegen kommt letztendlich wikito-converter nicht wirklich in die engere Wahl, genauso wenig wie überhaupt der Weg über html, den man übrigens auch via pandoc nehmen könnte (ich meine, dazu schon was geschrieben zu haben, weiß allerdings nicht mehr wo bzw. über welchen Kanal). pandoc kann auch was anderes nicht, nämlich html-Style eingebundene Bilder ohne html als Zwischenformat (!) erkennen; das kommt schlicht als Text raus, genau so, wie man das eingegeben hatte...

Jetzt also mal die "pandoc-Route":
Der Ausgangspunkt meiner Überlegungen ist im Prinzip hier zu finden:https://www.xaprb.com/blog/how-to-style-images-with-markdown/. Das ist imo bzgl. der Bilder-Frage eine "extended version" von "testfile.md", allerdings etwas schwerer zu erkennen, weil da nur kurz auf "Use Standard HTML" eingegangen wird. Ich hatte mit einigen Varianten dort rumgespielt, dto. mit dem Versuch, das ganze in Tabellen zu packen.
Via pandoc Tabellen hinzubekommen, ist allerdings tricky, und mit Bildern darin ist es mir bisher schlicht nicht gelungen.

ABER: Je nachdem, WO man bestimmte Flags hinsetzt (unter "Use CSS And Special URL Parameters" zu finden), bekommt man sehr unterschiedliche Ergebnisse, unter anderem ist es mir (ich meine, mit der "img[src*="#thumbnail"]"-Variante) "gelungen", im pandoc-pdf einen _Text_ zu produzieren (nämlich den html-style Link, *staun*)...
Reste dieser Versuche findet ihr in der pandoc.css.

Damit war die Idee geboren, je nach End-Format unterschiedliche "Flags" zu setzen, um damit das passende Ergebnis zu erzeugen . Damit man das aber auch schnell wiederfindet, braucht es eben einen (relativ) zentralen Ort, und da das Setzen der passenden flags vermutlich tricky ist, macht es auch wenig Sinn, die  einzelnen Mitwirkenden rumrätseln zu lassen, was denn jetzt das passende "setting" ist. Volles WYSWIG ist zwar sehr komfortabel, aber es geht notfalls mMn. auch ohne.

Einen weiteren Netzfund will ich euch auch nicht vorenthalten:
https://cmichel.io/how-to-create-beautiful-epub-programming-ebooks/. Darin findet man u.A. unter Hinweis auf http://bbebooksthailand.com/bb-CSS-boilerplate.html eine "nette" css-file, die einen bestimmten Zweck hat: "Falsche" Vorgaben aus der epub-Konvertierung rauszufischen . Ausgetestet, und siehe da: das E-Book sieht via pandoc generiert gleich viel besser aus (es hat dann andere Mängel, insbesondere viel zu viele leere Seiten und die Sprungmarken sind jeweils "davor"...).

Bzgl. TeX und pdf gibt es an zwei Stellen auch noch Fortschritte zu verzeichnen:
- Bild auf Titelseite (dafür paßt der Text nicht, das war aber vorher schon...)
- Code "rot auf grau"

Lösung zu Punkt 1:
Titelpage als tex (siehe Anhang) und anderer "bau-Befehl", was "--include-before-body" angeht

Code Auswählen Erweitern

--include-before-body=frontpage.tex

(Für die Fußzeile wäre es wohl ähnlich, WIP)

Lösung zu Punkt 2 wäre, das hier in die tex-formatting aufzunehmen (%=Kommentar):

Code Auswählen Erweitern

%Formatierung von Code
%https://stackoverflow.com/a/40975732
\usepackage{fancyvrb,newverbs,xcolor}

\definecolor{Light}{gray}{.90}
%\definecolor{Light}{HTML}{F4F4F4}

\let\oldtexttt\texttt
\renewcommand{\texttt}[1]{
  \colorbox{Light}{\color{red!90}{\oldtexttt{#1}}}
}
Sowas bräuchten wir vermutlich noch für andere Elemente, angefangen von den Schriften. Wer Vorschläge hat: tell me...

Anbei auch das pdf und das epub (Achtung: das bringt mir aber grade "weiter hinten" Calibre zum (Fast-Dauer-) "Sanduhrzeigen"...), damit ihr sehen könnt, wie das rauskommt... (@eventuelle Erstleser: da sind keine neuen Teile drin, das ist also wirklich nur aus optischen Gründen hier angehängt).

Kurz zusammengefaßt: Steinig, mühsam, ... aber im Ergebnis scheint mir zumindest für die pdf-Fassung pandoc weiter das Mittel der Wahl zu sein. Für die epub-Version evtl. nicht.
Auch für Wiki bin ich betr. pandoc optimistisch; evtl. kann man sogar direkt (!) via css die "richtigen" Textbausteinchen reinmischen, die man dafür braucht!

Was den "LaTeX-Restbestand" "\footnotesize" etc. angeht, wäre mein nächster Test, das iVm. passenden css-Einträgen in die Richtung zu versuchen: "[][#remarkstart]" und "[][#remarkend]".

(v.a.) @xenos1984:
Das ist jetzt alles eher LATeX-nahe. Paßt das soweit und hast du Vorschläge für die Schriftfrage? Hast du Erfahrung mit der .css-Geschichte und kannst mir verraten, ob ich damit auf dem richtigen Weg bin?

Hoffe, das ist jetzt etwas klarer?

(Das alles ist für mich ziemlich komplex, und  ich muß ehrlich zugeben, dass mir jetzt zwar manches etwas klarer ist, aber der "letzte Schliff" definitiv noch fehlt...)

[Schotty]

Sieht m.M.n. gut/besser aus @Beta-User! Vor allem die rote Schrift auf grauem Grund für die Codezeilen macht es imho viel übersichtlicher. Im PDF auf S.25 scheint die Schrift allerdings eine andere zu sein - nur für den Fall, dass das so nicht gewollt war..

Das epub zickt bei mir auch rum:
- Kap. 2 (FHEM-Grundlagen) wird nach wie vor leider überhaupt nicht angezeigt und
- früher oder später scheint sich der ganze Reader/das AddOn aufzuhängen, wenn ich im Inhaltsverzeichnis die Links anklicke
Zum Testen für die epub-Ansicht nutze ich derzeit nur schnell das "EPUB-Reader"-AddOn für Firefox, damit wir nicht alle mit den gleichen Tools (= Calibre ) testen.

[xenos1984]

Die LaTeX Umsetzung sieht schon recht gut aus. Die Formatierung der Code-Elemente finde ich auch recht gelungen. Ich persönlich benutze für Code in LaTeX Dokumenten ein Package namens "listings", mit dem man noch schöner formatieren kann, inkl. Syntax-Hervorhebung, allerdings ist das sicher nicht nach epub etc. portabel. Wobei ich nicht weiß, ob vielleicht Pandoc einen "fenced code block" in ein listing-kompatibles Ergebnis umwandeln kann...

Mit epub kenne ich mich generell wenig aus, bzw. mit CSS nur in Kombination mit reinem HTML5. Von daher kann ich dazu leider wenig sagen.

Ich benutze zum epub lesen FBReader, aber scheinbar fehlen dabei Seiten / Abschnitte. Ich wollte mir die Code-Beispiele in Abschnitt 2.3 ansehen, aber der fehlt komplett...

[xenos1984]

Um noch einmal eine ganz andere Idee einzuwerfen: Beim Stöbern bin ich über DocBook gestolpert, das dafür dienen soll, Dokumentation u.a. als PDF, EPUB und HTML zu erstellen. Das klingt so ziemlich wie das, was hier gesucht wird. Genauer mit den verfügbaren Programmen habe ich mich noch nicht befasst. Auch ist die Syntax (XML) klobiger als bei Markdown. Dafür hat es mehr Formatierungsmöglichkeiten.

Vielleicht besser geeignet: AsciiDoc. Die Syntax ist einfacher, es unterstützt Textformatierung und man kann es scheinbar ebenfalls in HTML, PDF, EPUB konvertieren. Getestet habe ich es noch nicht.

[xenos1984]

Ich habe einmal spaßeshalber ein Kapitel von Markdown nach AsciiDoc konvertiert (mittels Pandoc, und dann von Hand weiter angepasst). Die entsprechende Datei habe ich angehängt, ebenso das Ergebnis folgender Umwandlungen:

Code Auswählen Erweitern

asciidoc -b html5 -o test.html test.txt
a2x -f pdf test.txt
a2x -f epub test.txt

Noch nicht probiert habe ich Bilder, auch Textformatierung nur rudimentär. Da kann man sicher noch mehr machen - es ist eher ein "proof of concept", dass man diese verschiedenen Formate rausbekommt und der Quelltext lesbar bleibt.

[Beta-User]

 
Das sieht auch brauchbar aus, und auch der Quelltext ist "easy" zu verstehen, halt nochmal anders, aber das wäre an sich kein Problem...

(Woher wußtest du, dass ich gerne Boxen haben will?)

Das als Fußnote (?) zu formatieren, wäre auch mit Markdown kein Problem, es scheint @AsciiDoc halt noch ein paar mehr "Grundtypen" für Anmerkungen oä. zu geben, so dass wir da schneller zum Ziel kämen (dafür aber englische Begrifflichkeiten am Rand stehen, die man vermutlich auch irgendwie in beliebige andere Sprachen bekommt; nur eben wieder: wie...?).

Vielleicht noch eine Anmerkung zu LaTeX: Ich habe kein grundsätzliches Problem damit, das da an verschiedenen Stellen "die Keule" rausgeholt werden muß. Ich selbst habe mich in die ganze Thematik nur soweit eingedacht, wie es notwendig war, und mir würde es auch reichen, wenn wir für die pdf-Generierung eben noch die paar "Schalter" ergänzen, die es braucht, um das auf "gefühlte 80%" zu bringen - eine "ideale Positionierung von Bildern" gehört da für mich schon nicht mehr unbedingt dazu.
Unschön ist halt, dass "man" - je nach "Schalter"/eingebundenem Package - eben "einiges LaTeX braucht, um das pdf zu backen, aber das sehe ich nicht als wirkliches Hindernis.
Von daher würde mich tendenziell die Feinheiten zu "listings" mehr interessieren als noch ein Format...
(Was das fenced code block angeht, würde ich tippen, dass man in der epub.css die richtigen Einstellungen finden muß, und code sieht an der Stelle direkt "ordentlich" aus, zum Rest: siehe html gleich.)

Was die "kaputten internen Links" bei der pandoc-html-Variante angeht, wäre meine Vermutung, dass sich das in Luft auflöst, sobald man alle (md-) files erst in eine einzige "Groß-md" piped und die dann "verhtml't" (dann bekommt man aber nicht mehr das seitliche Inhaltsverzeichnis mit Schotty's Variante hin).

Was epub (remember: Prio 5) angeht: Das dürfte auf Basis von html-code besser funktionieren, kann dann noch sein, dass man zum einen etwas aufpassen muß, was Sonderzeichen in Überschriften angeht, und zum anderen, wie man mit Bildern umgeht (lokal einbinden, vorrendern...); denn dass es "ewig dauert", dann aber am Ende zumindest in Calibre doch dargestellt wird, muss ja einen Grund haben...

Mal schauen.

Jedenfalls: Wenn wir bei Bildern keine Fortschritte haben, würde ich eher die "pure Markdown" (ohne html)-Variante weiter verfolgen und nicht das Format wechseln - md "kennen" tendenziell eben  schon ein paar Leute mehr.

[Schotty]

Was die "kaputten internen Links" bei der pandoc-html-Variante angeht, wäre meine Vermutung, dass sich das in Luft auflöst, sobald man alle (md-) files erst in eine einzige "Groß-md" piped und die dann "verhtml't" (dann bekommt man aber nicht mehr das seitliche Inhaltsverzeichnis mit Schotty's Variante hin).

Also mit einem fehlenden seitlichen Inhaltsverzeichnis hätte ich persönlich jetzt nicht so das Problem..

[xenos1984]

Das als Fußnote (?) zu formatieren, wäre auch mit Markdown kein Problem, es scheint @AsciiDoc halt noch ein paar mehr "Grundtypen" für Anmerkungen oä. zu geben, so dass wir da schneller zum Ziel kämen (dafür aber englische Begrifflichkeiten am Rand stehen, die man vermutlich auch irgendwie in beliebige andere Sprachen bekommt; nur eben wieder: wie...?).

Indem man den drei Befehlen oben noch eine Option gibt:

Code Auswählen Erweitern

-a lang=de

Vielleicht noch eine Anmerkung zu LaTeX: Ich habe kein grundsätzliches Problem damit, das da an verschiedenen Stellen "die Keule" rausgeholt werden muß. Ich selbst habe mich in die ganze Thematik nur soweit eingedacht, wie es notwendig war, und mir würde es auch reichen, wenn wir für die pdf-Generierung eben noch die paar "Schalter" ergänzen, die es braucht, um das auf "gefühlte 80%" zu bringen - eine "ideale Positionierung von Bildern" gehört da für mich schon nicht mehr unbedingt dazu.
Unschön ist halt, dass "man" - je nach "Schalter"/eingebundenem Package - eben "einiges LaTeX braucht, um das pdf zu backen, aber das sehe ich nicht als wirkliches Hindernis.

Das kann man natürlich machen, wobei man sich damit natürlich auch noch stärker an LaTeX bindet und eine mögliche Konvertierung in andere Formate (Wiki, HTML) schwieriger wird. Da stellt sich dann auch die Frage, ob man nicht gleich komplett mit LaTeX arbeitet und die anderen Formate verwirft, statt eine Mischung aus Markdown + LaTeX zu benutzen, die dann nur noch von Kennern beider Sprachen wartbar ist.

Von daher würde mich tendenziell die Feinheiten zu "listings" mehr interessieren als noch ein Format...
(Was das fenced code block angeht, würde ich tippen, dass man in der epub.css die richtigen Einstellungen finden muß, und code sieht an der Stelle direkt "ordentlich" aus, zum Rest: siehe html gleich.)

Damit (listings) ist es sicher machbar, Perl zu formatieren, aber auch für FHEM lässt sich eine Syntax erstellen. Das kann ich, falls gewünscht, auch gerne tun. Aber auch hier gilt, dass das dann komplett LaTeX-spezifisch und nicht auf andere Formate portabel wäre, womit man sich komplett auf ein Ausgabeformat binden würde.
Details: http://texdoc.net/texmf-dist/doc/latex/listings/listings.pdf

AsciiDoc scheint auch hier eine portable Lösung anzubieten: http://asciidoc.org/source-highlight-filter.html

Was die "kaputten internen Links" bei der pandoc-html-Variante angeht, wäre meine Vermutung, dass sich das in Luft auflöst, sobald man alle (md-) files erst in eine einzige "Groß-md" piped und die dann "verhtml't" (dann bekommt man aber nicht mehr das seitliche Inhaltsverzeichnis mit Schotty's Variante hin).

Hier habe ich mich noch nicht ganz in die Umsetzung der Formate eingelesen. Meine Erfahrung aus LaTeX ist die, dass es sich anbietet, Anker / Verweisziele mit deskriptiven Kürzeln zu benennen, wenn das Format dies unterstützt (z.B. sec:intro), statt mit der vollen Überschrift eines Abschnitts, weil man erfahrungsgemäß letztere doch mal ändert, und dann in der übrigen Doku alles ersetzen muss.

Jedenfalls: Wenn wir bei Bildern keine Fortschritte haben, würde ich eher die "pure Markdown" (ohne html)-Variante weiter verfolgen und nicht das Format wechseln - md "kennen" tendenziell eben  schon ein paar Leute mehr.

Auch hier die Frage: Wie hättest du es denn gerne? Ich habe mich inzwischen etwas in AsciiDoc eingefuchst, und es scheint auch für Bilder eine flexiblere und möglicherweise portable Formatierung zu bieten:
http://asciidoc.org/userguide.html#X9
Eine Möglichkeit wäre es, einfach mal damit herumzuprobieren, um sich etwas hübsches und portables damit erstellen lässt, und ob das besser aussieht / einfacher umzusetzen ist als mit Markdown.

[Beta-User]

 
Ich glaube, da hat mich jemand überzeugt, doch nochmal (teilweise) die Pferde zu wechseln und auf AsciiDoc zu setzen...

Zur Vorgehensweise:
@xenos1986, könntest du dann das komplette layouten übernehmen?
Ich (oder du?) würde dann nur "auf die Schnelle" via pandoc alle Files nach AsciiDoc konvertieren? Die Nacharbeit in Kap. 1 ist ja schon gemacht, wenn ich das richtig interpretiere geht es vorrangig darum, die Links wieder zu dezentralisieren (geht evtl. automatisch, wenn man beim Konvertieren die Link-md mit einbindet?) und dann eben v.a. die "für später"-Teile entsprechend zu kennzeichnen, oder?

Bei den Bildern schwebte mir vor, das meiste jeweils nach rechts zu pinnen bei ca. 50% Seitenbreite, ausgenommen die ganz kleinen Bildchen bzw. die ganz großen. Dabei Textumlauf links, den Text aber nicht zu gedrängt an die Bilder dranpinnen, evtl. einen Rahmen drumrum, und tendenziell eigentlich keine Beschriftungen. (Aber wenn du das Layout übernimmst, halte ich mich im wesentlichen raus, wenn gewünscht!)

Was Schriften usw. angeht, würde ich als Grundtype eher eine Serifenlose nehmen, das könnte sogar die sein, die hier im Forum genutzt wird, die ist eigentlich ganz gut lesbar und bietet etwas mehr Orientierung als z.B. Arial.
Zeilenabstand darf gerne etwas größer sein, wie von andies bereits angemerkt.

Paßt das so für Dich?

Danke für's Nachbohren!

[xenos1984]

@xenos1986, könntest du dann das komplette layouten übernehmen?

Ich kann es versuchen, muss aber zugeben, dass ich nicht der große Layout-Experte bin Mit der technischen Umsetzung bin ich versierter als mit der Begutachtung, ob es "gut" aussieht.

Ich (oder du?) würde dann nur "auf die Schnelle" via pandoc alle Files nach AsciiDoc konvertieren? Die Nacharbeit in Kap. 1 ist ja schon gemacht, wenn ich das richtig interpretiere geht es vorrangig darum, die Links wieder zu dezentralisieren (geht evtl. automatisch, wenn man beim Konvertieren die Link-md mit einbindet?) und dann eben v.a. die "für später"-Teile entsprechend zu kennzeichnen, oder?

Falls du die automatische Konvertierung mit pandoc (dabei habe ich das gleiche -f Attribut benutzt wie bei deinem Beispiel und -t asciidoc) und die erste Nacharbeit wie von dir beschrieben übernehmen könntest, würde ich die Feinarbeit machen und die Dinge, wo es "klemmt", insbesondere die Formatierung der Bilder und vielleicht manches, das etwas mehr Einarbeitung erfordert.

Bei den Bildern schwebte mir vor, das meiste jeweils nach rechts zu pinnen bei ca. 50% Seitenbreite, ausgenommen die ganz kleinen Bildchen bzw. die ganz großen. Dabei Textumlauf links, den Text aber nicht zu gedrängt an die Bilder dranpinnen, evtl. einen Rahmen drumrum, und tendenziell eigentlich keine Beschriftungen. (Aber wenn du das Layout übernimmst, halte ich mich im wesentlichen raus, wenn gewünscht!)

Ich denke, sowas lässt sich hinbekommen. Meine Werke haben normalerweise selten Bilder, deshalb frage ich lieber nach

Was Schriften usw. angeht, würde ich als Grundtype eher eine Serifenlose nehmen, das könnte sogar die sein, die hier im Forum genutzt wird, die ist eigentlich ganz gut lesbar und bietet etwas mehr Orientierung als z.B. Arial.
Zeilenabstand darf gerne etwas größer sein, wie von andies bereits angemerkt.

Das denke ich auch. Ich nehme meistens DejaVu Sans oder Liberation Sans.

Paßt das so für Dich?

Klingt gut!

Danke für's Nachbohren!

Nichts zu danken! Wenn es zu weniger Arbeit und einem schöneren Ergebnis führt, lohnt es sich ja

[Beta-User]

So, jetzt habe ich das mal probiert und bin etwas ratlos; meine Ergebnisse sehen erst mal etwas anders aus als deine (Vorschau gibt's unter Okular auch keine), von daher: Geht das in die richtige Richtung bzw. brauchst du mehr als das, was jetzt im svn zu finden ist?
https://svn.fhem.de/trac/browser/branches/epdf2020
(lokale Kopie sollte gem. https://svn.fhem.de/ so klappen:

Code Auswählen Erweitern

svn co https://svn.fhem.de/fhem/branches/epdf2020 <directory>

Wenn das paßt, würde ich den Rest auch in die Richtung anpassen, aber das sieht eigentlich erst mal nach sehr viel mehr Anpassung aus, was in kap01.txt als Muster drin war.

Code Auswählen Erweitern

a2x -f pdf intro.txt

liefert zwar ein Ergebnis, aber wenn ich die drei files erst mit cat zusammenklebe und dann den pdf-Konverter anwerfe, kommt erst mal nichts raus. Aber immerhin sind die Bilder-Links (als Text-Link) wieder "an Ort und Stelle", und sogar Formatierungsanweisungen wären zu finden.
Für kap02 (bzw. auch das zusammengeklebte File) bekomme ich folgende Meldung:

Code Auswählen Erweitern

a2x: ERROR: "xmllint" --nonet --noout --valid " [...] Doku/branches/epdf2020/pdf.xml" returned non-zero exit status 4


Wie jetzt am besten weiter?