[WIP] reloaded 2020: "Einsteiger-pdf" - Mitwirkende gesucht

[andies]

Noch eine Anmerkung. Mir hat mal ein Sprachwissenschaftler erzählt: "Bei jeder Sprache gibt es Leute die entscheiden, wie richtig gesprochen und geschrieben wird" und das wird hier nicht anders sein. Ich würde mich wohler fühlen, wenn wir (in Ruhe) vorab entscheiden, wer am Ende den Daumen hebt oder senkt. Denn wenn das nicht klar ist und einige Leute viel Energie hineinstecken, dann aber unklare Entscheidungsregeln bestehen und Sachen hin- und herschwanken, kann das sehr demotivierend sein. Ich bin einfach für eine klare Ansage, wer das letzte Wort hat und es wäre sicher hilfreich zu wissen, nach welchen Regeln derjenige vorgeht. Das kann eine Person sein, eine Gruppe, wer auch immer - nur eben kein hin und her.

[Schotty]

Wünschenswert wäre es eventuell, das von der Form her in der Weise zu organisieren - aber:
- ich habe weder Erfahrung mit dem Akzeptieren von Vorschlägen in Git/Github und will mich eigentlich auch nicht auch noch dort einarbeiten;
- es ist m.E. zwingend, dass die files auf FHEM-eigenen Servern verbleiben, für eine Infrastruktur außerhalb sehe ich jedenfalls im Moment keine "schlagenden Gründe".

Pull-Requests sind bei GitHub praktisch und gar nicht so kompliziert: du siehst dir die Änderungen/Änderungsvorschläge an und übernimmst sie entweder mit einem kurzen Klick oder eben nicht.

Der m.E. 'schlagende' Grund wäre eben die von mir anfangs erwähnte Möglichkeit, mit den md-files direkt die GitHub-Pages (also die 'Onlineversion') zu erstellen. So könnte die vermutlich notwendige Konvertierung in die mediawiki-Syntax entfallen, was unterm Strich sicherlich einiges an Arbeit sparen würde.
Die Files selbst könntest du ja zusätzlich ins FHEM-eigene SVN hochladen (quasi als 'Backup' und auch damit es in der 'echten' FHEM-Infrastruktur liegt).
Aber ich will hier auch keine Grundsatzdiskussion GitHub/SVN anfachen, ich wollte nur auf eine in meinen Augen komfortable Möglichkeit hinweisen..

[andies]

Ich bin einfach für eine klare Ansage, wer das letzte Wort hat...

Ich werde mal noch konkreter: Beta-User entscheidet endgültig. Findet das Zustimmung?

[Schotty]

Ich werde mal noch konkreter: Beta-User entscheidet endgültig. Findet das Zustimmung?

Das ist für mich persönlich derzeit sowieso Stand der Dinge, schließlich hat Beta-User ja schon mit dem Dok angefangen und in meinen Augen ist es somit erstmal primär 'sein Projekt'.

[Beta-User]

Hallo zusammen,

(ich komm mit dem Ändern gar nicht nach...)

Noch eine Anmerkung. Mir hat mal ein Sprachwissenschaftler erzählt: "Bei jeder Sprache gibt es Leute die entscheiden, wie richtig gesprochen und geschrieben wird" und das wird hier nicht anders sein. Ich würde mich wohler fühlen, wenn wir (in Ruhe) vorab entscheiden, wer am Ende den Daumen hebt oder senkt. Denn wenn das nicht klar ist und einige Leute viel Energie hineinstecken, dann aber unklare Entscheidungsregeln bestehen und Sachen hin- und herschwanken, kann das sehr demotivierend sein. Ich bin einfach für eine klare Ansage, wer das letzte Wort hat und es wäre sicher hilfreich zu wissen, nach welchen Regeln derjenige vorgeht. Das kann eine Person sein, eine Gruppe, wer auch immer - nur eben kein hin und her.

Verrätst du uns, wer "wir" ist?
(s.u.)

Ich habe kein Problem mit Diskussion über den richtigen Weg, wichtig ist mir nur, dass wir da irgendwie auch vorankommen. "Nur mit Wiki" war da in der Vergangenheit nach meinem Geschmack zu wenig Bewegung, was teilweise auch damit zu tun hat, dass Wiki "per Definition" eben "neutral" sein soll und weniger "Meinung" wiedergeben. Auf diese Weise entsteht aber mMn. kein Leitfaden und keine wirkliche Diskussionsgrundlage, sondern eher ein Irrgarten...

