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
for any other sort of image for which we produce a preview on export,
e.g., eventually, for InsetExternal).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35032 a592a061-630c-0410-9148-cb99ea01b6c8
Buffer whether we are exporting or not, rather than rely upon isClone(),
which could be adapted to other purposes. And, of course, someone might
choose locally to disable cloning....
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34999 a592a061-630c-0410-9148-cb99ea01b6c8
allow this as a fallback. E.g., if we're unable to export as MathML,
then we try to export as an image.
There are several ways, I am sure, in which this implementation is not
ideal.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34993 a592a061-630c-0410-9148-cb99ea01b6c8
Solution: don't use boost::shared_ptr for msvc10 (could also be extended to several GCC versions)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34259 a592a061-630c-0410-9148-cb99ea01b6c8
Solution: don't use boost::bind for msvc10 (could also be extended to several GCC versions)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34257 a592a061-630c-0410-9148-cb99ea01b6c8
- implement an UI to specify the size of InstantPreview images
- change the default size to 1.0 because we've got many complaints that the former default size of 0.9 was too low
Both changes fix#6176.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31425 a592a061-630c-0410-9148-cb99ea01b6c8
* CacheItem::Impl::tryDisplayFormat
- Enhance description of the return value.
- Negate the return values to match the description.
* CacheItem::tryDisplayFormat
- Impl::tryDisplayFormat returns whether a conversion is needed, not whether the try was successful. Therefore, we should check the status as well.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@28754 a592a061-630c-0410-9148-cb99ea01b6c8
- switch to QImage backend instead of QPixmap. In any case this was done internally by Qt for any image loading or transformation. This should relieve the X11 server a bit for big images.
- try to clear out the memory after a transformation by calling QImage::detach(). Unfortunately there seems to be a bug somewhere in Qt... see (http://bugzilla.lyx.org/show_bug.cgi?id=5002).
* GraphicsImage: get rid of scaledDimension()
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@26455 a592a061-630c-0410-9148-cb99ea01b6c8
