[API change] Add a Figure block, modify Table block #83
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves jgm/pandoc#3177 in this library.
The design of
Figure
is the more expressive one:and the
Caption
fromTable
has been removed, since that seemed to be desired. The idea now is that a fewFigure
configurations will be special:Figure
with[Plain [Image...]]
content is a captioned imageFigure
with a sequence of captioned images as content is a "gallery" of images (could expand this to allowPlain [Image...]
blocks in the content, which would be considered captionless sub-images)Figure
with[Table...]
content is a captioned tableFigure
with[CodeBlock...]
content is a captioned code listingThese map fairly straightforwardly onto a lot of different formats as I mentioned in this comment. Some formats allow for more complex
Figure
content as well, but all formats will still need to keep these in mind, since they usually have explicit captions in their tables and code listings (when those elements exist). A future numbering/referencing system will need to respect them as well, to make sure that figures and tables can be numbered and referenced properly.At the start, writers can attempt to render a
Figure
by instead rendering aDiv
with an added"figure"
class, inside of which is aDiv
caption and the figure content, the caption being before or after the content depending on what theCaptionPos
is. I think that is a decent fallback in future for writers that encounter aFigure
in an invalid position or with invalid content for that format, but specific formats might have better ways of handling those situations.The exceptions are the captioned image and captioned table configurations, which should be detected and handled like implicit figures and tables are now, from the start, to avoid regressions in behaviour.
Each of LaTeX, JATS, DocBook, and HTML support more complex
Figure
content (which is why theFigure
block isn't just a sequence of captioned images). Beyond the special handling of the configurations above, I think the followingFigure
support is possible in those formats with this design:<fig-group>
and<formalgroup>
elementsFigure
.There may be other formats that support more complex figures, but I'm not too familiar with them.