Ergo habe ich vor längerem begonnen, eben diesen Hut anzusehen, und irgendwann - nachdem auch Uli dazu schweigsam war - eben entschieden, mir den aufzusetzen. Es ist etwas schade, dass das jetzt zeitlich zu einer Zeit ein halbwegs präsentables Stadium erreicht hat, zu der wir auch an anderen Ecken eine teils sehr emotionale Diskussion sehen, aber auf den St.-Nimmerlein zu warten, macht andererseits ja auch keinen Sinn.

Daher ist es eben jetzt so wie es ist, und von daher hatte ich eingangs schon deutlich versucht zu signalisieren, dass notfalls eben ich entscheide, wie was gemacht wird, selbst wenn ich am Ende alles alleine machen muß (was ich nicht glaube). Weiter hatte ich auch versucht, zu einigen Fragen bereits soweit klar Stellung zu beziehen, dass jeder die Wahl hat, sich darauf einzulassen. Auch meine Denkweise zu bestimmten Dingen dürfte hinlänglich bekannt sein.

Ich werde mal noch konkreter: Beta-User entscheidet endgültig. Findet das Zustimmung?

Wer bessere und ebenfalls zielführende Vorschläge zum Vorgehen hat: Her damit!
Wer den Hut haben will: Melden!
Wer sachdienliche Beiträge hat: s.o.: ich will der Diskussion über welches Thema auch immer nicht aus dem Weg gehen.

Und: ich habe weder jetzt - und nach meinem derzeitigen Befinden auch nicht zu einem späteren Zeitpunkt - irgendein Problem damit, "das Baby" wieder aus der Hand zu geben! Es sollte nur - in welcher Form auch immer und einigermaßen zeitnah - ein "gutes" Ergebnis rauskommen.



Damit bestimmte Positionen von meiner Seite (als "Wahlprogramm") klar sind:

* DOIF
Das DOIF-Thema würde ich vorläufig gerne auf die Seite legen, ich sehe da neben den bereits genannten Dingen noch mind. an zwei Punkten erhebliche "Bauchschmerzen":
- Es sollte in Phase 3 auch eine englische Fassung geben. Aber ich glaube nicht, dass irgendjemand DOIF "richtig" zum laufen bekommt, wenn er es per englischer commandref versucht. Das ist imo ein "no go"! Damit ist aber auch klar, dass das wenn, dann nur in einem eigenen Abschnitt eine Rolle spielen kann, weil es jedenfalls in der englischen Fassung nichts verloren hat.
- Auch die deutsche Commandref kommt mir eher vor wie eine große Ansammlung von Beispielen. Das liegt evtl. in der Natur der Sache, aber es ist - jedenfalls für mich - völlig unübersichtlich.
+ Dafür gibt es viel eigenständige Doku und viele User, die einem helfen können, wenn man das will (ich kenne aber nicht eben wenige, die irgendwann für sich entschieden haben, das nicht zu wollen). Von daher ist es eigentlich _für eine Einführung_ ausreichend, wenn es an passender Stelle erwähnt wird.

