We allow png, jpg to channel through already existing tiff2ps (library
libtiff-tools). Other formats can be added if there is a request.
For future reference:
- using pnmtops seem to have issues with landscape/portrait flip, so
tiff2ps seems better alternative.
- using GraphicsMagick won't help because some distros ban postscript
processing directly in its code (e.g. openSUSE)
This patch finishes IM policy ban handling, we can't probably do much
better.
As of v. 2.23.12, the safe mode is no longer supported and results in
error.
We thus remove the -safe flags from the converter and use our own
needauth flag instead.
Some distros banned GS for Imagemigick conversions.
In effect eps->png conversion is broken and this can't
be fixed locally by the user.
Our workaround is to allow eps->pdf->png conversion from
different tools when IM bans the conversion.
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg217834.html
There are several small parts that are needed here:
* Implement LayoutModuleList::asString() that returns a comma-separated
list of modules.
* in Converter::convert(), handle the new tokens $$c for the current
textclass and $$m for the list of modules.
* in Buffer::importFile(), pass the current buffer as parameter instead
of nullptr.
* in pasteClipboardText(), copy the parameters of the current buffer to
the internal one used for importation, so that the textclass and
modules information is available to convert().
* finally, modify configure.py to pass "-c $$c -m $$m" to tex2lyx for
the latexclipoard->lyx converter.
Fixes bug #11312.
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.
