Replies: 1 comment 1 reply
-
No. This is a good plan, and basically where I started going with the current Pandoc package anyway. I still think having an actual Haskell writer is a good idea too (for a different set of use cases involving embedding inline code in other languages) but that doesn't exclude this direction at all, and in fact nicely jives with it. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Long ago (jgm/pandoc#6087) there were attempts to bring SIL syntax support to Pandoc.
Let's think in a different way. (I'll be a bit bit tongue in cheek, with also #1866 in mind...)
With SILE + markdown.sile, or even better SILE + resilient.sile, you also get the pandocast module: the Pandoc (JSON) AST is supported as direct input. It was (and is still a bit) experimental when I initiated it, but then I'm having this idea... With a SILE distribution including these dependencies, it could be interesting to propose Pandoc's
--pdf-engine
to use this leveraged SILE as native PDF rendering engine directly, instead of TeX.This is probably a simpler patch on Pandoc's side than bringing a whole new (and as-of-yet incomplete) "input language". This could also get some interesting traction towards SILE.
Am I totally dreaming?
EDIT: But on a second thought we don't even have to use the pandocast route. Since Pandoc supports Djot, and my reading of the
--pdf-engine
logic (it converts the input to some intermediate target, and invokes LaTeX/conTeXt/roff/wkhtmltopdf as appropriate), then we could as well use the Djot route.However done,
pandoc input.xxx -o output.pdf --pdf-engine sile
uses SILE with whatever intermediate format we want to push on (djot, markdown profile with appropriate extensions, or pandoc AST).pandoc somefile.xxx -t djot -o output.pdf
(= assume we push for SILE to be the default PDF renderer for Djot)...Beta Was this translation helpful? Give feedback.
All reactions