(Bis vor kurzem hatten wir im svn auch einen weiteren "Generalisten" - MSwitch; das schien ähnliche Optionen zu bieten. Hier stellte sich auch bei den Entwürfen schon die Frage, mit welchem Recht nur das eine, nicht aber das andere... (beide User-Gruppen, die das jeweils (noch...) im Einsatz haben, scheinen damit jeweils ja sehr zufrieden zu sein.).

* GitHub
Als dauerhafte Lösung: No!
Die files bleiben auf der Server-Infrastruktur "unserer'" community.
(Nochmal: falls jemand was vergleichbares auf dieser Infrastruktur aufsetzen WILL: no problem, aber hier "nice to have", ich komme ohne aus.)
Es mag sein, dass man statt mit einem Floß auch mit dem A380 über den Ozean kommt, aber mMn. sind wir mindestens bei einem Raddampfer, was jedenfalls mir ausreicht; ich würde daher darum bitten, die Diskussion über "wünschenswert" einzustellen...

(Btw.: Wenn das ganze mal steht, könnte man auch den Weg des diff aus Wiki gehen und das halbwegs automatisieren... Dann kann jeder, der Wiki "kann" direkt "Vorschläge" machen...)

Meine Meinung: wir sollten erst mal einen neuen Pfad durch's Dickicht anlegen, alles andere wird dann schon .

[WIP] halt...


Damit das nicht untergeht:
Was den Weg md zu den diversen Zielformaten angeht, gibt's einen separaten Thread hier (der richtet sich derzeit vorrangig an Schotty und xenos1984).

[Schotty]

* GitHub
Als dauerhafte Lösung: No!
Die files bleiben auf der Server-Infrastruktur "unserer'" community.

Danke, das ist doch mal eine klare Ansage (ein klares "nein" ist mir lieber als gar keine Reaktion - dann weiß ich nämlich, dass mein Geschreibsel überhaupt gelesen und ggf auch durchdacht wurde ).

[andies]

Verrätst du uns, wer "wir" ist?

Jeder, der mitmacht, akzeptiert diese Regel.


Gesendet von iPhone mit Tapatalk Pro

[Prof. Dr. Peter Henning]

Semantisch falsch. Du meinst: Jemand der diese Regel nicht akzeptiert, darf nicht mitmachen.

Ich habe so meine Zweifel, ob das zielführend ist. Ich habe als Herausgeber schon Bücher mit bis zu 40 Autoren gemacht, weiß also, wovon ich rede. Wenn man so rigide Regeln aufstellt, zerstört das die Kreativität.

Ich schlage vor, das viel lockerer zu sehen, und das Gesamtwerk in einzelne Abschnitte aufzuspalten. Dann findet man erstens leichter Mitstreiter, und kann das zweitens besser aktualisieren.

LG

pah

[Schotty]

(...) Gesamtwerk in einzelne Abschnitte aufzuspalten. Dann findet man erstens leichter Mitstreiter, und kann das zweitens besser aktualisieren.

Sehe ich im Grunde auch so, daher hatte ich initial beim privaten Brainstormen mit Beta-User auch Markdown und die Aufsplittung in einzelne Files (derzeit: ein md-file pro Hauptkapitel) vorgeschlagen.
Die PDFs etc, die wir in den ersten Beiträgen eingestellt hatten, sind bereits das Ergebnis der Zusammenfassung&Umwandlung der einzelnen md-files.

[Beta-User]

Jeder, der mitmacht, akzeptiert diese Regel.

Das klingt - mit den Einschränkungen, auf die pah zurecht hingewiesen hat - gut!

Fehlt noch Rückmeldung zu der Frage hier?

sicher hilfreich zu wissen, nach welchen Regeln derjenige vorgeht.

oder darf ich dazu einstweilen schlicht auf das hier verweisen:

Mein Plan ist, das im Lauf des Jahres vollends "irgendwie" zum Abschluß zu bringen, und je mehr ggf. bereit sind, an dem Projekt mitzuwirken, desto "besser" und vollständiger kann es werden. Was man bereits jetzt erkennen können sollte, ist

   
• in etwa das, was an Themen darin zu finden sein soll, (allerdings teils auch für die Zukunft nur kurz angerissen bzw. als Stichwort zum "woanders weiterlesen");
• die "Tonlage", in der ich das gerne gestalten will und
• der "Erwartungslevel" an das "Publikum", was die Übertragung von Beispielen auf die eigene Installation usw. angeht.

Vielleicht sollte ich eines noch anmerken:
Gerade im Mittelteil sind ganz viele Platzhalter. Falls das den Eindruck erweckt, dass das zu allen diesen Themen ausführlich werden muß oder soll: Vermutlich nicht.

Vielleicht nochmal eine etwas andere Variante: Der geneigte Leser soll
- einen ersten Pfad durch das Dickicht "abgehen" können, und dabei (eher indirekt) gleich einen Eindruck davon bekommen, dass er praktisch alles auf seine Bedürfnisse anpassen kann und darüber hinaus häufig eben eine "gewisse" Transferleistung erforderlich ist, deren Erbringung (oder wenigstens Willen zur Erbingung) wir als Erwartung an ihn stellen;
- so in etwa "die Größe des Grundstücks" erkennen können;
- wissen, wo wichtige Eckpfeiler stehen (angefangen bei der commandref, in die viele Neulinge scheinbar nicht mehr schauen...)
- den einen oder anderen hilfreichen Trick mit auf den Weg bekommen;
- vielleicht beim einen oder anderen Thema einen ersten Einstieg finden (v.a. Heizungsregelung, Lichtsteuerung, Rollläden).

Bestimmt kommt da noch das eine oder andere dazu oder entfällt auch, je nachdem...

Ich schlage vor, das viel lockerer zu sehen, und das Gesamtwerk in einzelne Abschnitte aufzuspalten. Dann findet man erstens leichter Mitstreiter, und kann das zweitens besser aktualisieren.

Bin grundsätzlich für zielführende Vorschläge zu haben, das ganze ist - auch derzeit schon - nicht monolitisch aufgebaut, sondern es gibt für jedes Kapitel eine Markdown, wie Schotty auch schon geschrieben hat. Das kann man auch weiter aufdröseln, kein grundsätzliches Problem damit von meiner Seite.

Die files werdet ihr voraussichtlich auch bald hier finden, ich werde nur noch etwas Zeit brauchen, um das eine oder andere noch umzuorganisieren, man sieht z.B. an Schotty's Version, dass die Nummerierung der .md-Files nicht mit den jetzigen Kapitelnummern übereinstimmt und ähnliches mehr. Dann will ich die Screenshots noch vorab ins Wiki bringen, was das ganze noch weiter vereinfachen sollte (auch was die "Zuspielung" besserer Bilder angeht ) und gewisse zentrale Formatierungen noch vom eigentlichen Text trennen (weitestgehend jedenfalls).

Ich bitte daher um etwas Geduld!

Vorab wollte ich aber wenigstens denjenigen, die ggf. über die Ostertage etwas Ruhe haben ein wenig zu schmökern Gelegenheit geben, genau das zu tun: Lesen, sich eine Meinung bilden, ggf. mal kreativ hirnen, was ok ist, was gut, was weniger, was zu viel und was zu wenig .

Es wird aber trotzdem so sein, dass es sowas wie "einen Herausgeber" geben muß bzw. einen Gesamtverantwortlichen. Andererseits werde ich überlegen, ob es nicht Sinn macht, einzelne Teile aus dem Wiki 1:1 zu übernehmen (speziell notify hätte ich da im Moment im Auge) bzw. diese so zu überarbeiten, dass das paßt.

(Wenn "man" am Ende kein pdf braucht/will, sondern im Wiki einen "Grundkurs" durchklicken kann und sich die einzelnen Teile ausdrucken oder lokal runterladen: Mir auch recht ). Dto, wenn jemand (zusätzlich, daraus) "zielführende" Video-Tutorials machen will: gerne.
Wichtig ist vor allem, dass wir auf einen aktuellen Stand kommen, FHEM denjenigen schmackhaft machen, für die es etwas ist und den anderen klarmachen, warum es ggf. für sie besser ist, wenn sie eine andere grüne Wiese nehmen .

That's all...

Have fun! (oder sagt's wenn nicht, gerne mit konkretem Verbesserungsvorschlag...)

[Prof. Dr. Peter Henning]

"Durchklicken" ist ein Wort. Wenn wir wirklich ein Lernmodul haben wollen (sagen wir, im SCORM-Format): 2012-2015 haben wir in einem großen EU-Projekt unter meiner Leitung Software entwickelt, die aus einem Semantic MediaWiki Lenrmodule generieren kann.

LG

pah

[Schotty]

@pah: Klingt interessant - generell kostenlos und frei verfügbar ist sie nicht zufällig, oder? Das wäre sicherlich nicht nur für die hier angedachten Zwecke und die daran Beteiligten ein feines Ostergeschenk 

[Prof. Dr. Peter Henning]

generell kostenlos und frei verfügbar ist sie nicht zufällig, oder?

Nicht zufällig, sondern bewusst. Ich muss das nur noch irgendwo ausgraben...

LG

pah

[Beta-User]

"Durchklicken" ist ein Wort.

Hatte eher an ein paar ganz simple Buttons auf ein paar Web-Pages gedacht, aber vom Raddampfer auf Mondgleiter umsteigen? Warum nicht...?


Meine ersten Assoziationen dazu:
Au ja! Forumzugang ab jetzt nur noch mit Führerschein .
Niemanden mehr mit RTFM traktieren müssen (geht ohne Seitenzahlen auch schlecht...)
Alle wissen alles und finden das wenige, das sie nicht wissen mit wenigen Klicks .

Ein Traum...
(Ironiefrei: Wenn ich was beitragen kann - Gerne!)


Wie dem auch sei, im Anhang zu Post 2 hier gibt's jetzt wie versprochen ein zip mit den Quelltexten und dem Latex-etc-Beiwerk. Die screenshots sind nun in der Wiki-Infrastruktur zu finden und auch im Quelltext (soweit erkennbar vollständig) dahin verlinkt.

Da ich bei der Gelegenheit sowieso nochmal über den ganzen Text drübermusste, habe ich einige Kleinigkeiten noch "nebenbei" geändert, daher gibt es auch neue pdf- und epub-Fassungen.

Wer pandoc austesten will (hier: Version 2.9.2.1):

Code Auswählen Erweitern

pandoc --toc -s -H formating_simple.tex intro.md kap*.md refs_pdf.md metadata.yaml --pdf-engine=xelatex -o pdf2020.pdf -f "markdown+yaml_metadata_block+implicit_figures+table_captions+footnotes+smart+pipe_tables+raw_html+emoji+mmd_link_attributes+inline_code_attributes" --number-section -V subparagraph --dpi=300 --include-before-body=frontpage.md --email-obfuscation=javascript

## epub erstellen

pandoc --toc -s intro.md kap*.md refs_pdf.md metadata.yaml -f "markdown+yaml_metadata_block+implicit_figures+table_captions+footnotes+smart+pipe_tables+raw_html+emoji+mmd_link_attributes+inline_code_attributes" --number-section -V subparagraph --dpi=300 -o epub2020.epub --epub-cover-image=./pics/epdf_Firstlook_demo.png --email-obfuscation=javascript
(kann aber sein, dass ihr ziemlich viel Latex nachrüsten müßt...)

Da im epub das Ausgangsformat der Bilder wohl eine Rolle spielt, könnte man die vom Wiki auch "vorrendern" (verkleinern) lassen. Dann würde es Sinn machen, die Datei "refs_pdf.md" noch weiter aufzusplitten und für die epbub-Version einfach auf die verkleinerten Fassungen verlinken (oder das via html-Anweisungen versuchen). War mir aber für den Moment too much.

Es sind noch nicht alle Links zentral zusammengefasst, aber wenn man das so macht, wäre auch die Verlinkerei für eine englische Fassung relativ einfach zu machen, weil man das (im Text) nicht von überall her  zusammensuchen muß.

Schönen Feiertag zusammen,

Beta-User

[Beta-User]

Hallo zusammen,

da teils direkt und indirekt die Frage gestellt wurde "wie kann ich helfen?", an der Stelle mal, was ich an nächsten Arbeitspaketen sähe bzw. anzubieten hätte:

   
• Korrekturen/Verbesserungen an bestehenden Teilen.

Da geht es darum, so zu tun, als hätte man keine Ahnung und würde den Text als "DAU" lesen. Ziel wäre es
-- die Lesbarkeit zu erhöhen und die "Benutzerführung" zu verbessern;
-- logische Lücken und Brüche aufzudecken;
-- eventuell mißverständliche Formulierungen möglichst auszumerzen;
-- Schreibfehler dabei möglichst auch noch zu beseitigen.
Beispiele:
--- Die "Kommandozeile" ist erst in Abschnitt 2.3.3 bebildert, aber eigentlich wäre das beim "define" (2.3.1) besser aufgehoben.
--- Beim Abschnitt beginnend mit "Dazu klickst du auf das leere Feld neben "room" " könnte man ein paar Pfeile einfügen, die jeweils auf das Element zeigen, auf das man klicken muß bzw. irgendwas eingeben. Was in https://wiki.fhem.de/wiki/Datei:GotoRAW-Import_firststeps.PNG zu finden ist, finde ich fast etwas "überdeutlich", eine etwas schlankere Variante wie in https://wiki.fhem.de/wiki/Datei:Tasmota_mqtt_config.png würde mir insgesamt besser gefallen. Aber auch da gilt: Wer den ersten sinnvollen Vorschlag macht, bestimmt letztendlich die Richtung (für Bilder daher eine Bitte: immer eine unbearbeitete und eine bearbeitete Version bereitstellen)...
--- ebenfalls bei der Raum-Geschichte steht "Menü jetzt nicht mehr "Unsorted" grün". Nun ja, eigentlich ist ja der Hintergrund auch irgendwie "grün".  Es ist halt ein "etwas dunkleres Grün", oder "farblich hervorgehoben" usw..
--- Abb. 11 hat zu viele Elemente, weil ich da grade kein "sauberes" Testsystem zur Hand hatte.

Hoffe, das ist jetzt etwas klarer?

Diesen Teil würde ich ggf. in zwei "Pakete" aufteilen:
a) Einleitung + Hardware
b) Teil 2 (erst mal noch ohne den fehlenden "Rundgang").
(Schotty, xenos1986 und andies): Darf ich euch an der Stelle konkret ansprechen?)

   
• "Rundgang" (durch die Hauptinstanz):

