No single translation has been changed, but pt_BR and pt_PT are now correctly
sorted. This removes the artifical diffs that running
make ../lib/layouttranslations
did produce previously.
Thanks Scott for the idea to modify the document. This seems to work, but I am
not surer whether it is safe in all cases, so better warn if this is used.
Also MacOSX ReadMe files. Note that a few lib/doc files are
also "updated" because trailing spaces are removed, but their file
formats are the same because they were recently updated at 83672113.
I did "git checkout LFUNs.lyx" because this file is generated
automatically and has a special header.
Updating all previews (even if only one has changed) is more costly
than I thought. Thanks to Guillaume for tracking down this
performance issue.
This reversion is related to the reversions at 358745d0 and
a7a14395. See also #7242 and #9855.
This reverts commit 29948eec26.
Updating all previews (even if only one has changed) is more costly
than I thought. Thanks to Guillaume for tracking down this
performance issue.
This reversion is related to the reversion at 358745d0.
See also #7242 and #9855.
This reverts commit 66f527e417.
Prevent loading of lmodern.sty if non-TeX fonts are set and
Define DejaVu as non-TeX font.
This ensures that non-TeX fonts are used if requested (lmodern.sty set
the 8-bit version of LatinModern if compiling with LuaTeX).
Also ensure that a font with all characters is used. (LatinModern misses small
Greek characters.)
Similar actions for other manuals and examples with Greek or Cyrillic script
will solve some more export tests with non-TeX fonts.
Prevent encoding changes whenever the TeX engine is XeTeX or LuaTeX,
as XeTeX/LuaTeX use only one encoding per document:
* with useNonTeXFonts: "utf8plain",
* with XeTeX and TeX fonts: "ascii" (inputenc fails),
* with LuaTeX and TeX fonts: only one encoding accepted by luainputenc.
+1 no needless encoding switches
+1 runparams.encoding matches the correct encoding at any time
+1 less complicated code.
-1 there may still be problems with CJK (possibly impossible to
solve for Xe/LuaTeX with TeX fonts).
For LuaTeX & TeX fonts, the complete document uses the encoding
of the global document language.
See also #9740.
The referenced commit lead to performance issues and possibly
crashes in some cases when saving preferences. Thanks to Guillaume
for discovering the issues. See #9828 for more discussion.
I hope to come up with a better fix for #9507.
This reverts commit 390ae05444.
These were fixed manually. I tried to add an option to updatedocs.py to
open and save a file with LyX, but that did not work, since
lyx -x 'command-sequence buffer-write ; lyx-quit' does not write and does
not quit.
gen_lfuns.py does now produce the current file format, and and LFUNs.lyx was
re-created with the updated script.
There is one difference if you compare this version of LFUNs.lyx with the old
version updated by lyx2lyx: All occurences of LyX, TeX etc. in the lfun
descriptions are no longer output as logos. I do consider this as a feature,
since the old version did also output the TeX part of BibTeX as a logo, as well
as places where the names were part of some syntax, e.g. lyx::LyXRC::LyXRCTags.
lyx2lyx did not yet know about /systemlyxdir/ and set \origin to the path
where my git tree lives instead. This path is not usable except on my machine,
so better write something more usable instead.
This is a special command line switch of lyx2lyx, so it does not interfere
with normal usage. I did not try to deduce the systemlyxdir from lyx2lyx to
be on the safe side.
LyX format, create a backup of the original file. We put it in the backup
directory, if one exists, otherwise in the directory the original file is
in. This is the same strategy as for normal backups. Basically, the only
diferences are: (i) what name we use and (ii) we do not over-write any
backups that may already exist.
Actually, the changed tests were used to prevent overwriting the encoding
changed in Buffer::writeLaTeX with a language-default encoding.
This is still required for XeTeX with TeX-fonts unless a proper solution is found.
Documents with more than one encoding and TeX-fonts fail with LuaTeX,
as "luainputenc" can only handle one encoding.
With inputenc == "auto" or "default", the encoding changes with
the language and must be reset after an eventual language switch in insets
or environments (see #6216).
However, whether we need to do this does not depend on 8-bit TeX vs. LuaTeX
but on the possible use of more than one encoding for the document.
With "nonTeXFonts", the encoding is utf8,
LuaTeX with TeX fonts requires encoding handling similar to 8-bit TeX.
(Additionally, the value of "params.inputenc" could be tested: if it is
not "auto" or "default", we have just one common encoding and could skip
the reset as well.) Not sure how much time this saves, though.