diff options
author | John MacFarlane <jgm@berkeley.edu> | 2017-02-09 21:26:24 +0100 |
---|---|---|
committer | John MacFarlane <jgm@berkeley.edu> | 2017-02-09 21:26:24 +0100 |
commit | 0a4ba91994c875b0eaf22b76a6153c0d1de0f018 (patch) | |
tree | 2bbef149ce288843eec9e6b7d928025f1047e7d9 /test/dokuwiki_multiblock_table.dokuwiki | |
parent | 6949d74e01cceab360db4dd8f4b1c0550b246908 (diff) | |
download | pandoc-0a4ba91994c875b0eaf22b76a6153c0d1de0f018.tar.gz |
Reverted deferred media bag code.
This was not actually being used. Since it adds considerable
complexity, it's best not to include it unless we are
actually going to use it.
The original thought was that we could do all loading in the
readers, always deferred and thus costless. This was supposed
to eliminate the need to traverse trees loading resources in
the docx, epub, odt writers and in PDF and SelfContained.
(It would also have the side effect that --extract-media could
be used with all input formats. This wasn't an intended side
effect, and it could be debated whether it's desirable, since
--extract-media was originally designed to extract the media
contained in a docx or odt or epub container.)
However, we never actually took the step of moving all of this
work to the readers, for a couple of reasons. The main reason
is that we'd still need to fetch resources in the docx,
epub, odt, pdf and self-contained writers, since the Pandoc AST might
have been built programatically and hence not generated by a reader.
So it's not clear that doing lazy loading in the readers would have
any real advantage.
I'm still not completely sure about this --- if we change our
minds it would be easy to undo this commit.
@jkr comments welcome.
Diffstat (limited to 'test/dokuwiki_multiblock_table.dokuwiki')
0 files changed, 0 insertions, 0 deletions