Conversion between markup formats https://git.pashev.ru/pandoc/atom?h=master 2021-11-02T16:29:34Z 2021-11-02T16:29:34Z John MacFarlane jgm@berkeley.edu 2021-11-02T16:28:03Z urn:sha1:70eeeca9c7b399158f01c40ab2f6ef58bd76207f This ensures that when `SOURCE_DATE_EPOCH` is set, the modification times of files taken from the reference.docx will be set deterministically, allowing for reproducible builds. Closes #7654. 2021-08-29T05:31:42Z John MacFarlane jgm@berkeley.edu 2021-08-21T22:30:13Z urn:sha1:d6d7c9620abddc5e5e45450c091bc8a73bac8f66 + Add sandbox feature for readers. When this option is used, readers and writers only have access to input files (and other files specified directly on command line). This restriction is enforced in the type system. + Filters, PDF production, custom writers are unaffected. This feature only insulates the actual readers and writers, not the pipeline around them in Text.Pandoc.App. + Note that when `--sandboxed` is specified, readers won't have access to the resource path, nor will anything have access to the user data directory. + Add module Text.Pandoc.Class.Sandbox, defining `sandbox`. Exported via Text.Pandoc.Class. [API change] Closes #5045. 2021-08-25T05:19:15Z John MacFarlane jgm@berkeley.edu 2021-08-23T00:47:18Z urn:sha1:c39ddeb8f86e9dec5bd6096685812452e3f2c65e [API change] 2021-08-25T05:18:37Z John MacFarlane jgm@berkeley.edu 2021-08-23T02:26:53Z urn:sha1:8ad22002cb5ac4c79acda84c7256c6a122e2dd93 It was uselessly restricted to PandocIO, instead of any instance of PandocMonad and MonadIO. [API change] 2021-08-25T05:18:14Z John MacFarlane jgm@berkeley.edu 2021-08-23T04:38:55Z urn:sha1:0efbfb33ada6166eb53c5effb1b80393647a1c40 from PandocIO to any instance of MonadIO and PandocMonad. [API change] 2021-08-23T01:35:28Z John MacFarlane jgm@berkeley.edu 2021-08-23T01:35:28Z urn:sha1:d37dea9eeb788f53cdde386dba812a965539132a This will allow us to use withTempDir. 2021-07-09T21:14:19Z John MacFarlane jgm@berkeley.edu 2021-07-09T21:14:19Z urn:sha1:477a67061f06827b7e807319404cc277a417e9d0 Even on Windows. May help with #7431. 2021-06-10T23:47:02Z John MacFarlane jgm@berkeley.edu 2021-06-10T23:47:02Z urn:sha1:3776e828a83048697e5c64d9fb4bedc0145197dc With the 2.14 release `--extract-media` stopped working as before; there could be mismatches between the paths in the rendered document and the extracted media. This patch makes several changes (while keeping the same API). The `mediaPath` in 2.14 was always constructed from the SHA1 hash of the media contents. Now, we preserve the original path unless it's an absolute path or contains `..` segments (in that case we use a path based on the SHA1 hash of the contents). When constructing a path from the SHA1 hash, we always use the original extension, if there is one. Otherwise we look up an appropriate extension for the mime type. `mediaDirectory` and `mediaItems` now use the `mediaPath`, rather than the mediabag key, for the first component of the tuple. This makes more sense, I think, and fits with the documentation of these functions; eventually, though, we should rework the API so that `mediaItems` returns both the keys and the MediaItems. Rewriting of source paths in `extractMedia` has been fixed. `fillMediaBag` has been modified so that it doesn't modify image paths (that was part of the problem in #7345). We now do path normalization (e.g. `\` separators on Windows) only in writing the media; the paths are left unchanged in the image links (sensibly, since they might be URLs and not file paths). These changes should restore the original behavior from before 2.14. Closes #7345. 2021-06-04T00:34:38Z John MacFarlane jgm@berkeley.edu 2021-06-04T00:34:38Z urn:sha1:b6c04383e403b0962db09e6748760d3ec376f2ed This ensures that we get `\` separators on Windows. 2021-05-30T17:23:00Z John MacFarlane jgm@berkeley.edu 2021-05-30T17:22:02Z urn:sha1:cc206af392a40dd7b01b714ae7f33b2fbf4925cc The immediate reason for this is to allow the test output of #3752 to work on both windows and linux.