Markdown: Erfahrungen mit MarkEdit, Export als PDF

[agrajag]

Woran kann man das erkennen?

Entweder, indem du ins App-Bundle schaust und dort Contents/Frameworks/Electron findest. Oder via Activity-Viewer. Electron-Apps fallen dadurch auf, daß sie viele Prozesse auf machen, die wiederherum viele Threads haben. Das sind Ressourcen-Monster.

 

[lisanet]

Bei der Gelegenheit vielleicht noch einen Tipp: Deckset, Präsentationen in Markdown. Das ist soooo viel geiler, als sich einen in Powerpoint oder Keynote abzumühen.

... also wenn Präsentationen, dann Prezi ->

Aber auch daran sieht man sich satt.

 

[lisanet]

@jteschner
Ich verstehe ja deine Begeisterung für Obsidian. Aber ich weiß wirklich nicht, was mir das konkret für meine typischen Nutzungszenarien bringt. Hier mal ein Bsp eines Markdown README eines meiner Github-Projekte

-> https://github.com/lisanet/update-mergerfs-repo

Diese README möchte ich dann auch ggf. als PDF erstellen können (um es in ein eventuelles binary package zu integrieren). Und da sollte dann der PDF-Export sowohl gleiche Schriftart, eingermapen gleiche Farben für Links, Code-Blöcke, ggf farblich differenziert etc haben. Und die Schriftgröße sollte bei 11pt / 12 pt liegen bei A4 output.

 

[agrajag]

... also wenn Präsentationen, dann Prezi

Aber auch daran sieht man sich satt.

Prezi ist nett anzuschauen... aber zu erstellen?. Der Charme an MD-Präsis ist, daß man sich sich nicht um das genaue Positionieren von Elementen nicht kümmern muß. So wie bei Beamer-Präsientationen.

 

[agrajag]

Sind PDFs echt noch so ein Ding? Besonders, wenn das eh nie gedruckt wird? Am Bildschirm finde ich PDFs in den meisten Fällen eher unhandlich.

 

[lisanet]

Sind PDFs echt noch so ein Ding? Besonders, wenn das eh nie gedruckt wird? Am Bildschirm finde ich PDFs in den meisten Fällen eher unhandlich.

ich sage doch nirgends, dass ich PDF immer brauche oder haben will. Aber wenn ich es mal machen möchte, dann soll es halt passend sein. Und wie ich schon geschrieben habe, ich kriege den github style für HTML ja hin. Aber der output nach PDF ist dann nur entweder mit passendem Style aber nicht hinsichtlich Seitenumbruch (pandoc -> Safari) oder umgekehrt (pandoc -> Word) möglich, aber nicht beides.

Und Präsentation sind nicht mein Nutzungszenario. Daher habe ich in #3 auch nur nach eben alternativen Lösungen für Styles und PDF gefragt, am besten mit Bordmitteln ggf. scripte oder Ergänzungen zu MarkEdit / pandoc.

Dennoch danke für die anderen Anregungen.

 

[agrajag]

ich sage doch nirgends, dass ich PDF immer brauche oder haben will. Aber wenn ich es mal machen möchte, dann soll es halt passend sein.

Ich wollte damit nichts infrage stellen. Es hatte mich nur interessiert. Hätte ja sein können, daß du in Kontexten arbeitest, wo das noch "ein Ding" ist. Warnur reine neugierde.

Und wie ich schon geschrieben habe, ich kriege den github style für HTML ja hin. Aber der output nach PDF ist dann nur entweder mit passendem Style aber nicht hinsichtlich Seitenumbruch (pandoc -> Safari) oder umgekehrt (pandoc -> Word) möglich, aber nicht beides.

Hast du mal sowas wie `<div style="page-break-after: always;"></div>` ausprobiert? EDIT: Du kannst in den Export-Einstellungen zumindest Seitenumbrüche bei Top-Level-Abschnitten erzwingen, falls es für deine Zwecke reicht.

Und Präsentation sind nicht mein Nutzungszenario. Daher habe ich in #3 auch nur nach eben alternativen Lösungen für Styles und PDF gefragt, am besten mit Bordmitteln ggf. scripte oder Ergänzungen zu MarkEdit / pandoc.

Das hab ich auch nur, weil wir gerade beim Thema "Markdown" waren, in den Raum geworfen, da viele diese SW nicht kennen.

 

[Difool]

ich kriege den github style für HTML ja hin. Aber der output nach PDF ist dann nur entweder mit passendem Style aber nicht hinsichtlich Seitenumbruch (pandoc -> Safari) oder umgekehrt (pandoc -> Word) möglich, aber nicht beides.

Schau dir dazu mal die Möglichkeiten von media="print" an:
<link rel="stylesheet" media="print" href="print.css" />

How to Create Printer-friendly Pages with CSS
https://www.sitepoint.com/css-printer-friendly-pages/

