The Japanese math manual was not compiling because of some
complications with foreign language switching. This would
have been fixed after the translation from English to Japanese
is done but I want to make sure the document is compilable
for 2.1.
These translations were only in lib/layouttranslations. I don't know if they
were reviewed, but I understand enough dutch to be sure that they are not
completely wrong, so they are good enough for the GUI.
Now lib/layouttranslations.review contains all translations which have been
changed since the 2.0.0 release except for the ones where the commit log
mentioned that they were reviewed.
This is consistent with the treatment in LyX itself (cleanTranslation() is
also called on the translated strings), and some translators leave the context
in the translated msgstr (e.g. [[List of Listings]]), although that is not
recommended. Without this, lib/layouttranslations would contain wrong
translations.
lyx_pot.py treats the combination IsPredefined == true and UsesFloatPkg == true
incorrectly: In this case it does not extract the float name, although it needs
to be extracted. This was no problem for LyX 2.0.0, because no layout contained
this combination fo flags. However, the current version of achemso.layout uses
it for several styles, e.g. "List of Schemes".
You only see the bug if you remove lib/layouttranslations before updating it,
otherwise it would be covered by the old translations which are kept. The fix
make use of the fact that IsPredefined == false and UsesFloatPkg == false is
not supported by LyX to simplify the logic.
* disable branch-add-insert in pass thru paragraphs
* when it is not possible to input a quote inset, insert a single
ascii quote when argument to quote-insert is "single"
* handle "mathspace" dialog in Text::getStatus
* disable insertion of newline inset in pass thru paragraphs
* handle "mathdelimiter" and "mathmatrix" dialogs in GuiView::getStatus.
The pgf package 3.0.0 update lead to an error being given with
this document. Loading the 'etex' package fixes the problem.
For more information, see:
https://sourceforge.net/p/pgf/bugs/296/
The two fixes here a obviously right, although it is not clear why they are sufficient to fix the bug. Anyway I cannot reproduce any crash with it.
* the first part just conditions a whole if/else to change_next_pos.changed(). Originally, only the if branch was concerned.
* the second part is to avoid calling CursorSlice::backwardPos() when position is 0. Doing this leads to an assertion.
filehook.sty is required when you use non-TeX fonts and also the non-TeX math default font
In the same context LyX requires the font "latinmodern-math.otf", but we can currently not check for it, see my post to the list
Thanks to Benjamin Piwowarski who reported the problem and provided a fix.
magic_file() returns a NULL pointer if an error occurs, and due to a bug
this happens frequently on OS X: https://trac.macports.org/ticket/38771
I did not use the original patch, since I did not want to put a platform
specific workaround in (this needs further discussion), but the crash can
occur on all platforms and needs to be fixed.
The math parser aborts with an error message on \begin{align} and
\begin{align*} if this is not the hull inset. This is now fixed, however
this is not complete support for these two environments (the GUI does not
respect the numbering). It is only the minimal fix that ensures that no data
loss occurs for documents imported by tex2lyx.
This comes from trying to run tex2lyx on the AMS math test document
testmath.tex. Both \(...\) and \begin{math}...\end{math} are defined as
inline math formulas in standard LaTeX. tex2lyx recognizes this, but the
math parser in LyX did not handle "\begin_inset Formula \(" and
"\begin_inset Formula \begin{math}" correctly.
The fix is simple and safe: If we are in undecided mode (this is only true
for the first token of a math inset), create a hull inset of the respective
kind. Otherwise, handle the commands as before.
