Don't assume any encoding for the layout files and treat them in
the same way python 2 does. Thanks José for the idea.
This commit supersedes 50e21b71 and e19b2a71.
Biblatex can be used with Japanese, but then, biber (not pbibtex) should
be used as processor.
I this context, bring the jbibtex UI in line with bibtex, allowing for
a selection of alternatives.
Add common raster image viewing applications:
gwenview: KDE image viewer,
eog: Eye of Gnome, the Gnome default viewer,
xviewer: Eye of Gnome successor for MATE and Cinnamon,
ristretto: XFCE image viewer,
gpicview: LXDE image viewer,
lximage-qt: QXDE image viewer,
xdg-open: generic file handler
The problem with xdg-open is, that it calls the browser (firefox) as fallback. This is not good for DVI and PDF, but still better than an editor (Gimp) for raster images.
Kee Gimp as last option for viewing, and default choice for editing.
Place "notepad" at the end of the text editor selection list.
* Under Linux, notepad comes with the Windows emulator "wine"
but it is not a good choice for the default text editor.
* Most Windows users will not have the Linux programs
and not see any change.
* Windows users with the Windows version of "geany"
will see this (syntax highlighting) editor preferred over notepad by default.
'xed' is the 'gedit/plume' successor by Linux-Mint.
It inherits gedit's functionaly and adds a traditional UI matching the
XFCE, MATE and Cinnamon desktop environments.
See: https://de.wikipedia.org/wiki/X-Apps
'xreader' is the successor of 'evince' by Linux-Mint.
It inherits evince's functionaly and adds a traditional UI
matching the XFCE, MATE and Cinnamon desktop environments.
See: https://de.wikipedia.org/wiki/X-Apps
Addressing #10481.
This patch adds the new 'needauth' option for converters launching
external programs that are capable of running arbitrary code on behalf
of the user. These converters won't be run unless the user gives explicit
authorization, which is asked on-demand when the converter is about to
be run (question is not asked if the file is cached and calling the
converter is not needed).
The user prompt has a 3rd button so that he/she's not prompted again
for (any converter over) the same document (identified through
buffer->absFileName()).
Two preference options are added:
lyxrc.use_converter_needauth_forbidden disables any converter with
the 'needauth' option, which is meant to force user to an explicit
action via the preferences pane, before being able to use advanced
converters that can potentially bring security threats;
lyxrc.use_converter_needauth enables prompting the user for 'needauth'
converters, or bypasses the check if not enabled, falling back to the
previous behavior.
So, the first option is for maximum security, the second is for
maximum usability.
Based on Daniel Groger's work of five years ago, with minor changes
http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg169820.html
This extends the support for Xfig LaTeX + PDF to a more modern and
actively developed vector graphics editor. Embedded Objects manual
updated, also to include a workaround for an Inkscape 0.91 bug.
We do already have docx, but xlsx was missing. This is a separate format
because of the MIME type. nd because some users might need converters which
can only handle one format. Now the spreadsheet template does not hide the
fact anymore that it can deal with xlsx files as well.
After the fix at fe06ef0e, several converter chains to DVI
(dviluatex) were broken because they had previously gone through an
incorrect link in the chain.
This commit adds converters for the above formats to dviluatex and
fixes the following ctests:
export/examples/Literate_dvi3_texF
export/examples/Literate_dvi3_systemF
export/examples/knitr_dvi3_texF
export/examples/knitr_dvi3_systemF
export/examples/lilypond_dvi3_texF
export/examples/lilypond_dvi3_systemF
export/examples/noweb2lyx_dvi3_texF
export/examples/noweb2lyx_dvi3_systemF
export/examples/sweave_dvi3_texF
export/examples/sweave_dvi3_systemF
export/templates/RJournal_dvi3_texF
Although this a problem that only manifests itself on windows the change is general
and it works anywhere.
The major change is to change the file redirection > to -o the specifies the output file.
At the same time it makes the call to lyx2lyx less cryptic, e.g. to revert to the 1.3
format we have:
\converter lyx lyx13x "python -tt $$s/lyx2lyx/lyx2lyx -t 221 $$i > $$o" ""
now instead of
python -tt $$s/lyx2lyx/lyx2lyx -t 221 $$i > $$o
we use a call where the version to revert is explicit
python -tt $$s/lyx2lyx/lyx2lyx -V 1.3 -o $$o $$i
or we could write a longer, but more understandable form:
python -tt $$s/lyx2lyx/lyx2lyx --final_version 1.3 --output $$o $$i
FWIW I shuffled the order of the arguments just for the sake of readability,
to let $$i be the last argument.
The external templates requested conversion to these formats, but there was no
converter defined, so plain text export did fail, and there are no obvious ways
to create plain text representations for the files used by these templates.
Now we output the file name as for other templates and also the graphics inset.
This fixes bug #7135.
The external date inset was implemented as a demonstrator for external insets
in general. It was never intended for production code. Now that we have several
external insets defined we do not need the demonstrator anymore. This fixes
bugs #4398 and #9948.
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.
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.
Otherwise it could easily happen that the order is changed, since rsvg_convert
seems to be more picky about invalid files (see http://www.lyx.org/trac/ticket/9891)
* Omit commented-out lines
* Properly escape backslash
* Do not allow non-space chars after delaration
* Allow blanks before # comment character
Fixes: #9746
The path argument of checkProg* was added to the PATH list in a nested
loop such that the list doubles in size each time the loop is executed,
thus also slowing down detection of missing programs.
When closing a document with the cursor near an icon info inset, LyX
may crash on loading again the same document. This is most probably due
to the fact that compressed svg icons are first uncompressed to a
temporary file before being used. The temporary file is then deleted
but something still expects to find it in place. The exact circumstances
that lead to the crash are unknown, and maybe there is also a race entering
the picture here. However, a document that always leads to a crash can be
found attached here: http://article.gmane.org/gmane.editors.lyx.devel/154566
This commit does not fix the cause of the crash but rather avoids it.
As a bonus, the svg icons used by LyX are not uncompressed anymore before
being used, speeding up startup time. This is not a problem, because Qt
can deal with compressed svg images.
As discussed on the list, but I did not need to create two new pdf formats
since any given document either uses TeX fonts or not. For the same reason
I also added an additional converter to PDF (cropped).
The reason being the backslashes in the path. Note that escaping
does not work here because the path is being interpreted multiple
times (how many times I don't know) and that would be fragile.
For this same reason, the change is not limited to Windows.
This branch implements string-wise metrics computation. The goal is to
have both good metrics computation (and font with proper kerning and
ligatures) and better performance than what we have with
force_paint_single_char. Moreover there has been some code
factorization in TextMetrics, where the same row-breaking algorithm
was basically implemented 3 times.
Globally, the new code is a bit shorter than the existing one, and it
is much cleaner. There is still a lot of potential for code removal,
especially in the RowPainter, which should be rewritten to use the new
Row information.
The bugs fixed and caused by this branch are tracked at ticket #9003:
http://www.lyx.org/trac/ticket/9003
What is done:
* Make TextMetrics methods operate on Row objects: breakRow and
setRowHeight instead of rowBreakPoint and rowHeight.
* Change breakRow operation to operate at strings level to compute
metrics The list of elements is stored in the row object in visual
ordering, not logical. This will eventually allow to get rid of the
Bidi class.
* rename getColumnNearX to getPosNearX (and change code accordingly).
It does not make sense to return a position relative to the start of
row, since nobody needs this.
* Re-implement cursorX and getPosNearX using row elements.
* Get rid of lyxrc.force_paint_single_char. This was a workaround that
is not necessary anymore.
* Implement proper string metrics computation (with cache). Remove
useless workarounds which disable kerning and ligatures.
* Draw also RtL text string-wise. This speeds-up drawing.
* Do not cut strings at selection boundary in RowPainter. This avoids
ligature/kerning breaking in latin text, and bad rendering problems
in Arabic.
* Remove homebrew Arabic and Hebrew support from Encoding.cpp. We now
rely on Qt to do handle complex scripts.
* Get rid of LyXRC::rtl_support, which does not have a real use case.
* Fix display of [] and {} delimiters in Arabic scripts.
For Windows: AcroRd32 and gsview (both 32 and 64 bit versions).
For Unix: qpdfview.
Qpdfview is a nice alternative to Okular for KDE users and a superior
alternative to Evince for Gnome users, due to its complete synctex
support. It only depends on Qt libraries for the graphical interface.
This variable was introduced to guard against any bad consequence of the then-new right-to-left
languages support. Let's be bold and get rid of it altogether!
Now right to left support is always enabled.
It currently does not make a difference that it is before
Adobe Reader in configure.py because as Enrico points out
on Windows the default viewer configured in the OS is used.
If we call tex2lyx on a temporary file created from the clipboard, the
file is always in utf8 encoding, without any temporary changes, even if it
contains encoding changing LaTeX commands. Therefore, we must tell tex2lyx
to use a fixed utf8 encoding for the whole file, and this is done using the
new latexclipboard format. Previously, tex2lyx thought the encoding was
latin1.
As a side effect, the -e option is now also documented in the man page.
With LyX configured in this way, the user would only need to:
File > New from Template > EPS.lyx (or PDF-cropped.lyx):
- insert a math inset and type in an equation, or create whatever
content LaTeX can handle,
- view/export to cropped EPS/PDF.
This would allow for LyX to act as a "generator for includable graphics" (equations, commented graphics, etc).
This fixes bug #7839.
If you have an unmounted dir, ac_dir, in your PATH, the call to
os.path.isfile( os.path.join(ac_dir, ac_word + ext) )
hangs. This is probably a python bug, but the result of configure.py
hanging and LyX freezing is really bad, hence this workaround.
According to the python docs, MacOS doesn't provide os.access();
the hasattr protection is used for this reason.
ps2pdf by default produces the PDF 1.4 format. The PDF 1.3 format was
released in 2000. PDF 1.4 was released in 2001. LyX specified 1.3 as
the output version in 2002 (c1541c22), perhaps because at the time
PDF 1.4 was only a year old so some viewers did not support it.
When using CMake, the binary files are stored in <build-dir>/bin. LyX can't fin tex2lyx with the current code. So, we have to point configure.py to explicitly look in the binary dir.
Before, the converter chain for DocBook -> PDF (ps2pdf) was:
docbook -> DVI
DVI -> Postscript
Postscript -> PDF (ps2pdf)
sgmltools has a backend for PostScript so the first two
steps in the above converter chain are now condensed into
one by adding the following converter for docbook -> Postscript:
sgmltools -b ps $$i
gnuhtml2latex does not handle encodings at all. Therefore the result is not
imported correctly by tex2lyx if the HTML file is encoded in anything else
than ascii or latin1 (the default of tex2lyx). The simple wrapper script
loads inputenc if needed. It may not be possible to compile the result with
LaTeX, (e.gif utf8 is used), but for running tex2lyx it will work just fine.
If you do not explicitly specify the output file name, gnuhtml2latex will
guess a file name itself. The result of the guess is not what we expect if
the input file name did not contain a .html extension, but something which
is not related to a format, e.g. .qV9984 from FileName::tempName().
Previously, the format used for included pdf files was the same as for
document export via ps2pdf. This caused unwanted conversion routes, e.g.
export via odt->pdf instead of dvi->ps->pdf.
I renamed the format for included graphics and not for exported documents,
since otherwise the command line syntax for export would change. This would
require more adaptions for the users, since with the chosen solution the
custom converters are almost always changed correctly in prefs2prefs(),
so that only custom external templates need manual adjustement.
