Ich habe ein reproduzierbares Problem beim PDF-Export aus Markdown , das nach meiner Einschätzung erst in neueren (der neuesten?) DEVONthink-Versionen auftritt.
Ich nutze DEVONthink, um Markdown-Dokumente per HTML/WebKit als PDF auszugeben. In früheren Versionen funktionierten manuell gesetzte Seitenumbrüche
<div style="page-break-after: always;"></div>
dabei zuverlässig. Aktuell wird zwar korrekt eine neue Seite erzeugt, der nachfolgende Text beginnt jedoch nicht am oberen Seitenrand, sondern deutlich weiter unten – etwa in der Seitenmitte. Es wirkt, als würde ein unsichtbares Element vertikalen Raum belegen.
Dieses Verhalten tritt unabhängig davon auf, wie der Seitenumbruch gesetzt wird. Ich habe verschiedene Varianten getestet (HTML-Elemente mit page-break-before/after, moderne break-before-Regeln, unterschiedliche Block-Elemente sowie explizit auf null gesetzte Höhen und Abstände), jeweils mit identischem Ergebnis. Auch der Einsatz oder Verzicht auf @media print ändert nichts am Verhalten.
Zum Vergleich habe ich dasselbe Markdown-Dokument – inklusive der identischen HTML-Seitenumbrüche – in iA Writer geöffnet und dort ein PDF erzeugt. In diesem Fall funktioniert der Seitenumbruch erwartungsgemäß: Die neue Seite beginnt sauber am oberen Rand. Das spricht aus meiner Sicht gegen ein Problem im Markdown oder im von mir ausgewählten CSS-Stylesheet und eher für ein verändertes Verhalten im DEVONthink-Render- bzw. Print-Pfad (WebKit).
Ich kann das Problem mit einem sehr kleinen Minimalbeispiel reproduzieren (Markdown-Datei, zugehöriges Stylesheet und das resultierende PDF) und stelle diese Dateien bei Bedarf gerne zur Verfügung.
Nach meinem Eindruck trat dieses Verhalten in früheren DEVONthink-Versionen nicht auf. Deshalb wollte ich nachfragen, ob dieses Problem bereits bekannt ist, ob es einen empfohlenen Weg für manuelle Seitenumbrüche beim Markdown→PDF-Export gibt oder ob hier möglicherweise ein Bug im aktuellen Exportprozess vorliegt.
Konvertieren das MD doch bitte mal nach HTML. Und schau dir das HTML in Safari an. In den Entwicklertools solltest du sehen können, was da los ist. Zumindest, wenn du Safari sagst, es soll den Media Type Print benutzen. Das sollte in den Entwicklertools möglich sein.
Alternativ: HTML von Chrome aus drucken.
Vermutlich benutzt iAWriter einen anderen Renderer.
Wenn schon Umweg, dann ist der Weg über iAWriter sinnvoller. Das ist wenigstens ein ausgewachsener MD-Editor, in den könnte ich auch eigene Stylesheets importieren.
Aber ich würde das gerne in DT erledigen und eigentlich dachte ich, dass dieses Verschieben des Textes nach dem Umbruch etwas Neues ist. Vielleicht installiere ich mir nochmal eine ältere DT-Version und vergleiche.
Es sollte nicht sein. Aber es hat nichts mit DT selbst zu tun, wie man leicht sehen kann, wenn man die Konvertierung ohne CSS durchführt. Abgesehen davon: Mit dem jetzt nachgereichten CSS sieht das HTML hier so aus:
Das hat so keinen Sinn. Bitte mach genau das, was ich vorgeschlagen habe: Konvertiere dein MD bei in DT nach HTML. Guck dir das in den Developer Tools deines Browsers an (zur Not auch Safari). Schau dort nach, wie das CSS aussieht und vor allem, welches da geladen ist. Ich kann mir schwer vorstellen, dass es sich wirklich um das handelt, was du gepostet hast. Grund:
body {
margin:1.5em calc(max(1.5em,(100vw - 59.3em)/2));
}
Wenn du z.B. ein 1900px breites Fenster hast, sind das bei 10px font size (warum stellst Du sowas im CSS ein?): (1900 - 593) /2) 653 Pixel Rand rechts und links. Da bleiben von 1900 Pixel noch gerade 594 Pixel übrig. Zufall? Nein. Deine Formel ist nur ein sehr komplizierter Ausdruck für margin: 1.5em 59.3.em. Denn:
x - ((x-y)/2)*2 = y, mit x = 100vw und y = 59.3em. Denn dass max(1.5em, 100vw - body width) jemals 1.5em ergeben würde, wollen wir nicht hoffen.
Außerdem enthält das CSS einen Fehler, denn *:not('#...') ist kein gültiger Selektor.
Wie auch immer: Wenn ich body,html {margin: 1.5em; width: 59.3em;} eintrage, sehen HTML und PDF vernünftig aus. Und weder mit diesem noch mit deinem CSS sehe ich das von dir beschriebene Phänomen.
Das Problem, dass beim Ausdruck auf der zweiten Seite der Text nach unten geschoben wird. Das war es doch, worum es ging. Insofern habe ich das nicht noch einmal erwähnt, sondern dachte, das ist klar.
@MichaelHD warum möchtest du uns nicht zeigen, was das developer tool des browsers anzeigt? damit wäre das problem schnell identifiziert, da gebe ich @chrillek recht! Gerne helfen wir dir, aber du machst es uns wirklich schwer.
