This revives a patch by Uwe and extends it. Additional options to font
packages/fontspec can now be entered in Document Settings.
This is principally also true for TeX fonts, if the new TeXFont tag
MoreOptions is set. For the time being, I have only done this for
MinionPro, as a model and prove of concept.
Note that adding more TeXFonts requires a file format change,
respectively, and changes to tex2lyx (in the same way as I've done for
MinionPro).
This addresses #8226
With non-TeX fonts, the \inputencoding setting is overridden
by "utf8-plain" (pass-through). Keeping the old value allows
switching back to TeX fonts without the need to (re)set
the input encoding.
Also change back the GUI name of the "auto-legacy" setting
(cf. #11115).
The culprit here is the constructor QString(QByteArray const &): in
Qt4, it would interpret the byte array as latin1, and in Qt5 as utf8.
Therefore it is safer to use explicitly QString::fromUtf8 instead of
this constructor.
Several places where additionally simplified, in order to avoid some
extra conversions.
Ensure the default encoding "utf8" comes always first,
followed by other common variants.
The encodings were sorted based on the GUI name which leads to
the default setting moving from the top position in some localizations.
Prepare for languages that use CJK with TeX fonts and Polyglossia
with non-TeX fonts.
Korean is already supported by Polyglossia,
LyX support will follow (file version change).
Previously, we only included branches from the master document. This
includes those from the parent, grandparent, etc, and does so in a way
that won't crash on recursive includes.
This is not done right at all. The best is to revert for now and
think about how to do it properly.
This reverts commit 66a3d64346332e47252b37dbc0f80158738987dc.
The basic problem here is that rather than using an abstract syntax,
backend-specific param strings are produced in the listings dialog,
depending on whether listings or minted is used.
Of course this breaks if a user switches backends inbetween (s/he would
have to open and re-apply each and every listings inset!)
Do at least the most basic translations in InsetListings::latex().
A sane solution would imply the use of only one param syntax with
respective interpretation for each backend. But this would be a file
format change.