[epdf] - Markdown, LaTeX + Convertertools

Schotty · 17 April 2020, 11:02:11

kap09

Beta-User · 17 April 2020, 16:00:19

Hab's gesehen, dass das mit dem svn Einchecken geklappt hat!

Grade habe ich noch was nettes gefunden: asciidoctorjs-live-preview - eine Extension für Firefox. Bin geneigt, die Dateien alle umzubenennen, da das bestimmte Dateiendungen braucht: "Render AsciiDoc (.ad, .adoc, .asciidoc) as HTML inside Firefox!"

Irgendwelche Einwände oder Vorlieben?

Schotty · 17 April 2020, 16:08:03

Meinst du mich mit dem 'Einchecken hat geklappt'?

Ich habe vorhin mit https://asciidocfx.com/ gearbeitet, da hat man gleich eine entspr Ansicht inklusive der Grafiken rechts neben dem Editor-Fenster (wenn man bei 'Doctype' oben asciidoc auswählt). Außerdem Icons für die Schriftgestaltung und Buttons, um direkt PDF, epub etc zu generieren - habe ich aber noch nicht getestet..

Beta-User · 17 April 2020, 16:18:58

Mist, da hat mir meine app einen Streich gespielt...

Aber der Hinweis auf asciidocFX war auch was wert. Das mag aber auch lieber eine passende Dateiendung, wenn ich das auf die Schnelle richtig interpretiert habe...
.adoc?

Schotty · 17 April 2020, 16:23:31

Nope, geht wie gesagt auch so, wie es derzeit vorliegt (als als .txt) - man muss nur oben bei 'Doctype' Asciidoc auswählen.

Beta-User · 17 April 2020, 16:30:09

...da will die Win-Version nicht mitspielen, was den preview angeht. Ist aber kein Beinbruch, muß ich halt auch noch etwas svn üben...

