This Unicode char (U+2029) is intended as a semantic separator between
paragraphs; it is cleaner and less intrusive than the pilcrow sign that
we used before. This also changes the default `sep` value used in the
`pandoc.utils.blocks_to_inlines` Lua function.
Custom writers can define a default template via a global `Template`
function; the data directory is no longer searched for a default
template.
Writer authors can restore the old lookup behavior with
``` lua
Template = function ()
local template
return template.compile(template.default(PANDOC_SCRIPT_FILE))
end
```
Like custom readers, like writers, can define the set of supported
extensions by setting a global. E.g.:
``` lua
reader_extensions = {
smart = true,
citations = false,
}
```
Custom writers can define the extensions that they support via the
global `writer_extensions`. The variable's value must be a table with
all supported extensions as keys, and their default status as values.
E.g., the below specifies that the writer support the extensions `smart`
and `sourcepos`, but only the `smart` extension is enabled by default:
writer_extensions = {
smart = true,
sourcepos = false,
}
New-style custom Lua writers can now define an alternative entry function
`BinaryWriter`. If a function with that name is defined, then pandoc
will treat the returned string as binary output. This allows to generate
formats like docx and odt with custom writers.
The `T.P.Lua.writeCustom` function changed to allow either a TextWriter
or ByteStringWriter to be returned. The global variables
`PANDOC_DOCUMENT` and `PANDOC_WRITER_OPTIONS` are no longer set when the
writer script is loaded. Both variables are still set in classic writers
before the conversion is started, so they can be used when they are
wrapped in functions.
The function runs the *citeproc* processor on a Pandoc document.
Exposing this functionality to Lua allows to make citation processing
part of a filter or writer, simplifies the creation of multiple
bibliographies, and enables the use of varying citation styles in
different parts of a document.
The module now has the additional functions `list_directory`,
`make_directory`, and `remove_directory`. This makes it easier to write
cross-platform scripts that need to inspect or modify the file system.
Noto Sans CJK TC, that is suggested as a character set that contains Japanese characters, may not be suitable to properly display Japanese characters. Rather, Noto Sans CJK JP is much more recommendable for that purpose.
Although some characters originated from China are quite similar among countries/regions, most of them have evolved into different shapes in Mainland China, Hong Kong, Taiwan, Japan, Korea, and Vietnam. Therefore, it is best to use a character set that the language of the country/region uses for the readability/recongnizability sake. See also [an webpage that discusses the glyph appearance issue in Chinese, Japanese, Korean, and Vietnamese languages](https://heistak.github.io/your-code-displays-japanese-wrong/).
[README of Noto CJK](https://github.com/googlefonts/noto-cjk/blob/main/README.md) may be also good resource to know which font should be used to display characters of each language.
Albert Krewinkel