Wenn du eh bereits eine taugliche html-Ausgabe mit css vorliegen hast, dann dazu eine print.css anlegen.


Beispiel: How to Make Your HTML Print Styles Different from Your PDF Print Styles
https://www.madcapsoftware.com/blog/how-to-make-your-html-print-styles-different-from-your-pdf-print-styles/

 

[lisanet]

@Difool

Dannke für die Links.

Ich sehe schon, ich muss mich da wirklich einiges tiefer mit CSS befassen, als ich das bisher getan habe.

 

[jteschner]

Die direkte Markdown-Eingabe mit gleichzeitigem Preview fehlt dort halt. Das ist auch so in MarkText und hat mir nicht so gefallen. Das "Umschalten" der Ansicht habe ich ja schon in VS Code und da gefällt es mir auch nicht so recht, wobei ich dort wenigstens direkt in Markdown-Code schreibe und ihn sehe.

Ich glaube, dass ich diesen Punkt nicht recht verstehe.
Markedit sowie Typora machen doch so zB etwas im "Source Mode":

Aber das meinst du nicht, oder?
Im Live-Preview sieht es dann etwas anders aus. Da wird zB in Typora so wie in Obsidian so lange der Markdown Code angezeigt, bis das Kommando abgeschlossen ist.
Ich verstehe daher nicht was du eigentlich meinst. Ist aber vielleicht nicht kriegsentscheidend ...

 

[lisanet]

Markedit sowie Typora machen doch so zB etwas im "Source Mode":

ja, den "Source Mode" kenne ich...

Aber das meinst du nicht, oder?
Im Live-Preview sieht es dann etwas anders aus. Da wird zB in Typora so wie in Obsidian so lange der Markdown Code angezeigt, bis das Kommando abgeschlossen ist.

... und genau da liegt ja der Unterschied. In MarkEdit mit dem Preview-Plugin sehe ich Source und Preview direkt nebeneinander. In Typora muss ich umschalten, wenn ich den Preview haben will. Diese Funktionalität des Umschaltens habe ich ja auch schon in VS Code.

Das ist nicht kriegsentscheidend, wie die anderen Dinge ja auch. Ich finde es beim erstmaligen Erzeugen eines Textes aber recht sinnvoll, das gleich zu sehen.

 

[jteschner]

Preview haben will. Diese Funktionalität des Umschaltens habe ich ja auch schon in VS Code.

Das ist nicht kriegsentscheidend, wie die anderen Dinge ja auch. Ich finde es beim erstmaligen Erzeugen eines Textes aber recht sinnvoll, das gleich zu sehen.

ok, ich glaube zu verstehen.
Allerdings kann man bei Typora und Obsidian direkt in dem Live-Preview schreiben - in Markedit ist das anders. So sieht man immer den den ganzen Text in der Preview und nur der Teil/das Wort/die Komponente, an dem gerade bearbeitet wird, wird im Source-Mode angezeigt. Da muss man gar nichts umschalten.

 

[wegus]

So sieht man immer den den ganzen Text in der Preview und nur der Teil/das Wort/die Komponente, an dem gerade bearbeitet wird, wird im Source-Mode angezeigt.

Genau und deswegen brauche ich den Source Mode fast nie.

 

[lisanet]

Allerdings kann man bei Typora und Obsidian direkt in dem Live-Preview schreiben

ja kenne ich von MarkText. Das ist die open-source-Variante von Typora. -> https://github.com/marktext/marktext

Das habe ich schon länger getestet und so richtig warm geworden bin ich damit nicht. Ich werde da aber wie gesagt nochmals mit Typora probieren, ob ich mich mit diesem Konzept anfreunden kann.

Ich kann mich da nur wiederholen. Mein eigentlicher Start mit Markdown war, dass ich mich per ssh in andere Rechner einloggte und dort eben mit nano zuerst Testdatei angleget habe, in denen ich meine Systemmodifikationen beschrieben habe, mal Auszüge aus der bash_history eingefügt habe, nen Link auf eine Webseite etc.

Das habe ich dann vom reinen Text auf Markdown umgestellt, weil das dann auch via ssh mit nano / less / cat einfach leichter und übersichtlicher zu lesen war.

Und das ist neben den README für guithub-Projekte eben nach wie vor ein Nutzungsszenario. Daher arbeite ich eben gerne im Markdown-source-code. Und diese Arbeitsweise habe ich dann mit der Zeit halt auch auf den Mac übernommen.

Nur kommt da halt noch dazu, dass ich aus Markdown auch HTML und PDF exportiere, weil ich diese beiden Formate auf dem Mac schöner und angenehmer zum lesen empfinde, als dass ich auf dem Mac ein Terminal öffne und das mit nano / less / cat mache.