Da es für alle anderen dann ggf. einfacher ist, das Ergebnis im Browser mit der extension (sowas gibt's u.a. auch für chrome) anzuzeigen, mache ich das bei Gelegenheit.

Schotty · 17 April 2020, 16:39:03

Sorry, vergessen: Nach dem Auswählen von "Asciidoc" musst du dann rechts im Preview-Fenster einen Rechtsklick ausführen und 'reload page' auswählen..

Beta-User · 17 April 2020, 16:57:45

Puh, überall Neuland, Danke für den Tipp!

wg. svn: Ich puste das bei Gelegenheit rein, kein Stress damit!

Aktueller Plan wäre, dass ich das erst reinschubse, mir dann die vorgeschlagenen Änderungen zur Brust nehme und das dann auch gleich mit dem Preview checke, ob alles optisch paßt und ggf. die Bilder plaziere. Will sagen: Wenn dann ein file als ".ad" im svn erscheint, ist diese Übung durch...

Schotty · 17 April 2020, 17:07:42

Zitat von: Beta-User am 17 April 2020, 16:57:45
wg. svn: Ich puste das bei Gelegenheit rein, kein Stress damit!

Gut und schön, aber prinzipiell wäre es ja erstrebenswert, wenn das auch von meiner Seite aus ginge..

Schotty · 19 April 2020, 12:58:03

Als Beispiel - in kap02.txt steht:

Zitat
=== FHEM starten und weitere _basics_

Jetzt kann es also richtig losgehen, du startest jetzt endlich dein "richtiges FHEM". Dazu ziehst du bitte zuerst alle nicht erforderlichen USB-Geräte (vor allem Interfaces!) aus dem Raspberry Pi (auf anderen Systemen ist das nicht erforderlich), wechselst wieder auf die Linux-Kommandozeile und erweckst aus der heraus FHEM mit `sudo service FHEM start` zum Leben - das ist der gegenläufige Befehl zu dem, mit dem wir vorhin das automatisch beim Start des Raspberry (bzw. unmittelbar nach der Installation) ausgeführte FHEM gestoppt hatten.

Da ich gerade folgenden Kommentar von @CoolTux entdeckt habe und nicht weiß, ob/inwiefern das 'wichtig' ist, wollte ich hier nur mal eben kurz drauf hinweisen:

Zitat
https://forum.fhem.de/index.php/topic,110377.msg1044396.html#msg1044396
Verwende bitte nicht mehr service sondern systemcrl servivename command

Beta-User · 19 April 2020, 17:24:03

Zitat von: Schotty am 19 April 2020, 12:58:03
Als Beispiel - in kap02.txt steht:
Da ich gerade folgenden Kommentar von @CoolTux entdeckt habe und nicht weiß, ob/inwiefern das 'wichtig' ist, wollte ich hier nur mal eben kurz drauf hinweisen:

"Wichtig" ist, dass es so aktuell ist, wie es geht. Wenn es also zukünftig (verläßlich) dieser unschöne neue Command ist, dann ist das halt so (ich bin da lazy und nutze, was ich kenne *grins*). Nur getestet sollte er sein (das kommt in Start- und stop-Varianten mind. noch an einer weiteren Stelle vor; wenn, dann einheitlich!).

xenos1984 · 23 April 2020, 16:10:03

Zitat von: Beta-User am 17 April 2020, 10:03:29@xenos1984: das "kontroll-pdf" hatte ich mit a2x erstellt. Das kann aber scheinbar mit den remote-Bildern nicht umgehen (ich habe die manpage noch nicht angesehen, ist evtl. einfach). Das würde mich im Moment jedenfalls von "deiner Seite" am meisten "drücken"... (auch nicht eilig!)

Die letzte Woche war etwas arbeitsreich bei mir, aber jetzt bin ich endlich wieder dazu gekommen, mich um das Projekt zu kümmern

Ja, in der Tat scheint das dblatex, mit dem a2x normalerweise arbeitet, keine als URL eingebundenen Bilder zu verarbeiten. Allerdings gibt es stattdessen auch FOP, und das kann es scheinbar. Ich habe nun diesen Befehl benutzt:

Code Auswählen

a2x -a lang=de -f pdf --fop frame.adoc

Das gibt mir ein PDF mit Bildern (auch wenn die noch nicht richtig formatiert sind, aber eins nach dem anderen).

Die .adoc Endung wird seltsamerweise nicht im user Guide benutzt, sondern .txt - aber VIM erkennt .adoc als AsciiDoc, also scheint es wohl doch ein verbreiteter Standard zu sein. Also macht es wohl Sinn, alle Dateien so zu benennen.

Beta-User · 23 April 2020, 17:04:37

Kein Ding.

Vielleicht noch ein paar Anmerkungen zu dem, was ich zwischenzeitlich mal ausgetestet hatte:
- Es gibt dieses "Rahmendokument", aus dem raus grade alles rausreferenziert wird. Schaut man das in firefox mit installiertem asciidoctor-preview-plugin an (link), sieht das eigentlich ganz hübsch aus, allerdings: Ohne Bilder, und interne Referenzierungen passen auch nicht bzw. nur beim toc...
- Nimmt man für die "include::"-Anweisungen adoc-Dokumente, gibt es scheinbar nur einen klickbaren Link auf das Teildokument - dafür sind dann aber in diesem dann Bilder zu sehen (Formatierung: im Moment unklar).
Das war der Grund, warum ich das eine erst mal wieder umbenannt hatte. Es könnte aber sein, dass das Problem nur in der Art der Referenzierung liegt (einfacher Doppelpunkt vs. doppelter Doppelpunkt?)

Irgendwie ist das ganze jedenfalls etwas "verheddert" und ich bin unschlüssig, wie wir das am besten angehen. Kann eigentlich nur eine Kleinigkeit sein.

Meine aktuellen Gedanken:
- Super wäre es, wenn es mit dem Rahmendokument klappt. Dann hätten wir einen "live-preview" für das ganze Dokument.
- Macht aber vor allem dann Sinn, wenn wir auch die internen Links bekommen und Bilder angezeigt. Würde also erst mal checken, wie man das aufbauen/referenzieren muß, dass das geht (nächster try wäre Teildokumente aber nur mit einfachem Doppelpunkt?, Dann dasselbe mit adoc-Elementen).
- Wenn nein, sollten es in jedem Fall adoc werden, dann hat man wenigstens den "live-Preview" dieser Teile.

- Was Links angeht, ist und bleibt es schwierig. Da habe ich im Moment noch keine rechte Idee, wie das gehen kann. Vermutlich ist es auch hier so, dass man den Anker und die Quelldatei angeben muß. Wie das aber ggf. dann beim Export nach Wiki oder pdf rauskommt, wäre die Frage...

xenos1984 · 24 April 2020, 19:00:28

Zitat von: Beta-User am 23 April 2020, 17:04:37- Es gibt dieses "Rahmendokument", aus dem raus grade alles rausreferenziert wird. Schaut man das in firefox mit installiertem asciidoctor-preview-plugin an (link), sieht das eigentlich ganz hübsch aus, allerdings: Ohne Bilder, und interne Referenzierungen passen auch nicht bzw. nur beim toc...

Kurzer Kommentar / teilweiser Testbericht dazu: Hast du es auch mal mit der lokalen frame.adoc Datei im Firefox versucht? Da scheinen zumindest die Bilder zu funktionieren. Ganz durchgetestet habe ich es aber noch nicht.

xenos1984 · 25 April 2020, 09:15:29

Inzwischen bin ich etwas weiter:

Die Form mit den zwei Doppelpunkten bei Links und Bildern steht wohl für ein Block-Element, im Gegensatz zu einem Inline-Element mit nur einem Doppelpunkt. Block-Elemente müssen mit Leerzeilen oder AsciiDoc-Blöcken abgetrennt sein.
Mit AsciiDoctor in Firefox funktioniert die Live-Vorschau, wenn man das lokale frame.adoc öffnet, mit Bildern und internen Links, und das auch mit eingebundenen *.adoc Dateien.
Interne Links funktionieren auch zwischen verschiedenen Dokumenten mittels xref: <<anker>> erzeugt einen Link auf [[anker]].
Manche Attribute von Bildern (wie z.B. align) funktionieren scheinbar nur bei Block-Elementen (zwei Doppelpunkte).
Die mit FOP erzeugte PDF-Variante wertet scaledwidth="XX%" aus und skaliert Bilder entsprechend; allerdings nicht die HTML-Variante. Letztere wertet dagegen width=XX bzw. height=XX aus. Dieses wird aber ebenfalls von FOP ausgewertet und hat dann scheinbar Vorrang, also wird scaledwidth dann ignoriert. Deshalb sehe ich (noch) keine Möglichkeit, Bilder so zu formatieren, dass es für beides gut aussieht.

Ich habe das ganze einmal ins SVN geladen. Im AsciiDoctor sehe ich allerdings keinen Unterschied, wenn ich die frame.adoc öffne, d.h. ich bekomme die gleiche ausgewertete Seite angezeigt, egal ob die eingebundenen Dokumente .adoc oder .txt sind... Allerdings wird bei mir in beiden Fällen nur das erste Kapitel richtig formatiert, der Rest streikt. Mit der lokalen Datei klappt es dagegen.