Issue discussed in the mailing list: when the EPS contains several images (Adobe Photoshop exports two of them, one being a low-quality TIFF for preview), two files are generated, none with the existing name (prefix: -0 and -1). Hence, LyX thought that there was an error.
This ensures that we use a consistent Python interpreter in LyX.
$${python} is replaced by the Python version found.
Users can apply this in preferences and use the same version defined by
LyX.
The main problem is that, while lilypond.exe exists, there is not lilypond-book.exe: the previous calls always failed, even though the file was there, just not called the right way.
Private message by Michal Hoftich (tex4ht head developer):
oolatex is not recommended way to use Tex4ht for the ODT conversion.
It is better to use
make4ht -f odt mwe.tex
make4ht fixes some issues in ODT files
This is candidate for stable.
This is only relevant on linux/unix if running the scripts from a shell.
These two were the last where the call still used an unversioned python.
This has no reflex on the way that lyx calls the scripts or the python
version used since the #! "shebang line" is ignored.
In cooperation with Thibaut Cuvelier:
lib/scripts/spreadsheet_to_docbook.py: Strip the document header and convert some flags
lib/xtemplates/gnumeric.xtemplate: use this output to be inserted in docbook5
lib/configure.py: Add needed conversion entries
Preparation to test docbook5 exports
'xhtml_table': Format used for inserting spreadsheet tables in docbook
'pdf9': Result format used by conversion docbook5 with pandoc to create a pdf
If the modules are not in utf8 then we warn and skip that file
like it happens for layout files.
It would be nice in both cases to have a warn in the gui and not only in the config.log
This is a modern alternative for makeindex that is fully unicode-aware
and written in lua.
As opposed to xindy, it is more lightweight and actively maintained.
The program is still in a rather early stage of development, so we do
not propose this as default.
This relies on xindex 0.22 (about to be released) to function properly.
I did not realize when I added this that it would mean that ALL
files detected as text/html would be handled this way.
Should fix#11087. But it is the right thing to do anyway.
By default, the behavior is the same as before, except that the
language of new document is not unconditionally en_US anymore.
The new checkbox "Respect OS keyboard language" (off by default)
governs this behavior.
Update prefs format to 30.
