1.) If building with external iconv, remove remnants of libiconv data
created if previousy used internal iconv
2.) Remove the variable HELP from cache to enable subsequent builds.
(Different variable-handling on new cmake (version >= 3.18))
3.) New macro to extract cmake-known-cxx-sts features
4.) Check for CXX11-features only for a subset of possibilities
known by the used cmake
LyX should still avoid crashing on those, and if they start to pass, then something is wrong (most likely, a very large part of the files is being ignored).
This is a minimal implementation, as DocBook lacks a serious way of encoding all of this. Maybe a <formalpara> could do the trick, but I'd need to find a way to shoehorn a title through the styles (i.e. a first complete tag):
Theorem: Bla bla
<formalpara>
<title>Theorem</title>
<para>Bla bla</para>
</formalpara>
This would also only be a solution for single-paragraph things, as formalpara only allows one paragraph. Or a sidebar, but it's semantically very remote.
That's mostly generating DocBook tags at an inappropriate place with some metadata, rather than outputting whatever you have at your disposal. Far from satisfying, but good enough for a generic tool (see details in the new TODO). Doesn't trigger assertions. Is valid XML.
These exports now pass, and the output looks reasonable to me
(although I do not know Hebrew). I believe they work now because of
Jürgen's fixes at a7ad0747 and d7b64b8e.
Previously there are po-entries like
#: lib/examples/Articles:0 src/TocBackend.cpp:296
#:src/frontends/qt/GuiExternal.cpp:87
msgid "External Material"
msgstr ""
now:
#: src/TocBackend.cpp:296 src/frontends/qt/GuiExternal.cpp:87
#: lib/examples/Articles:0
msgid "External Material"
msgstr ""
(The string at 'lib/examples/Articles:0' proceeds also from the directory name 'lib/examples/External_Material')
This makes it easier to use some po-editors like 'linguist'
1.) Math-editor seems to use system fonts, so install it there.
2.) We use fonts from the support-dir, so install them there too.
This is something automake may take int account too.
Thanks to Jürgen, who mentions the following:
luaotfload does not find "DavidCLM". In fact, at least on my system,
there is no such font, only "DavidCLM Medium" (and other shapes). This
one is found. Apparently, luaotfload cannot infer from the one to the
other.
As opposed to LuaTEX, XeTeX also queries TEXMF so maybe it just finds
its font there.
