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.
A static local variable is guaranteed to be initialized only once, and in time.
Lambda expressions can be used to perform complex initialization of those static
variables on the spot.
(starting from: gcc >= 4.8, msvc >= 2015)
Boost.Signals is deprecated. This fixes bug #9943.
The only thing left to do is to rewrite (or get rid of) the boost -mt test
in config/lyxinclude.m4 not to use signals anymore.
The \jobname macro is redefined for the preview snippets such that
it contains the name of the document without extension. This is
harmless because the moment it is redefined, TeX has already chosen
the name of the output and log files. On the other hand, any use
of \jobname in preview snippets is now consistent with what one
obtains after exporting and compiling by hand.
This was a regression of 0c093a6264. The crash was found by the tex2lyx
test case test-insets.tex: Running lyx -f main -e pdflatex test-insets.lyx.lyx
did crash. This is not a real fix, but will do for now since previews are not
needed in command line mode (I wonder why they are generated at all?) In the
long term, we need theApp() to return a console application in commandline
mode to eliminate the existing sifferences between export from GUI and
commandline.
We have been here before. The png files are generated, but then by the time we preview the document, they are gone. This is because (a) when the PreviewLoader for a Buffer is deleted, it removes all its previews and (b) we export in a clone, so that Buffer gets deleted before the preview is actually shown. So we need to check whether we are a preview for a clone before we delete anything.
This brings the external inset on par with the graphics insets as far as the
clipping option is concerned. The graphicxs package supports both: A bounding
box without units (which means that bp ia assumed), and a bounding box with
units, so we can simply output the values including the units.
If latex fails to generate any output, the forked process was not removed.
Now, if a snippet was changed a new one was started but, if also the zoom was
changed, things went awry because the 2 concurrent processes were asked to
process again the same snippet. Previously this would have simply caused a
waste of resources because the changed snippet would have not been regenerated.
Also reset the guard due to the early exit.
If the zoom factor is changed right while the previews are being
regenerated, the refreshPreviews() method is a no-op. So, reschedule
the refresh until everything is ready.
Relying on the fact that the timer is not active anymore does not
guarantee that the previews at the correct zoom are ready because
the regeneration process may take several seconds and during this
time the zoom factor may be changed again. So, we need an additional
guard for assuring that everything has settled down.
Until now the regeneration process was starting as soon as the zoom scale
factor was changed. This was causing some glitches, especially if the zoom
was changed by the mouse wheel, as on each change the process was started
again and again making zoom changes painful and causing races such that
one could end up with the text at some zoom factor and the previews at
another one. After this commit, the regeneration is started only after
the zoom factor has been stable for about 1 second. In this way, one can
use the mouse wheel for changing back and forth the zoom factor at own's
heart desire without any slow down due to the regeneration process running
in the background. For those using previews with numbered math equations,
a nice possibility for getting the equations correctly numbered in sequence
(after removing or adding an equation) is using the shortcuts Alt+ and Alt-
in rapid sequence (less than a second between the keystrokes). Previously,
this would have triggered twice the regeneration, but now only once.
The "save-as" part of the bug is fixed by extending the \textclass tag
such that, if a local layout file is used, its path relative to the
document directory is now stored together with the name. If a relative
path cannot be used, an absolute one is used but, in this case, the
document is not usable on a different platform.
The "copy" part is fixed by introducing a new \origin tag, which is
written when the file is saved. This tag stores the absolute path of
the document directory. If the document is manually copied to a
different location, the local layout file is retrivied by using
\origin (which is only updated on save).
This new tag may prove useful also for locating other files when the
document is manually moved to a different directory.
As in the original implementation the files needed for the layout
(for example, a latex class) had to be in the same directory as the
layout file, this directory has also to be added to TEXINPUTS.
Avoid that \newcommand[x] definitions of math macros are pushed multiple
times to the preview loader.
Redefinitions (via \renewcommand[x]) are properly handled.
The preview snippets are cached in a seemingly random order, such
that, when regenerating them on zoom, the math previews would be
numbered accordingly. Hence, we have to go through the insets to
get the correct order. This is a bit slower but unavoidable.
Sometimes, even compilable documents could not display preview
snippets. Previously the preview was computed only with help
of latex or xelatex.
This also fixes#9371
Imagemagick detects the inut file format based on contents. Therefore it does
not make sense that we prefix the to be converted file name with the extension
(assuming that the file extension matches the imagemagick format name). This
breaks formats where the extension used by LyX does not match the imagemagick
format name.
If a mask is missing, the TempFile class appends it to the filename.
This may be a problem with applications relying on the extension,
so explicitly add a mask.
Add display_pixel_ratio to buffer params to use it for displays with high resolution.
It holds the highest ratio between physical pixels and device-independent pixels of the LyX application.
Preview snippets will be generated using this value to get high resolution preview.
Add pixel_ratio to graphics params to use it for displays with high resolution.
It holds the ratio between physical pixels and device-independent pixels of the graphics.
build_script() was already threadsafe, since it used a TempFile, and the
counter was basically not needed, but the new solution makes this obvious
and has the additional advantage that TempFile constructs the real output
file, not a dummy without extension which is not needed.
FileName::tempName() created a new temp file name by using qt to create a
temporary file with a unique name, and then deleting that file and returning
the name. This was unsafe, since other processes or even other threads of the
running LyX could create files with the same name between deletion and then
using the temp name.
This is fixed by using the TempFile class instead. As a side effect, a few
cases where the temp files were not deleted after usage were fixed as well.
The only place that is still unsafe is createTmpDir().
This regression was introduced by me at 8b66f9ce. I did not take
into account that a call to a python script containing $$s is embedded
within a separate python script. Thus, when commandPrep() is called it
only sees the call to the outer python script, and does not see the
$$s contained in that python script. It therefore did not substitute
for it. This fix simply calls commandPrep() directly before writing
the embedded command.
Now the replacement is done in startScript(). In addition to making
the code cleaner and more consistent, this commit fixes a bug where
"$$s" was not replaced when "latex=" was specified in the extra flags
of a converter.
Note that the temporary fix at 731b8610 is reverted with this commit.
for possible thread conflicts, of the sort Georg resolved at
6a30211f. I have made static variables const where possible,
and marked cases that looked potentially problematic with the
comment:
// FIXME THREAD
Many of these definitely are vulnerable to concurrent access, such
as the static variables declared at the start of output_latex.cpp.
Suppose, e.g., we were outputting latex and also displaying the
source of a different document.
I'd appreciate it if others could grep for "FIXME THREAD" and see
if some of these are harmless, or what.
When calling the default converter (convert) we pass the format on the
command line. In LyX we have various pdf, pdf2, pdf3, etc. formats all
representing PDF. We need to strip to trailing digit in the format string
otherwise the format is not understood by convert.
each failure.
There are several places I was not sure what to do. These are marked
by comments beginning "LASSERT:" so they can be found easily. At the
moment, they are at:
Author.cpp:105: // LASSERT: What should we do here?
Author.cpp:121: // LASSERT: What should we do here?
Buffer.cpp:4525: // LASSERT: Is it safe to continue here, or should we just return?
Cursor.cpp:345: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:403: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:1143: // LASSERT: There have been several bugs around this code, that seem
CursorSlice.cpp:83: // LASSERT: This should only ever be called from an InsetMath.
CursorSlice.cpp:92: // LASSERT: This should only ever be called from an InsetMath.
LayoutFile.cpp:303: // LASSERT: Why would this fail?
Text.cpp:995: // LASSERT: Is it safe to continue here?
While exporting from the command-line, theApp() doesn't exist.
The colors foreground and background are only needed when
previewing, so ignore this during buffer export.
This replaces the fix in 4285b0b3 (Tommaso Cucinotta, 10-12-2012).
In this case, we do not need to pull in Qt dependencies.
This patch puts all projects into subfolders (at least for MSVS). In this
way, there is a better overview (especially if the number of test projects
will be increasing).
While cppcheck did not turn out any suspicious error messages, using
the "performance" flag highlighted several nitpicks in three categories
* do not use it++ for iterators, ++it is better
* do not use size() to test for emptyness, empty() is here
* do not use "const T" as a function parameter, "const & T" is better
I doubt that any of these is a real performance problem, but the code is cleaner anyway.
LyX fails to read the bounding box from an EPS file if it has
negative values. Adjusting the regex will overcome this problem.
Negative values do not pose big problems later on, but the GUI
doesn't handle it correctly yet (see bug #5718).
This is already supported in Converters::convert() and needed e.g. for
eps2->eps conversion.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40649 a592a061-630c-0410-9148-cb99ea01b6c8
This restores \input@path handling, which turns out to be necessary, as
the TEXINPUTS mechanism is not used with relative paths. It turns out
that both methods must be used, because \input@path does not work in all
cases (most notably with tikz).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39918 a592a061-630c-0410-9148-cb99ea01b6c8
Let's have this in trunk for testing. The real difference maker
when it comes to color is whether we use dvipng or ghostscript.
For dvipng:
- The color info is passed as command-line arguments.
- The tightpage option is not necessary, and since it adds
ps specials to the output, we shouldn't use it.
For ghostscript:
- The color info needs to be in the latex file.
- The foreground color is set for each preview inset.
- The background color is set by \pagecolor in the preamble,
which is understood by pdflatex, but ignored in dvips mode.
Thus dvips is handled with a ps special.
- The tightpage option is necessary to crop the images.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39797 a592a061-630c-0410-9148-cb99ea01b6c8
(e.g., compressed dia, odg, sxd, ...). These need to be marked via the "zipped=native" flag in the RC file.
The old 'dia' configuration is automatically updated (it used to be hardcoded in the code, now it is handled
via the flag).
See also http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg170974.html
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39705 a592a061-630c-0410-9148-cb99ea01b6c8
- Japanese is now handled by passing the option --latex=platex
to the standard lyxpreview script. This is done in PreviewLoader.
- Remove obsoleted file lyxpreview-platex2bitmap.py and the
corresponding lines in the configure script.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39659 a592a061-630c-0410-9148-cb99ea01b6c8
- Handle the preprocessing in the main lyxpreview script with the
command-line arguments --lilypond and --lilypond-book=exe.
- Remove the obsoleted file lyxpreview-lytex2bitmap.py and the
corresponding lines in configure.py.
Fix for the japanese preview still to come.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39658 a592a061-630c-0410-9148-cb99ea01b6c8
Add command-line arguments in a standard unix fashion, using getopt.
Usage: ./lyxpreview2bitmap.py <options> <input file>
Options:
-h, --help: Show this help screen and exit
--dpi=<res>: Resolution per inch (default: 128)
--png, --ppm: Select the output format (default: png)
--fg=<color>: Foreground color (default: black, ie '000000')
--bg=<color>: Background color (default: white, ie 'ffffff')
--latex=<exe>: Specify the executable for latex (default: latex)
The colors are hexadecimal strings, eg 'faf0e6'.
The changes to PreviewLoader.cpp break the preview of lilypond-book
and japanese files, but they will be handled in the next commits.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39657 a592a061-630c-0410-9148-cb99ea01b6c8
The PreviewLoader is created directly by Buffer on demand. The PreviewLoader cache was complex and unneeded because there is one and only one PreviewLoader per Buffer.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39276 a592a061-630c-0410-9148-cb99ea01b6c8
when latex fails with a preview. Fixes bug #7303 (IP fails with hyperref).
Patch by Ale with suggestions from Enrico
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38243 a592a061-630c-0410-9148-cb99ea01b6c8
- use pdflatex route for preview snippet generation if hyperref is used.
This works around a bug in hyperref and/or preview-latex via DVI route (bug #7303).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37696 a592a061-630c-0410-9148-cb99ea01b6c8
I guess this deserves to be sorted out better, because we are doing tricky things by deleted the object from itself.
Problem:
PreviewImage? has a member PreviewLoader?. PreviewImage::Impl::statusChanged() calls PreviewLoader::remove. PreviewLoader::Impl::remove removes a snippet from the cache. In the cache is a map of the snippet and a shared pointer to PreviewImage?. This means that removing the snippet from the cache, destroys the PreviewImage?. When we get back to PreviewImage::Impl::statusChanged() this will start to crash.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37681 a592a061-630c-0410-9148-cb99ea01b6c8