Dennoch mag ich es halt, die Texteingabe direkt im Source-Code vorzunehmen. Wie schon oben erwähnt, das mit gleichzeitigem Preview ist nicht kriegsentscheidend. Es ist auf dem Mac halt schöner, als im Terminal zu arbeiten. Aber die Arbeit im Terminal werde ich dennoch weiter haben, da ich eben die Texte auf den remote Rechnern habe.

Edit:

Um mal rein optisch zu zeigen, warum ich Markdown im Source-Code gerne nutze, hier ein screenshot, wie so eine Notiz auf einem meiner NAS aussieht. Ich finde das leichter zu lesen und übersichtlicher, als reinen Text. Und HTML oder PDF bringt halt beim Zugriff über ssh nichts.

 

[jteschner]

Um mal rein optisch zu zeigen, warum ich Markdown im Source-Code gerne nutze, hier ein screenshot, wie so eine Notiz auf einem meiner NAS aussieht. Ich finde das leichter zu lesen und übersichtlicher, als reinen Text. Und HTML oder PDF bringt halt beim Zugriff über ssh nichts.

Anhang anzeigen 471365

OK. Alles gut. Wobei ich in deinem anhängendem Screenshot kaum einen Unterschied zu Markedit oder Typora im Source-Mode sehe - ggf. in der Größe der Einzüge oder in der Farbwahl - aber das lässt sich ja einfach in den Einstellungen oder auch über ein "Thema" anpassen.
Aber zurück zu deinem Thema ... Optik ist ja eher sekundär.

 

[Nevikov]

@lisanet Vielleicht hast du es übersehen, aber guck dir mal meinen Beitrag hier im Thread an. Gerade iA Writer müsste deinen Vorstellungen mindestens nahe kommen. Es gibt dir die Möglichkeit, den Quellcode zu bearbeiten und hat daneben eine Vorschau. Dazu gibt es standardmäßig schon die Vorschau im GitHub-Style und das lässt sich auch direkt so als PDF exportieren. Andere Styles auch möglich und auch Anpassungen via CSS.

 

[rudluc]

Ich nutze iA Writer auch gerne mit Markdown. Es schreibt nicht nur, sondern bietet auch eine Dokumentenverwaltung mit iCloud-Synchronisation, sowie optional eine Grammatik- und Stilprüfung. Es läuft auch auf dem iPhone. Es kostet etwas, aber glücklicherweise nur einmal.
Eine Alternative dazu ist Notebooks. Die beiden sind aber nicht funktionsgleich!

 

[lisanet]

@lisanet Vielleicht hast du es übersehen, aber guck dir mal meinen Beitrag hier im Thread an. Gerade iA Writer müsste deinen Vorstellungen mindestens nahe kommen. Es gibt dir die Möglichkeit, den Quellcode zu bearbeiten und hat daneben eine Vorschau. Dazu gibt es standardmäßig schon die Vorschau im GitHub-Style und das lässt sich auch direkt so als PDF exportieren. Andere Styles auch möglich und auch Anpassungen via CSS.

... nehme ich auf meine Testliste mit auf. Kenne ich bisher nicht.

Ich teste aber immer eine längere Zeit, da ich so eine Software besser kennen lerne als mehrere Programme an einem Tag mal schnell durchklicken.

Aktuell werde ich nun erst mal die Links von @Difool verwenden und mich tiefer mit CSS befassen. Zudem habe ich in Pandoc weiter Möglichkeiten entdeckt, meine schon entwickelten Dienste / Schnellaktionen / scripte zu erweitern und bspw mithilfe von Word nicht nur das Problem des Seitenumbruchs zwischen Überschrift und Absatz zu lösen, sondern auch Styles zu verwenden.

Insoweit ist also MarkEdit immer noch nicht durch getestet, aber bislang mein Favorit. (habe ich oben aber ja schon ein paar mal geschrieben, warum)

 

[lisanet]

Wobei ich in deinem anhängendem Screenshot kaum einen Unterschied zu Markedit oder Typora im Source-Mode sehe - ggf. in der Größe der Einzüge oder in der Farbwahl

Das ist ein Terminalfenster, mit dem ich per ssh auf einem remote-Rechner eingeloggt bin. Weder mit MarkEdit noch mit Typora kann ich per ssh auf einem remote-Rechner arbeiten.

Das war doch auch nur ein Bsp, warum ich Markdown-Source gerne nutze und per ssh nutzen muss.

Die Größe der Einzüge sind Markdown-Syntax für Code. Da ich in diesem Bsp nano nutze, ist es so drastisch einfacher: einfach Tab und schon ist es als Code markiert. Für Einzeiler ist das deutlich einfacher, als die backticks, die immer beide Häande benötigen und auch am Ende angesetzt werden müssen.

Ich habe dafür nano auf eine Tab-Weite von 4 eingestellt.

 

[jteschner]

Das ist ein Terminalfenster, mit d.....

Aaaaargh ... natürlich, das ist es - sorry, da war ich auf dem komplett falschen Dampfer :-/