Closed expilo closed 9 years ago
I had answered this in detail on the context mailing list. Copy-pasting the solution here:
ort answer: Add --no-wrap
to \defineexternalfilter
:
\deffineexternalfilter
[pandoc]
[
filter={pandoc --no-wrap -f \externalfilterparameter{format} -t context
-o \externalfilteroutputfile},
format=twiki,
directory=output,
]
Long answer: This is what is happening.
Normally, when an external filter like pandoc creates an output, it adds a
\n
at the end of the last line. This leads to an empty line when the
file is read back in ConTeXt. To prevent that I set \endlinechar=-1
in the
inline mode.
However, this also means that the linebreak at the end of every line is
ignored. Typically this is not a problem because one expects \inline<...>
snippets to be short.
But pandoc formats its output to 80 characters. So, the example that you gave is formatted as:
w artykule L*** (E.Januszkiewicza) \quotation{Notatki wspomnień z życia
A. Mickiewicza}
When reading it, the space at the end of 'zycia' is ignored.
I can try not setting \endlinechar=-1
, and adding \removeunwantedspaces
after reading a file, but this will require some extensive testing. An
easier solution is to add --no-wrap
option to pandoc, so that pandoc does
not wrap the lines in the first place.
Since there is an easy work around, I am closing this issue. If someone else also encounters the same issue with another filter, I can look into trying to come up with a robust solution at the TeX side of things.
When using the \inlinepandoc command in the first paragraph below interword spacing is supressed in random (?) locations and html entities are not interpreted properly. This does not happen when using pandoc environment.