Previously we always used MathML for math in EPUB3, because
the spec includes MathML. But this is not widely supported
by readers, so it seems better to allow users to choose their
math method as they can with EPUB2 or HTML.
Closes#8164.
NOTE! Existing workflows that produce EPUBv3 documents including
math will be affected by this change. You must add `--mathml` to
your command line if you want to continue producing MathML.
Previously classes like "underline" and "marked" had to
be the first class in a span in order for the span to be
interpreted as a "ul" or "mark" element. This commit allows
these special classes to be "stacked," e.g.
`[test]{.mark .underline}`; in addition, the special classes are no
longer required to come first in the list of classes.
See #8194 for context.
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.
These are nondeterministic and have repeatedly failed
on strange edge cases.
The Muse reader's maintainer has not been active, and
it isn't worth developer time to chase down these problems.
In the manual, there is an indication that Math is rendered in all output formats, yet there is no mention of PowerPoint below, when specifying how it is rendered.
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.
The previous code threw away the directory component of
the filename in constructing a new one. This led to
surprising results if you had e.g. `foo/pic.svg` and `bar/pic.svg`;
in the final PDF they'd be the same image, because the latter
would overwrite the former in the temp directory.
parsed as inlines, as the manual states.
Previously, they were parsed as inlines if they would
otherwise have been a single Plain or Para, but otherwise
left unchanged. This led to some quirky results (e.g. #8143).
We now use the general function `blocksToInlines` from T.P.Shared.
Using the default jats template of pandoc 2.18, the https://jats4r.org/jats4r-validator/ warns: "The license URI is given in `@xlink:href`. For JATS 1.1d3 and later, if the license is defined by a canonical URI, then it should be specified in the `<ali:license_ref>` child element."
I can confirm that what JATS4R recommends here is consistent with the JATS article packages found on the FTP site for the
PubMed Central Open Access Subset <https://www.ncbi.nlm.nih.gov/pmc/tools/openftlist/> (at least with the eLife article I looked at).
This proposed change follows the JATS4R recommendation and an example eLife article on the PubMed Central FTP site.
The following table feature are now supported in ConTeXt:
- colspans,
- rowspans,
- multiple bodies,
- row headers, and
- multi-row table head and foot.
The wrapping `placetable` environment is also given a `reference` option
with the table identifier, enabling referencing of the table from within
the document.
Add `formatCode` function to Text.Pandoc.Shared [API change].
Use this in the LaTeX reader so that e.g.
`\texttt{\textbf{bold code}}` is parsed as `Strong [Code ("",[],[]) "bold code"]`.
This was a leftover from previous hslua versions that relied heavily on
`Foreign.C.withCString` and the like. However, hslua 2 and later use
bytestring functions to retrieve string values, so this is no longer
needed.
This fixes a problem where the encoding used for Lua filenames would
sometimes mismatch the encoding used by the OS. The file wasn't found
when that happened, for example with an umlaut-containing filename on
Windows. The change ensures that all characters of available in the
default locale can be used in the filename.