Das könnte jemand (bisher: 3 Namen, 2 Tasks?, aber auch gerne jemand anderes) aufgreifen und nochmal die Begriffe auflisten/wiederholen - ein Bild dazu, das ähnlich wie bei dem Tasmota entsprechende Nummern enthält, damit man das gut zuordnen kann. $motd erläutern (und bitte nicht ausblenden...).

   
• global

Da wäre "der Spur nach" das zu finden, was im pdf enthalten ist (z.B. longitude, language), allerdings würde ich tendenzielle die Verbindung zu fhem.pl mehr betonen, h2we kurz erwähnen bzw. nach hinten zu $we und IsWe() verlinken (das ist insgesamt etwas schwieriger, da man da meine Gedanken zur Gesamtstruktur erraten müßte).

   
• autocreate

Da könnte ich mir vorstellen, dass das jemand wieder auch bereits zum jetzigen Zeitpunkt ganz gut übernehmen könnte:
Gedanklich ist das im Moment der Ort, an dem MQTT2_SERVER und der Shelly ins Spiel kämen und als 2. Beispiel ein Signalduino@USB (gleich mit "by-id"  "für später").
(Bzgl. des Shelly steht da jemanden vor meinem geistigen Auge - an der Stelle würde es aber m.E. für's erste genügen, wenn derjenige die "Artwork" und RAW zur Verfügung stellen würde und zu einem späteren Zeitpunkt logs für das monotonic-userReading.)

   
• Daten aufzeichnen und darstellen

Das wäre der gedanklich nächste Themenkreis.
- FileLog-Gerät als Eventhandler erläutern;
- Exkurs für den Spezialfall Energiemessung: userReading "monotonic" (=> TRIGGER!)
- KURZ auf DBLog eingehen (ich würde dazu tendieren, Anfängern ohne DB-Erfahrung davon abzuraten, DB-Logging zu machen! Und das Stichwort "Grafana" noch ergänzen/verlinken für die, die wissen, was sie tun.)
- Das Log vom Shelly-pm erläutern (oder was ähnliches).
- Schön wäre, wenn wir eine generalisierte gplot irgendwo hätten, auf die wir verweisen können, um uns dann an der Stelle etwas intensiver um plotReplace zu kümmern.
(Falls derjenige mitliest (noch jemand anderes als die vorherigen!), den ich hier konkret im Kopf habe: Das wäre super, wenn du dich angesprochen fühlen würdest!) Da gehört m.E. etwas "Umfeldarbeit" (im Wiki) mit dazu...
Eine generelle Anmerkung zu praktisch allen gplot-Files: Die sind "old-scool-style", und deswegen teils schwer auf ähnliche Sachverhalte zu transferieren. Vielleicht liest der eine oder andere Developer hier mit und nimmt sich jeweils der Sache an...?

   
• Transfer ins Wiki u.ä.
  

Ich selbst würde mich tendenziell dann erst mal um die offene Frage kümmern, wie man das ggf. ins Wiki-Format bekommt und - so das via pandoc erfolgreich ist - weitere LaTeX (?) und css-Tweaks bzw. falls nicht erfolgreich - würde ich die anderen vorgeschlagenen Tools mal näher beleuchten.
(Und dann habe ich noch ein paar andere FHEM-Baustellen, die ich auch gerne zum Abschluß bringen würde...).
(epub ist an der Stelle nicht so wichtig; das war nur ein "Nebenprodukt", aber ganz gut um rauszufinden, wie pandoc intern "tickt". Wenn das irgendwie doch klappt, ist gut, wenn nicht, ist es kein Drama).

Bitte melden, falls das aus eurer Sicht so nicht funktionieren kann oder was wichtiges an Info fehlt, ansonsten würde es mich SEHR freuen, wenn die Leute sich melden würden, an die ich konkret gedacht hatte. Wenn nicht: Es stehen mit Absicht nur sehr wenige Namen da... Es ist definitiv eine Bitte, bei der man "Nein" sagen darf (z.B. durch Schweigen). Und selbstredend: Falls jemand anderes sich angesprochen fühlen sollte: Ebenfalls SEHR GERNE!

Schöne Ostern!

Beta-User