Brett on 06 Oct, 2013 02:38 PM
As mentioned in other discussions, it's a webkit bug, which is what Marked uses to display the preview and export PDFs. The bug has been fixed in the open source version of WebKit, but hasn't been integrated by Apple. When they do, it will work, but until then, not within Marked.
wkhtmltopdf uses it's own patched version of WebKit, which I may have to resort to at some point.
Brett on 24 Oct, 2013 09:12 PM
1. Marked converts hr’s and <!—BREAK—> by replacing it with a div with style "page-break-before:always". This only works when Marked is printing to PDF, it wouldn’t necessarily translate to an exported HTML file. You could easily add (or shell convert) your own divs and embed the styles directly, though.
2. I’ve looked at solutions from Pandoc to wkhtmltopdf to wkpdf, but every time either size or license issues have been a problem. I’d consider adding an export processor, but there are so many options to consider when using those converters that it would require a lot of configuration on the user’s part. If you’re already capable of doing the conversion on the command line, it might just be prudent to export the html from Marked and have a Hazel process do the conversion via script…
That being said, I’ll look back into wihtmltopdf and see if it’s a feasible option.
Brett on 25 Oct, 2013 07:55 PM
Correct on MultiMarkdown 4.
As far as the workflow goes, do you still want the output PDF to have Marked styles? If that’s the case, you’ll need to use a webkit-compatible PDF generator like wkhtmltopdf or wkpdf to do the build as a command line tool. You’ll need to export the CSS from your preferred or custom style and then include it via command line options with the CLI.
Most of Marked’s features, such as Table of Contents and pagination tweaks aren’t available without Marked running. If your needs are simple, though, a wkhtmltopdf workflow with included CSS may work fine.
I am wondering if this has been resolved. I'm using Marked Version 2.4.11 (895), and when I generate a paginated PDF, the links within the document are visible but do not correctly link. If it hasn't been fixed, is there a workaround that can be employed?
Brett on 07 Apr, 2015 04:33 PM
There has been no change to WebKit's handling of intra-document
links at this point. The only workaround would still be to export
to HTML and use wkhtlm2pdf, but the same problems with certain
syntax not being carried over will exist.
Brett on 18 May, 2017 05:22 PM
Yeah, that update to the webkit source was made almost 2 years ago now,
but Apple still hasn't incorporated it into the SDK version. In order to
implement it in Marked, I'd have to include a custom webkit, which would
basically mean putting a whole copy of Safari into it. The download size
would go up by 500% and it's just not feasible for me to maintain a
codebase that's split off from the SDK.
"Made printing to PDF produce internal links when the HTML has internal links" was in release 18 of the Safari technology preview and we're now at release 30. I downloaded it and gave File>Export as PDF… and File>Print…>Save as PDF… a try:
- in a web page with plain unqualified #fragment links within the page, those links come out as URL links in the generated PDF, rather that internal PDF links (/GoTo actions) — bad :-(
- when I open a local HTML file (generated by Marked 2 & containing internal links) the internal #fragment links remain as internal links in the generated PDF — good the bug is indeed fixed.
Then I cross-checked with latest Safari (10.1 on Sierra 10.12.4), and that gave the same behaviour. Does it uses its own more recent webkit? Hard to tell, given the obfuscation inside the bundle. Security-wise it would not make sense to have Safari use a different webkit to the rest of the system - that could allow Safari to have some security fixes that were not available to the rest of the system - they would never do that.
So… is there a possibility that the ability to generate internal links in PDFs is already present in webkit on Sierra, and that Marked 2 is not for some reason benefiting from it? (Perhaps some trick needed to engage it.)
Brett on 24 May, 2017 04:23 PM
Safari does use a different webkit than is available in the SDK, though
I should note that Marked runs on the original WebKit and not the
WKWebView that was introduced more recently. I'll take another look at
switching that over and see if it makes a difference (it didn't
previously, and it was a lot of re-coding to adopt the new API for