LyX did not distinguish compressed and uncompressed svg files previously.
Therefore XHTML export of vector graphics did use svgz images directly, which
is not supported by browsers. If svg and svgz are treated as two formats then
all works fine. This is also consistent with the loadable image formats
reported by qt: It reports both svg and svgz.
The gunzip dependency in converters is not new (it is already used internally),
but the gzip dependency is new, so it might not be available on windows.
This is not important at the moment, since we do not yet need to convert svg
to svgz, I only added the converter for completeness.
Although the fix affects only a content of a LyX note, it is
still surprising to get a dialog-window demanding creation
a new document if trying to edit the subdocument.
Now that 5mu are added on each side of : (because it is a relation), there is no need to do the same in the definition of \vcentcolon.
This is closer to what is done in mathtools.sty.
Inset-icons are auto-scaled according to their width.
This is problematic, if converted from SVG
with the bounding box set to content (ignoring the page size)
and the content is not square.
OTOH, ignoring page size is done for good reasons - we usually want just
the drawing area when inserting an image into a document.
An invisible square with fixes this problem.
Some icons had spurious invisible elements outside the page -- leading
to too small results in the PDF. These were removed.
(#8738)
For efficiency, we add a new flag to the buffer indicating when changes are
present. This flag is updated at each buffer update, and also when explicitly
requested via a dispatch result flag.
The old text was incorrect and came from the 2.0 release. LyX works fine if
the default python interpreter is python 3, as long as python 2 is available
as well.
Building LyX does also work with python 3, but since I did not check all
special build steps with both cmake and autotools, I kept a note about
possible problems.
The aim of the tutorial is to explain how to use LyX and not special LaTeX issues with \frontmatter, non-TeX fonts etc. Therefore the preamble should kept clean.
We ensure that configure.py is called by python2, regardless whether 'python'
is python 2 or 3. Therefore we can simply call TeXFiles.py with the currently
running interpreter. This fixes configuration on systems where 'python' is
python 3.
The difference has been validated with diffpdf.
The following could not be tested and were left unchanged:
docbook_article.lyx
lilypond.lyx
linguistics.lyx
springer/sv*.lyx
de/linguistics.lyx
es/linguistics.lyx
ja/FeynmanDiagrams.lyx
ja/lilypond.lyx
ja/beamer.lyx
ja/xypic.lyx
The following is the script that I used (in lib/examples):
LYX=../../build/src/lyx
$LYX -E pdf2 $1.old.pdf $1
sed -i "s/^\\\\begin_inset Separator parbreak$/\\\\begin_inset Separator plain/" $1
sed -i "/^\\\\begin_inset Separator latexpar$/ { N; d; }" $1
$LYX -e lyx $1
$LYX -E pdf2 $1.pdf $1
diffpdf $1.old.pdf $1.pdf
The difference has been validated with diffpdf.
The following could not be tested and were left unchanged:
AEA.lyx
IJMPC.lyx
ja_beamer-conference-ornate-20min.lyx
The following is the script that I used (in lib/templates):
LYX=../../build/src/lyx
$LYX -E pdf2 $1.old.pdf $1
sed -i "s/^\\\\begin_inset Separator parbreak$/\\\\begin_inset Separator plain/" $1
sed -i "/^\\\\begin_inset Separator latexpar$/ { N; d; }" $1
$LYX -e lyx $1
$LYX -E pdf2 $1.pdf $1
diffpdf $1.old.pdf $1.pdf
We do not currently handle UTF-8 characters in our layout strings.
Replace dashes with simple ASCII dashes to avoid the following
error:
msguniq -o lyx.po
msguniq: input file '-' doesn't contain a header entry with a
charset specification
This commit amends the recent commit b4dcad83.
This was discussed in the thread "Translations of Math environments in LyX
output for LyX 2.2" at http://www.mail-archive.com/lyx-docs@lists.lyx.org/msg08633.html
and has been reviewed. The problem was that in 2.1, the portuguese translation
was correct in lib/layouttranslations but different in po/pt_PT.po. In fact,
the translation is the same for all three languages spanish, portuguese and
brazilian portuguese.
This is the same as the parbreak separator and is represented on screen
as the old parbreak. Old parbreak separators are converted to latexpar
separators when they are used for introducing blank lines in the
latex output rather than for separating environments.
Instead, parbreak separators are now represented on screen by a
double line. In essence, latexpar and parbreak separators produce
the same output but are represented differently on screen.
The context menu does not account for latexpar separators and only
"true" separators can be turned each into the other one.
After some discussion between Georger, Pedro, Pavel and me Georger came to the
conclusion that Mapa is not the correct translation of Chart in this context.
Originally he proposed Gráfico, but since that would be identical to the
translation of Graph we decided that Diagram is better. It is a bit more
general than Gráfico, but it is also used in pt_PT, and the german translation
uses the german equivalent, which is more general as well. Those who need a
Gráfico can still use Graph.
Unfortunately Geoger based the new .po file on the remerged one at
259196e1a6, so we have now the situation that pt_BR is remerged, but the
other languages are not.
These translations were changed implicitly at ad6ab20bb1: Previously, the
translations were taken from pt. At ad6ab20bb1 all pt_BR translations were
copied from pt_BR.po, so we do still need a review for those that differ from
pt_PT.
The term LongTable has been deprecated and moreover the renaming makes the interface easier to the eye.
File format updated to 507. (conversion based on jamatos patch)
Layout format updated to 60.
tex2ylx tests updated.
Document EmbeddedObjects.lyx has been updated.
