Hi Brett, I’m reporting an issue that has been happening intermittently without a pattern, and I can’t for the life of me figure out why.
I’ve been using a custom CSS with a custom processor without issues for months, but starting last week it suddenly removes all the margins when I try to print it, so it appears like lorem_no_margin.pdf. This often goes away on its own, without me catching any clear pattern. (Often I would restart the laptop, but it still didn't resolve the issue. Then, a couple of hours later, it fixed itself. It was working fine this morning, and now the issue is happening again.)
On another laptop with the exact same settings (and the same app version), using the same file and CSS, the margin is still there and renders correctly. The result is lorem.pdf.
So it looks like it’s not related to Marked 2’s settings themselves, but that something happens when it’s sent to the printer. For what it’s worth, I’ve using the same printer with the same settings for the past few months.
I’ve attached the test Markdown file, the CSS I used, and two PDFs—one rendered with margins and one without. I’d appreciate it if you know what’s going on, or if you’ve seen something similar and have any suggestions on what I should look into. Thanks!
// Configuration (do not edit)
Marked 2 1071 (Direct)
macOS Version: 26.2
additionalMathJaxConfig:
allowPageBreakInCode: YES
bookTxtIsLeanpub: NO
summaryMdIsGitBook: NO
codeIsPoetry: NO
codeCanWrap: YES
collapsibleHeadlines: NO
convertGithubCheckboxes: YES
convertGithubEmoji: YES
convertYAMLToMMD: NO
defaultMathJaxConfig: TeX-AMS-MML_HTMLorMML
defaultPreviewStyle: 100
defaultProcessor: MultiMarkdown
enableMiniMap: NO
excludeBlockQuotesFromCounts: NO
excludeFootnotesFromCounts: NO
excludeVerbatimFromCounts: NO
excludeCaptionsFromCounts: NO
folderPreviewExtensionsArray: md, markdown, txt, mdown, html, opml
githubNewlines: YES
h1IsPageBreak: NO
h2IsPageBreak: NO
hrIsPageBreak: NO
includeMathJax: NO
includeKatex: NO
limitTextWidth: NO
mathNumberEquations: NO
mathNumberEquationsSide: 0
mathNumberEquationsAMSOnly: NO
minimalJavaScript: NO
outlineModeExtensions:
permissionGranted: YES
printHeaderBottomLeft:
printHeaderBottomRight:
printHeaderFirstPage: YES
printFooterFirstPage: NO
printHeaderTopLeft: %filename
printHeaderTopRight: %date - %time (%page / %total)
processHTMLFiles: YES
removeMetadataForPreview: NO
removeYAMLHeaders: NO
scrollToEdit: YES
shouldDetectCritic: YES
shouldHighlightMarkupErrors: NO
shouldLoadCritic: NO
syntaxHighlight: YES
syntaxHighlightOnlyLang: NO
useCustomMarkdownProcessor: YES
customMarkdownProcessor: /opt/homebrew/bin/pandoc
useCustomPreprocessor: NO
customPreprocessor: ~/Dropbox/ALL/scripts/process-tk.sh
useFirstH1AsPrintTitle: YES
Hmm. The fact that this is intermittent makes it really hard to track down. When Marked exports to print or PDF, it runs a quick JavaScript to prepare the document for print output. It's possible that occasionally that JavaScript is taking too long and the print system is picking it up before it has time to complete, although it uses callbacks and shouldn't return to the main app until it's done, so that's a shot in the dark.
What kind of machine are you running on? Does it have enough resources for a web view to run a significant amount of JavaScript?
I think what you’re describing makes sense. I don’t know much about macOS internals, but I think there’s something low-level going on with communicating with AirPrint when the JavaScript is taking a long time?
I’m running an Apple M4 Pro, but what you’re saying might be correct, because the document I’m rendering is much longer than usual (15K words).
But the strange thing is that after this happens, even trying to render shorter documents still removes the margins, as if something got cached?
Yeah, this is really a tricky one. I'd be curious how V3 handles it for you, would you be willing to try the beta and let me know? If so, got to https://markedapp.com/join-the-beta. Beyond that, I'm a bit stumped as I haven't run into this. I don't test printing often, but I do test PDF export, which on V2 creates the same output as printing using the system print dialog. On v3 the print/pdf export first calls a completely internal process to generate a print object, then sends that to the print system, rather than letting WebKit generate its own print preview.