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.
Some applications do not accept forward slashes, so call external viewers
and editors with backward slashes which is the usual convention under windows.
The check for a latex format is very fragile. Both libmagic and our
guessing from contents cannot distinguish the pstex and pdftex formats
used by the xfig external inset. Moreover, it may also happen that
lyx files are mistaken as latex ones. Thus, when the guessed format
is latex, the only solution is to give precedence to the format
determined by the file extension.
In this case I use a mutex, so the zip status of files is shared between
threads. This is possible because a deadlock can't happen, and it should give
better performance.
The magic library can detect the charset used by a file. While this
detection is not full proof, actually the library seems to be infallible
as regards the binary nature of a file. So, use libmagic for the detection
and fallback to the previous method if the library is not installed or
its database cannot be loaded.
If LyX does not know about a given file format, it may easily
happen that the format is recognized as "latex" and this causes
bug #9146. This patch limits the check for a latex format to
non-binary files. The strategy for deciding that a file has
binary content is the same as that adopted by the "less" program.
The Adobe EPS file format specification (TN-5002, currently available at
http://partners.adobe.com/public/developer/en/ps/5002.EPSF_Spec.pdf) specifies
a binary version of EPS files with integrated preview, sometimes also called
DOS EPS binary files. LyX 2.0 did recognize these files unreliably by
extension, but since f4eae12d they are misdetected as latex (bug #9146).
This change adds proper detection for these files using the officially
documented binary header.
The format entries should be sorted according to the culture selected for the
UI. This was not the case previously, resulting in unexpected sorting of small
and capital letters. This is now fixed by using the standard C function
strcoll(). Qt does only offer similar functionality in Qt5, and this is not
mature enough yet to depend on it.
Unfortunately we have a report that strcoll() does not work on MSVC, however
this partial fix is better than nothing. The MSVC issue might also be a
configuration problem, since MS claims that strcoll() is supported. This
still needs to be checked.
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.
Thanks to Benjamin Piwowarski who reported the problem and provided a fix.
magic_file() returns a NULL pointer if an error occurs, and due to a bug
this happens frequently on OS X: https://trac.macports.org/ticket/38771
I did not use the original patch, since I did not want to put a platform
specific workaround in (this needs further discussion), but the crash can
occur on all platforms and needs to be fixed.
We only need to sort the formats when it is really necessary, i.e. for GUI
purposes.
This also prevents 11000 requests for translation everytime the toolbars
are updated.
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.
Caching the string value of extensions is not necessary. It
was a nice textbook exercise in getter/setter methods but it
is cause for confusion and prone to mistakes in maintenance.
Also, extension_list_ doesn't need to be mutable.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39714 a592a061-630c-0410-9148-cb99ea01b6c8
They were implementation-specific and do not impact on the interface anyway.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39709 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
Additionnal extensions are separated by commas (,) in lyxrc
preference files, while spaces are ignored, e.g. "jpg, jpeg".
Preference lyxrc file format incremented to 2.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39670 a592a061-630c-0410-9148-cb99ea01b6c8
and invoke the previewer with only its filename without the path.
This solves the problem about forward search on Windows reported here:
http://thread.gmane.org/gmane.editors.lyx.general/71130
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39410 a592a061-630c-0410-9148-cb99ea01b6c8
variable. This is done in the preferences, much like as the PATH prefix.
A single '.' in the paths will get replaced with the current document dir
and also non-absolute paths will be prefixed with that dir.
The default semantics of TEXINPUTS apply, such that, for example, if a
path is terminated with a double slash, all subdirectories will be also
searched by both the TeX engine and ancillary programs such as dvi
previewers or dvips. As an example, if the prefix is set to ".:figs", the
TEXINPUTS variable will be set as ".:<docdir>:<docdir>/figs:$ORIGTEXINPUTS",
where <docdir> is the document directory.
The initial '.' is necessary to address the actual current dir (this will
be the temp dir at preview time), while if TEXINPUTS was initially unset,
such that $ORIGTEXINPUTS is empty, a colon (or semicolon on Windows) will
end the path list. This is very important, because we don't want to replace
the system directories but to complement them and, in order to do that, an
empty element has to be present in the list. Indeed, according to the
TEXINPUTS semantics, an empty element means the standard search path.
This works whether TEXINPUTS is originally set or not, because if the
original TEXINPUTS starts with a colon (meaning that the standard search
path is wanted there) we will have an empty element at that point,
otherwise the final colon will simply serve as a path separator.
Of course, on Windows a ';' has to be used as a path separator. LyX will
take care of transforming the platform path list into one understandable
by the TeX engine. For example, this will be the case for a Cygwin version
of LyX using a native Windows TeX engine or viceversa. I tested all of
this and it works for me.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38681 a592a061-630c-0410-9148-cb99ea01b6c8
documents and graphics were not copied to the export directory, since
the format passed to addExternalFile() was wrong.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@38378 a592a061-630c-0410-9148-cb99ea01b6c8
risk, due to our lack of control over the links and the program used to
view them.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36789 a592a061-630c-0410-9148-cb99ea01b6c8
- (paperSizeName): add missing paper sizes. Add an argument to the function
that returns context-sensitive information (depending on the purpose)
- (paperSizeName): Do not hardcode "letter" for default paper size (bug 2098).
- (dvips_options): pass purpose DVIPS to paperSizeName
* src/Converter.cpp:
- (dvipdfm_options): pass purpose DVIPDFM to paperSizeName.
* src/Format.cpp:
- (view): pass purpose XDVI to paperSizeName (fix bug 4432).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@22664 a592a061-630c-0410-9148-cb99ea01b6c8
