Re: ImageMagick
On 5/15/26 8:40 AM, Jürgen Spitzmüller wrote: Am Freitag, dem 15.05.2026 um 13:06 +0200 schrieb Jürgen Spitzmüller: Am Freitag, dem 15.05.2026 um 12:54 +0200 schrieb Jürgen Spitzmüller: See attached patch. Or rather this. I tested more and since it works well (and the conversion is really fast, too), I committed to master. I propose to backport this. OK. Riki -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Freitag, dem 15.05.2026 um 13:06 +0200 schrieb Jürgen Spitzmüller: > Am Freitag, dem 15.05.2026 um 12:54 +0200 schrieb Jürgen Spitzmüller: > > See attached patch. > > Or rather this. I tested more and since it works well (and the conversion is really fast, too), I committed to master. I propose to backport this. -- Jürgen -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Freitag, dem 15.05.2026 um 12:54 +0200 schrieb Jürgen Spitzmüller:
> See attached patch.
Or rather this.
--
Jürgen
diff --git a/lib/configure.py b/lib/configure.py
index 8561a51b7f..bad14f34c2 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -1247,12 +1247,39 @@ def checkConverterEntries():
removeFiles(['mock.eps'])
#needs empty record otherwise default converter will be issued
addToRC(r'''\converter epspng"" ""
-\converter pngeps"" ""
\converter jpgtiff"convert $$i $$o" ""
\converter pngtiff"convert $$i $$o" ""''')
logger.info('ImageMagick seems to ban conversions from EPS. Disabling direct EPS->PNG.')
pdftopng.append('pdftoppm -r 72 -png -singlefile $$i > $$o')
#
+# Same for png to eps
+_, cmd = checkProg('a PNG -> EPS converter', ['magick', 'convert'])
+have_png2eps = False
+if cmd:
+from PIL import Image
+img = Image.new('RGB', (5, 5))
+img.save("mock.png", "PNG")
+try:
+subprocess.check_call([cmd, "mock.png", "mock.eps"])
+removeFiles(['mock.eps', 'mock.png'])
+rc_entry = r'\converter pngeps"%s $$i[0] $$o" ""'
+addToRC(rc_entry % cmd)
+have_png2eps = True
+except:
+removeFiles(['mock.png'])
+#needs empty record otherwise default converter will be issued
+addToRC(r'''\converter pngeps"" ""''')
+logger.info('ImageMagick seems to ban conversions to EPS. Disabling direct PNG->EPS.')
+
+if not have_png2eps:
+#try inkscape instead.
+if inkscape_stable:
+checkProg('an alternative PNG -> EPS converter', [inkscape_cl + ' $$i --export-area-drawing --export-filename=$$o'],
+rc_entry = [ r'\converter pngeps"%%" ""'])
+else:
+checkProg('an alternative PNG -> EPS converter', [inkscape_cl + ' --file=$$i --export-area-drawing --without-gui --export-eps=$$o'],
+rc_entry = [ r'\converter pngeps"%%" ""'])
+#
# PDF -> PNG: sips (mac), IM convert (windows, linux), pdftoppm (linux with IM ban)
# sips:Define a converter from pdf6 to png for Macs where pdftops is missing.
# The converter utility sips allows to force the dimensions of the resulting
--
lyx-devel mailing list
[email protected]
https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Freitag, dem 15.05.2026 um 12:38 +0200 schrieb Pavel Sanda:
> My worry is about the document containing png figure being exported
> to pdf. I didn't inspect the current code, but assume that the
> conversion of the figure is done by IM. Adding explicit img2pdf
> might overload it and create slightly different output for users
> with normally functional IM.
>
> If my assumption is not correct feel free to dismiss my previous
> email...
I didn't check that, but meanwhile it turned out that img2pdf is
probably not very reliable. The tests regularly stall.
I have tried now to use inkscape for png->eps and this works better.
See attached patch.
--
Jürgen
diff --git a/lib/configure.py b/lib/configure.py
index 8561a51b7f..d2df759981 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -1247,12 +1247,35 @@ def checkConverterEntries():
removeFiles(['mock.eps'])
#needs empty record otherwise default converter will be issued
addToRC(r'''\converter epspng"" ""
-\converter pngeps"" ""
\converter jpgtiff"convert $$i $$o" ""
\converter pngtiff"convert $$i $$o" ""''')
logger.info('ImageMagick seems to ban conversions from EPS. Disabling direct EPS->PNG.')
pdftopng.append('pdftoppm -r 72 -png -singlefile $$i > $$o')
#
+# Same for eps to png
+_, cmd = checkProg('a PNG -> EPS converter', ['magick', 'convert'])
+if cmd:
+from PIL import Image
+img = Image.new('RGB', (5, 5))
+img.save("mock.png", "PNG")
+try:
+subprocess.check_call([cmd, "mock.png", "mock.eps"])
+removeFiles(['mock.eps', 'mock.png'])
+rc_entry = r'\converter pngeps"%s $$i[0] $$o" ""'
+addToRC(rc_entry % cmd)
+except:
+removeFiles(['mock.png'])
+#needs empty record otherwise default converter will be issued
+addToRC(r'''\converter pngeps"" ""''')
+logger.info('ImageMagick seems to ban conversions to EPS. Disabling direct PNG->EPS.')
+#try inkscape instead.
+if inkscape_stable:
+checkProg('a PNG -> EPS converter', [inkscape_cl + ' $$i --export-area-drawing --export-filename=$$o'],
+rc_entry = [ r'\converter pngeps"%%" ""'])
+else:
+checkProg('a PNG -> EPS converter', [inkscape_cl + ' --file=$$i --export-area-drawing --without-gui --export-eps=$$o'],
+rc_entry = [ r'\converter pngeps"%%" ""'])
+#
# PDF -> PNG: sips (mac), IM convert (windows, linux), pdftoppm (linux with IM ban)
# sips:Define a converter from pdf6 to png for Macs where pdftops is missing.
# The converter utility sips allows to force the dimensions of the resulting
--
lyx-devel mailing list
[email protected]
https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Fri, May 15, 2026 at 11:53:28AM +0200, Jürgen Spitzmüller wrote: > Am Freitag, dem 15.05.2026 um 09:13 +0200 schrieb Pavel Sanda: > > Would you mind moving img2pdf into the except clause? > > Sure. > > > This is creating new default route for pure pdf export. > > What do you mean, "default route"? This would need to be fixed. My worry is about the document containing png figure being exported to pdf. I didn't inspect the current code, but assume that the conversion of the figure is done by IM. Adding explicit img2pdf might overload it and create slightly different output for users with normally functional IM. If my assumption is not correct feel free to dismiss my previous email... Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Freitag, dem 15.05.2026 um 09:13 +0200 schrieb Pavel Sanda: > Would you mind moving img2pdf into the except clause? Sure. > This is creating new default route for pure pdf export. What do you mean, "default route"? This would need to be fixed. -- Jürgen -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Thu, May 14, 2026 at 03:19:37PM +0200, Jürgen Spitzmüller wrote: > Am Donnerstag, dem 14.05.2026 um 12:30 +0200 schrieb Pavel Sanda: > > Yes, exactly. Pavel > > Like the attached? Would you mind moving img2pdf into the except clause? This is creating new default route for pure pdf export. Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Donnerstag, dem 14.05.2026 um 12:30 +0200 schrieb Pavel Sanda:
> Yes, exactly. Pavel
Like the attached?
--
Jürgen
diff --git a/lib/configure.py b/lib/configure.py
index 8561a51b7f..7b97b955b6 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -1247,12 +1247,30 @@ def checkConverterEntries():
removeFiles(['mock.eps'])
#needs empty record otherwise default converter will be issued
addToRC(r'''\converter epspng"" ""
-\converter pngeps"" ""
\converter jpgtiff"convert $$i $$o" ""
\converter pngtiff"convert $$i $$o" ""''')
logger.info('ImageMagick seems to ban conversions from EPS. Disabling direct EPS->PNG.')
pdftopng.append('pdftoppm -r 72 -png -singlefile $$i > $$o')
#
+# Same for eps to png
+_, cmd = checkProg('a PNG -> EPS converter', ['magick', 'convert'])
+if cmd:
+from PIL import Image
+img = Image.new('RGB', (5, 5))
+img.save("mock.png", "PNG")
+try:
+subprocess.check_call([cmd, "mock.png", "mock.eps"])
+removeFiles(['mock.eps', 'mock.png'])
+rc_entry = r'\converter pngeps"%s $$i[0] $$o" ""'
+addToRC(rc_entry % cmd)
+except:
+removeFiles(['mock.png'])
+#needs empty record otherwise default converter will be issued
+addToRC(r'''\converter pngeps"" ""
+\converter jpgtiff"convert $$i $$o" ""
+\converter pngtiff"convert $$i $$o" ""''')
+logger.info('ImageMagick seems to ban conversions to EPS. Disabling direct PNG->EPS.')
+#
# PDF -> PNG: sips (mac), IM convert (windows, linux), pdftoppm (linux with IM ban)
# sips:Define a converter from pdf6 to png for Macs where pdftops is missing.
# The converter utility sips allows to force the dimensions of the resulting
@@ -1263,6 +1281,9 @@ def checkConverterEntries():
#pdftoppm: Some systems ban IM eps->png conversion. We will offer eps->pdf->png route instead.
checkProg('a PDF to PNG converter', pdftopng,
rc_entry = [ r'\converter pdf6png"%%" ""' ])
+#img2pdf: Some systems ban IM png->eps conversion. We will offer png->pdf->eps route instead.
+checkProg('a PNG to PDF converter', ['img2pdf'],
+rc_entry = [ r'\converter pngpdf6"%%" ""' ])
#
# no agr -> pdf6 converter, since the pdf library used by gracebat is not
--
lyx-devel mailing list
[email protected]
https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Thu, May 14, 2026 at 12:22:09PM +0200, Jürgen Spitzmüller wrote: > Am Donnerstag, dem 14.05.2026 um 11:59 +0200 schrieb Pavel Sanda: > > But then we are at the same hole, no? If IM available but it's > > delegate is banned, configure will pick IM, but the conversion itself > > will fail later. > > Currently we do not check for a png->eps converter at all. I propose we > should do this (for magick), add a test for png->eps as we do for eps- > >png (configure.py:1235ff.) and add the converter only if this succeeds > (analogouos to png->eps). > > This way, IM should be used if available and permitted, otherwise the > more complex route via pdf. Yes, exactly. Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Donnerstag, dem 14.05.2026 um 11:59 +0200 schrieb Pavel Sanda: > But then we are at the same hole, no? If IM available but it's > delegate is banned, configure will pick IM, but the conversion itself > will fail later. Currently we do not check for a png->eps converter at all. I propose we should do this (for magick), add a test for png->eps as we do for eps- >png (configure.py:1235ff.) and add the converter only if this succeeds (analogouos to png->eps). This way, IM should be used if available and permitted, otherwise the more complex route via pdf. -- Jürgen -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Thu, 2026-05-14 at 11:59 +0200, Pavel Sanda wrote: > But then we are at the same hole, no? If IM available but it's delegate > is banned, configure will pick IM, but the conversion itself will fail later. > > Pavel Unless I am misunderstanding the issue, my suggestion was to check that the delegate is not banned by, for example, attempting a given minimal conversion. We can change configure as well. -- José Abílio -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Thu, May 14, 2026 at 11:46:42AM +0200, Jürgen Spitzmüller wrote: > Am Donnerstag, dem 14.05.2026 um 11:12 +0200 schrieb Pavel Sanda: > > Is the implication that on any machine having img2pdf installed > > we prefer it over IM's convert (even if IM is functional?). > > I haven't tried, buit I would assume IM would be preferred if available > anyway (since this chain has less nodes). But then we are at the same hole, no? If IM available but it's delegate is banned, configure will pick IM, but the conversion itself will fail later. Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Donnerstag, dem 14.05.2026 um 11:12 +0200 schrieb Pavel Sanda: > Is the implication that on any machine having img2pdf installed > we prefer it over IM's convert (even if IM is functional?). I haven't tried, buit I would assume IM would be preferred if available anyway (since this chain has less nodes). -- Jürgen -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Thu, May 14, 2026 at 10:44:58AM +0200, Jürgen Spitzmüller wrote: > IIRC convertDefault.py is only called if no converted is available from > prefs, right? Sounds correct. > From Pavel's suggested approach 3, only a png to pdf chain (img2pdf) is > missing. > > If I add to prefs > > \converter "png" "pdf6" "img2pdf -o $$o $$i" "" > > conversion of the problematic files to DVI works again, and the > converted graphics are actually of very good quality. Good news then. > So should we add a test for this converter to configure.py? Is the implication that on any machine having img2pdf installed we prefer it over IM's convert (even if IM is functional?). It might be better to check IM's functionality first and add this converter only IM is banned as we do for eps->png? Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Donnerstag, dem 14.05.2026 um 10:02 +0200 schrieb Pavel Sanda: > > I can look into it in the next week if this is the best way. > > We have explicit checks for banned IM eps->png delegate (but in > configure.py, > not convertDefault.py) which you might want to assimilate, check > bd0510b08ff6f. > > Putting the fallback directly into convertDefault.py might leave less > .log > traces to check the problems in users reports. IIRC convertDefault.py is only called if no converted is available from prefs, right? From Pavel's suggested approach 3, only a png to pdf chain (img2pdf) is missing. If I add to prefs \converter "png" "pdf6" "img2pdf -o $$o $$i" "" conversion of the problematic files to DVI works again, and the converted graphics are actually of very good quality. So should we add a test for this converter to configure.py? Letting convertDefault.py check for the ImageMagick policy is still a good idea. -- Jürgen -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Wed, May 13, 2026 at 05:58:38PM +0100, José Matos wrote: > On Wed, 2026-05-13 at 18:39 +0200, Jürgen Spitzmüller wrote: > > OK, can we implements these in convertDefault.py as alternative in case > > magick doesn't exist or permit conversion? > > Yes, we can. > > The basic idea is to use a fall through approach where we do some kind of test > and, if it fails, we go the next option. > > Without looking into the code I think that we just check for the program but > do > not ensure that the output is what is to be expected. > > I can look into it in the next week if this is the best way. We have explicit checks for banned IM eps->png delegate (but in configure.py, not convertDefault.py) which you might want to assimilate, check bd0510b08ff6f. Putting the fallback directly into convertDefault.py might leave less .log traces to check the problems in users reports. Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Wed, 2026-05-13 at 18:39 +0200, Jürgen Spitzmüller wrote: > OK, can we implements these in convertDefault.py as alternative in case > magick doesn't exist or permit conversion? Yes, we can. The basic idea is to use a fall through approach where we do some kind of test and, if it fails, we go the next option. Without looking into the code I think that we just check for the program but do not ensure that the output is what is to be expected. I can look into it in the next week if this is the best way. Best regards, -- José Abílio -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Dienstag, dem 12.05.2026 um 10:14 +0200 schrieb Pavel Sanda: > > For the DVI cases, png->eps > > a) oldschool: pngtopnm input.png | pnmtops -noturn > output.eps > b) canoon: gs -q -dNOPAUSE -dBATCH -sDEVICE=eps2write - > sOutputFile=output.eps input.png > c) via pdf: img2pdf input.png -o temp.pdf && pdftops -eps temp.pdf > output.eps > > I didn't the output wrt margins etc. OK, can we implements these in convertDefault.py as alternative in case magick doesn't exist or permit conversion? -- Jürgen -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Mon, May 11, 2026 at 06:31:57PM +0200, Jürgen Spitzmüller wrote: > Am Montag, dem 11.05.2026 um 09:44 +0200 schrieb Pavel Sanda: > > Which direction is more critical for you? > > For the DVI cases, png->eps a) oldschool: pngtopnm input.png | pnmtops -noturn > output.eps b) canoon: gs -q -dNOPAUSE -dBATCH -sDEVICE=eps2write -sOutputFile=output.eps input.png c) via pdf: img2pdf input.png -o temp.pdf && pdftops -eps temp.pdf output.eps I didn't the output wrt margins etc. Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Montag, dem 11.05.2026 um 09:44 +0200 schrieb Pavel Sanda: > Which direction is more critical for you? For the DVI cases, png->eps > eps->png can be solved by pdftoppm which will offer eps->pdf->png > route in case IM is banned. Good. > > We could ask your distro maintainer to include pdftoppm in > lyx dependencies if they decided to ban IM forever. -- Jürgen -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Mon, May 11, 2026 at 10:18:04AM +0200, Scott Kostyshak wrote: > On Mon, May 11, 2026 at 09:44:51AM +0200, Pavel Sanda wrote: > > > > What are the image file formats that we are trying to convert > > > > from/to? > > > > > > mainly eps <> png > > > > Which direction is more critical for you? > > > > eps->png can be solved by pdftoppm which will offer eps->pdf->png > > route in case IM is banned. > > > > We could ask your distro maintainer to include pdftoppm in > > lyx dependencies if they decided to ban IM forever. > > Can someone remind me when does eps -> png come up in practice? The one use I know is that you want preview of eps file in GUI. I am not sure whether it's useful to DVI production Juergen mentioned earlier. Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Mon, May 11, 2026 at 09:44:51AM +0200, Pavel Sanda wrote: > On Thu, May 07, 2026 at 05:14:13PM +0200, Jürgen Spitzmüller wrote: > > Am Donnerstag, dem 07.05.2026 um 11:02 -0400 schrieb Neal Becker: > > > What are the image file formats that we are trying to convert > > > from/to? > > > > mainly eps <> png > > Which direction is more critical for you? > > eps->png can be solved by pdftoppm which will offer eps->pdf->png > route in case IM is banned. > > We could ask your distro maintainer to include pdftoppm in > lyx dependencies if they decided to ban IM forever. Can someone remind me when does eps -> png come up in practice? Scott signature.asc Description: PGP signature -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Thu, May 07, 2026 at 05:14:13PM +0200, Jürgen Spitzmüller wrote: > Am Donnerstag, dem 07.05.2026 um 11:02 -0400 schrieb Neal Becker: > > What are the image file formats that we are trying to convert > > from/to? > > mainly eps <> png Which direction is more critical for you? eps->png can be solved by pdftoppm which will offer eps->pdf->png route in case IM is banned. We could ask your distro maintainer to include pdftoppm in lyx dependencies if they decided to ban IM forever. Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Donnerstag, dem 07.05.2026 um 11:02 -0400 schrieb Neal Becker: > What are the image file formats that we are trying to convert > from/to? mainly eps <> png -- Jürgen -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Thu, May 7, 2026 at 8:10 AM Jürgen Spitzmüller wrote: > Am Donnerstag, dem 07.05.2026 um 13:50 +0200 schrieb Pavel Sanda: > > If you have clear candidate for alternative convertor we can add it. > > No I don't. That's why I asked here! > > Sorry, haven't followed all the details. What are the image file formats that we are trying to convert from/to? -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Donnerstag, dem 07.05.2026 um 13:50 +0200 schrieb Pavel Sanda: > If you have clear candidate for alternative convertor we can add it. No I don't. That's why I asked here! -- Jürgen -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Thu, May 07, 2026 at 01:01:10PM +0200, Jürgen Spitzmüller wrote: > Am Mittwoch, dem 06.05.2026 um 22:19 +0200 schrieb Pavel Sanda: > > I am way more concerned if we add different conversion chain for > > producing dvi/eps/pdf output which would contextually switch > > depending on the config of your machine. That would produce different > > outputs without much warnings. > > But now it fails to produce any output at all. Is this better? I can argue in both ways and don't have that strong opinion. If you have clear candidate for alternative convertor we can add it. Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Mittwoch, dem 06.05.2026 um 22:19 +0200 schrieb Pavel Sanda: > I am way more concerned if we add different conversion chain for > producing dvi/eps/pdf output which would contextually switch > depending on the config of your machine. That would produce different > outputs without much warnings. But now it fails to produce any output at all. Is this better? -- Jürgen -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Wed, May 06, 2026 at 07:47:14AM +0200, Jürgen Spitzmüller wrote: > Am Dienstag, dem 05.05.2026 um 21:53 +0200 schrieb Pavel Sanda: > > Second option is to directly edit /etc/ImageMagick-7/policy.xml (or > > at similar location) and allow only the delegates of interest (in > > lyx's case that's mainly eps/pdf). That's what I used to do when IM > > policies were more strict (at that time triggered actually by > > ghostscript vulnerabilities). > > I can do that, but for users this is not a satisfactory situation. I am not sure I do have other satisfactory solution though. We have still place the machinery from the earlier case in configure.py, where we explicitely test whether IM delegate for eps conversion works and if not, we add new specific external convertor. The difference is that IIRC the eps->png chain banned earlier caused only problem for displaying stuff within LyX GUI - so if the new convertor produced slightly different result it was not big deal. I am way more concerned if we add different conversion chain for producing dvi/eps/pdf output which would contextually switch depending on the config of your machine. That would produce different outputs without much warnings. Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Dienstag, dem 05.05.2026 um 21:53 +0200 schrieb Pavel Sanda: > Second option is to directly edit /etc/ImageMagick-7/policy.xml (or > at similar location) and allow only the delegates of interest (in > lyx's case that's mainly eps/pdf). That's what I used to do when IM > policies were more strict (at that time triggered actually by > ghostscript vulnerabilities). I can do that, but for users this is not a satisfactory situation. -- Jürgen -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Tue, May 05, 2026 at 08:01:54PM +0200, Jürgen Spitzmüller wrote: > Am Dienstag, dem 05.05.2026 um 17:38 +0200 schrieb Pavel Sanda: > > On what distro and what exact conversion fails for you? > > OpenSuse Tumbleweed. > > PNG to EPS conversion fails here (and probably vice versa). > > > Different distros have different approaches how the deal with IM > > policies. > > For some time or pdf/eps/svg convertors were widely banned, then this > > relaxed little bit. It might be get more strict again, but as far as > > I could see on debian, they are nowadays rather trying fix large > > number of CVEs than killing the conversion delegates altogether. In > > any case it's not entirely new situation and you might need to > > personally relax IM policies on your computer to > > have full IM power. > > They provide five different policies. The only one that works for me is > the "open" policy, descibred as follows: > > "This policy is designed for usage in secure settings like those > protected by firewalls or within Docker containers." I see it's similar to debian open policy (I think that's still the default). I would expect that for server layouts for ubuntu and similar the strict version will be chosen. Second option is to directly edit /etc/ImageMagick-7/policy.xml (or at similar location) and allow only the delegates of interest (in lyx's case that's mainly eps/pdf). That's what I used to do when IM policies were more strict (at that time triggered actually by ghostscript vulnerabilities). Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Dienstag, dem 05.05.2026 um 17:38 +0200 schrieb Pavel Sanda: > On what distro and what exact conversion fails for you? OpenSuse Tumbleweed. PNG to EPS conversion fails here (and probably vice versa). > Different distros have different approaches how the deal with IM > policies. > For some time or pdf/eps/svg convertors were widely banned, then this > relaxed little bit. It might be get more strict again, but as far as > I could see on debian, they are nowadays rather trying fix large > number of CVEs than killing the conversion delegates altogether. In > any case it's not entirely new situation and you might need to > personally relax IM policies on your computer to > have full IM power. They provide five different policies. The only one that works for me is the "open" policy, descibred as follows: "This policy is designed for usage in secure settings like those protected by firewalls or within Docker containers." As said, this is a very recent policy change that was rolled out last week, and I understand this is in response to the recent vulnerability reports. -- Jürgen -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Mon, May 04, 2026 at 09:26:37PM +0200, Jürgen Spitzmüller wrote: > As a result, many of our tests via the DVI chain fail now. This can be > worked around by using less strict policies, but of course this is not > advisable. On what distro and what exact conversion fails for you? Different distros have different approaches how the deal with IM policies. For some time or pdf/eps/svg convertors were widely banned, then this relaxed little bit. It might be get more strict again, but as far as I could see on debian, they are nowadays rather trying fix large number of CVEs than killing the conversion delegates altogether. In any case it's not entirely new situation and you might need to personally relax IM policies on your computer to have full IM power. For alternatives - some convertors might be available in Qt, but I am pretty sure that if we are heading into turbulent time of AI discovering security holes en masse, Qt's handling of svg will be probably in the same swamp ;) I wouldn't like to be sysadmin in the forthcoming months. Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Jean-Marc Lasgouttes schrieb am 05.05.2026 13:29 (GMT +02:00): > It seems to me that convert is imagemagick and ghostscript is the > conduit used for the imagemagick attack. You're right. Jürgen -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Le 05/05/2026 à 09:40, Jürgen Spitzmüller a écrit : Kornel Benko schrieb am 05.05.2026 08:46 (GMT +02:00): You could overcome this by using $ prefTest.pl test from the build directory. This modifies the some converters in the local test-preferences. This does not work for me (I have this setting). Also, in the long term, I think we should try to get rif of ImageMagick if there are suitable alternatives (ghostscript? convert?). The problem also applies to real use. It seems to me that convert is imagemagick and ghostscript is the conduit used for the imagemagick attack. JMarc -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Kornel Benko schrieb am 05.05.2026 08:46 (GMT +02:00): > You could overcome this by using >$ prefTest.pl test > from the build directory. This modifies the some converters in the local > test-preferences. This does not work for me (I have this setting). Also, in the long term, I think we should try to get rif of ImageMagick if there are suitable alternatives (ghostscript? convert?). The problem also applies to real use. Jürgen > >Kornel > > >Kornel > > -- > lyx-devel mailing list > [email protected] > https://lists.lyx.org/mailman/listinfo/lyx-devel > -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
Am Mon, 4 May 2026 22:14:40 +0200 schrieb Scott Kostyshak : > On Mon, May 04, 2026 at 09:26:37PM +0200, Jürgen Spitzmüller wrote: > > Just a heads-up: > > > > In response to the recently discovered security issues in ImageMagick > > [1] distributions are tightening the policies. > > > > As a result, many of our tests via the DVI chain fail now. This can be > > worked around by using less strict policies, but of course this is not > > advisable. > > Thanks for the heads-up Jürgen! > > Scott You could overcome this by using $ prefTest.pl test from the build directory. This modifies the some converters in the local test-preferences. Kornel Kornel pgp66GKDoJ85Z.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick
On Mon, May 04, 2026 at 09:26:37PM +0200, Jürgen Spitzmüller wrote: > Just a heads-up: > > In response to the recently discovered security issues in ImageMagick > [1] distributions are tightening the policies. > > As a result, many of our tests via the DVI chain fail now. This can be > worked around by using less strict policies, but of course this is not > advisable. Thanks for the heads-up Jürgen! Scott signature.asc Description: PGP signature -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick security settings in openSUSE
On Sat, Oct 31, 2020 at 12:11:58AM +0100, Tommaso Cucinotta wrote: > Now, the question I wanted to ask is: when reconfiguring LyX looking for > existence of the various converters, would it make sense for LyX to have a > means to try the converters one by one (at least a known subset of them), to > be sure they work and they've not been forbidden, so to exclude those ones > that don't actually work ? > Or, is there some other way to handle the problem in a user-friendly way ? The security bugs which led to the conversion ban are fixed for a long time. So it would make sense to file a bug in ubuntu that the permanent ban makes lyx unusable for standard vector graphics formats. Moreover since /etc is writeable only for root, normal users has no chance to override this restriction with their own policy files. They might listen to us or not, but it's IMHO worth of trying. >From our part the most user informative way would be to check the policy via "convert -list policy" and if not trigger message that those conversions were banned. The combative part in me would even add note which would suggest users to file bug to their distro maintainers so they get some additional feedback. Maybe if they close the same bug 100x times they try to do something about it ;) Pavel -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick security settings in openSUSE
Hi, I'm not sure if the problem is similar, I've just tried LyX 2.3.4 on Ubuntu 20.04.1, and noticed that after inserting a PDF file/graphics, LyX has problems in converting the image into PNG, as needed to show the preview on-screen. One way I could work around it, was to comment out the PDF rule/filter in the security policy coming with ImageMagick 6: (not understanding yet the full implications of this, though) tommaso@laptom$ grep PDF /etc/ImageMagick-6/policy.xml Now, the question I wanted to ask is: when reconfiguring LyX looking for existence of the various converters, would it make sense for LyX to have a means to try the converters one by one (at least a known subset of them), to be sure they work and they've not been forbidden, so to exclude those ones that don't actually work ? Or, is there some other way to handle the problem in a user-friendly way ? FYI, the user perception of the issue shows up like this: tommaso@laptom$ lyx placement.lyx convert-im6.q16: attempt to perform an operation not allowed by the security policy `PS' @ error/constitute.c/IsCoderAuthorized/408. convert-im6.q16: no images defined `/tmp/lyx_tmpdir.pPGlFCzHmrqd/gconvertDiWwGs.png' @ error/convert.c/ConvertImageCommand/3258. and, in LyX, the generic error on the image "spot" saying "cannot convert". Thanks, T. On 03/07/19 15:43, Cor Blom wrote: Dear LyX devs, Because of the following bug https://bugzilla.opensuse.org/show_bug.cgi?id=1139928 I have become aware of the strict security settings in openSUSE which limits capabilities of ImageMagick. There is an alternative setting that the user can activate, but most users will not know this. I am just writing this, so you are aware of this. I don't know a solution. Regards, Cor -- lyx-devel mailing list [email protected] http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: ImageMagick security settings in openSUSE
Op 10-07-19 om 16:51 schreef Pavel Sanda: I'm not sure for how big percentage of userbase I speak of but to butcher postscript processing renders lyx quite unusable imho, so question is to whether suse wants lyx in its repositories at all if this does not work... So if it was on me would rather ask for removing lyx from your official repos and let only advanced users to fetch from alternative sources and tweak settings -- because delivering half non functional lyx just give us bad reputation. But again, that's due to my way of using lyx, don't take this as official lyx team stand point:) Personally I use LyX with openSUSE's hardened ImageMagick without any problems. I would not have noticed the issue with ImageMagick had it not been reported as a bug. I am not really afraid for the reputation of LyX. I think users who are confronted by this will blame (open)SUSE (or understand it). In the meantime I try to spread the information in different, relevant places, so that it can hopefully be found. Thanks for your input. Cor
Re: ImageMagick security settings in openSUSE
On Wed, Jul 10, 2019 at 08:58:58PM +0200, Cor Blom wrote: > Op 10-07-19 om 16:51 schreef Pavel Sanda: >> Can't you simply demand this 'alternative configuration' as dependency >> when lyx is installed? > > I can try this. The reason for this security policy has been explained to > me, so I have little hope. But who knows... Let's see. I can understand that you don't want any risk on a production server, but you don't want lyx there neither. > I have updated the wiki with the relevant information: > > https://wiki.lyx.org/LyX/LyXOnOpenSUSE > > It need the confirmation of a link. Confirmed. For now, Pavel
Re: ImageMagick security settings in openSUSE
Op 10-07-19 om 16:51 schreef Pavel Sanda: Can't you simply demand this 'alternative configuration' as dependency when lyx is installed? I can try this. The reason for this security policy has been explained to me, so I have little hope. But who knows... I have updated the wiki with the relevant information: https://wiki.lyx.org/LyX/LyXOnOpenSUSE It need the confirmation of a link. Thanks, Cor
Re: ImageMagick security settings in openSUSE
On Wed, Jul 10, 2019 at 03:47:26PM +0200, Cor Blom wrote: > The following message describes the situation for openSUSE Leap 15.0, but > it is also true for 15.1 and Tumbleweed: > > https://lists.opensuse.org/opensuse-security-announce/2019-05/msg00010.html > > In short: the user can install an alternative configuration for IM that > enables postscript related stuff (and other things), following upstream IM > setting. The default SUSE setting are very strict. Can't you simply demand this 'alternative configuration' as dependency when lyx is installed? I'm not sure for how big percentage of userbase I speak of but to butcher postscript processing renders lyx quite unusable imho, so question is to whether suse wants lyx in its repositories at all if this does not work... So if it was on me would rather ask for removing lyx from your official repos and let only advanced users to fetch from alternative sources and tweak settings -- because delivering half non functional lyx just give us bad reputation. But again, that's due to my way of using lyx, don't take this as official lyx team stand point :) > In general postscript does not work out of the box on openSUSE for security > reasons nowadays, but the user can enable this by installing additional > packages. > > I hope this give enough information. There is not much more that can be > done. Maybe this information can be added to the LyX wiki also? You can add there whatever feels right, no one understands suse+lyx situation better than you do. Pavel
Re: ImageMagick security settings in openSUSE
Op 10-07-19 om 15:30 schreef Pavel Sanda: On Wed, Jul 03, 2019 at 03:43:06PM +0200, Cor Blom wrote: Dear LyX devs, Because of the following bug https://bugzilla.opensuse.org/show_bug.cgi?id=1139928 I have become aware of the strict security settings in openSUSE which limits capabilities of ImageMagick. There is an alternative setting that the user can activate, but most users will not know this. Is this security measure sideeffect of ghostscript problems from last september? As far as I understood the total ban of conversions was just temporary measure which should be lifted once the individual CVEs were resolved. I believe both upstream and other distros already lifted it. I am just writing this, so you are aware of this. I don't know a solution. In decreasing order: - Can't you just file suse-related bug to remove the ban? - Can't you pull/set different IM config iff lyx is installed? - Can't you trigger some message if lyx is installed so user is at least know how to fix it. If nothing of this work, we could add some note to our release notes that users of open suse need to fix IM settings. Pavel The following message describes the situation for openSUSE Leap 15.0, but it is also true for 15.1 and Tumbleweed: https://lists.opensuse.org/opensuse-security-announce/2019-05/msg00010.html In short: the user can install an alternative configuration for IM that enables postscript related stuff (and other things), following upstream IM setting. The default SUSE setting are very strict. I have added a README.SUSE to the package and refer to that in the description that explains the situation and tells the user the options he has. It has been discussed on the openSUSE Factory mailinglist, but the suggestion how to inform users is what I have done. See: https://build.opensuse.org/request/show/713564 I came accross this because a bug was filed that eps preview was not working. This is not really my area of expertise. As far as I can see, the situation in (open)SUSE will remain as it is. This means the user either installs an alternative configuration for ImageMagick, or edits security pollicy settings for IM manually. In general postscript does not work out of the box on openSUSE for security reasons nowadays, but the user can enable this by installing additional packages. I hope this give enough information. There is not much more that can be done. Maybe this information can be added to the LyX wiki also? Kind regards, Cor
Re: ImageMagick security settings in openSUSE
On Wed, Jul 03, 2019 at 03:43:06PM +0200, Cor Blom wrote: > Dear LyX devs, > > Because of the following bug > > https://bugzilla.opensuse.org/show_bug.cgi?id=1139928 > > I have become aware of the strict security settings in openSUSE which > limits capabilities of ImageMagick. There is an alternative setting that > the user can activate, but most users will not know this. Is this security measure sideeffect of ghostscript problems from last september? As far as I understood the total ban of conversions was just temporary measure which should be lifted once the individual CVEs were resolved. I believe both upstream and other distros already lifted it. > I am just writing this, so you are aware of this. I don't know a solution. In decreasing order: - Can't you just file suse-related bug to remove the ban? - Can't you pull/set different IM config iff lyx is installed? - Can't you trigger some message if lyx is installed so user is at least know how to fix it. If nothing of this work, we could add some note to our release notes that users of open suse need to fix IM settings. Pavel
Re: Imagemagick might be banned from postscipt/pdf conversion soon on your distro too
Jürgen Spitzmüller wrote: > Am Sonntag, den 02.09.2018, 23:27 +0200 schrieb Pavel Sanda: > > These are pacthes for the vulns reported on Aug 21, but as the > > original report says: > > Yes, but it indicates that Artifex care and reacts swiftly. So no need > to declare ghostscript death (yet). I agree, we could just mention this problem in the 2.3.1 release news. Pavel
Re: Imagemagick might be banned from postscipt/pdf conversion soon on your distro too
Am Sonntag, den 02.09.2018, 23:27 +0200 schrieb Pavel Sanda: > These are pacthes for the vulns reported on Aug 21, but as the > original report says: Yes, but it indicates that Artifex care and reacts swiftly. So no need to declare ghostscript death (yet). Jürgen signature.asc Description: This is a digitally signed message part
Re: Imagemagick might be banned from postscipt/pdf conversion soon on your distro too
On 09/02/2018 05:27 PM, Pavel Sanda wrote: > Daniel wrote: >>> in policy.xml so they can continue their work. >>> In longer-term -- if this ban continues -- we might try to ask Qt to do >>> the >>> conversions instead of imagemagick, but that's is definitely not for >>> 2.3.1. >>> Other ideas? >>> Pavel >>> https://www.bleepingcomputer.com/news/security/no-patch-available-yet-for-new-major-vulnerability-in-ghostscript-interpreter/ >> There seems to be a patch for it already. >> >> https://artifex.com/news/ghostscript-security-resolved/ >> >> Hopefully distros will patch and go back to normal. > These are pacthes for the vulns reported on Aug 21, but as the original > report says: > > "These bugs were found manually, I also wrote a fuzzer and I'm working on > minimizing a very large number of testcases that I'm planning to report over > the next few days. I will just file those issues upstream and not post each > individual one here, you can monitor https://bugs.ghostscript.com/ if you > want to. I expect there to be several dozen unique bugs." > > So, not sure, we are already in the fixed state for what is coming. New bump > of ghostscript was announced to late Sept ASFAIK. I think removing the dependency on ImageMagick would be worth doing anyway, if it could be done reasonably. For 'exotic' conversions, maybe we would still need it, but surely Qt can handle most of what we need. Riki
Re: Imagemagick might be banned from postscipt/pdf conversion soon on your distro too
Daniel wrote: >> in policy.xml so they can continue their work. >> In longer-term -- if this ban continues -- we might try to ask Qt to do >> the >> conversions instead of imagemagick, but that's is definitely not for >> 2.3.1. >> Other ideas? >> Pavel >> https://www.bleepingcomputer.com/news/security/no-patch-available-yet-for-new-major-vulnerability-in-ghostscript-interpreter/ > > There seems to be a patch for it already. > > https://artifex.com/news/ghostscript-security-resolved/ > > Hopefully distros will patch and go back to normal. These are pacthes for the vulns reported on Aug 21, but as the original report says: "These bugs were found manually, I also wrote a fuzzer and I'm working on minimizing a very large number of testcases that I'm planning to report over the next few days. I will just file those issues upstream and not post each individual one here, you can monitor https://bugs.ghostscript.com/ if you want to. I expect there to be several dozen unique bugs." So, not sure, we are already in the fixed state for what is coming. New bump of ghostscript was announced to late Sept ASFAIK. Pavel
Re: Imagemagick might be banned from postscipt/pdf conversion soon on your distro too (was: 2.3.1 Binaries)
Am Sonntag, den 02.09.2018, 12:59 +0200 schrieb Pavel Sanda: > After the recent discovery of ghoscript vulnerabilities distributions > seem to > actually follow suggestion of the security researcher who announced > them > and broadly ban any conversions from ps/eps/pdf/xps in imagemagick no > matter > the consequences. I don't need to stress on this list what it means > for > LyX -- just from todays update of my distro I'm not capable to view > most > of my documents by default... > > Unfortuntaly there is very little we can directly for 2.3.1. > We should at least signalize in announcement for distro maintainers > that this *is* > issue and perhaps add some hint how to allow users to locally enable > things > in policy.xml so they can continue their work. > > In longer-term -- if this ban continues -- we might try to ask Qt to > do the > conversions instead of imagemagick, but that's is definitely not for > 2.3.1. The vulnerabilities have been resolved, so it seem to be a medium-term problem: https://artifex.com/news/ghostscript-security-resolved/ Jürgen > > Other ideas? > > Pavel > > https://www.bleepingcomputer.com/news/security/no-patch-available-yet-for-new-major-vulnerability-in-ghostscript-interpreter/ > signature.asc Description: This is a digitally signed message part
Re: Imagemagick might be banned from postscipt/pdf conversion soon on your distro too
On 02/09/2018 12:59, Pavel Sanda wrote: Richard Kimberly Heck wrote: Are available for testing at http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/. I suppose we should wait to prepare binaries until we have some feedback. Before we announce we might consider to issue new warning as part of release. Or even as a separate entry. After the recent discovery of ghoscript vulnerabilities distributions seem to actually follow suggestion of the security researcher who announced them and broadly ban any conversions from ps/eps/pdf/xps in imagemagick no matter the consequences. I don't need to stress on this list what it means for LyX -- just from todays update of my distro I'm not capable to view most of my documents by default... Unfortuntaly there is very little we can directly for 2.3.1. We should at least signalize in announcement for distro maintainers that this *is* issue and perhaps add some hint how to allow users to locally enable things in policy.xml so they can continue their work. In longer-term -- if this ban continues -- we might try to ask Qt to do the conversions instead of imagemagick, but that's is definitely not for 2.3.1. Other ideas? Pavel https://www.bleepingcomputer.com/news/security/no-patch-available-yet-for-new-major-vulnerability-in-ghostscript-interpreter/ There seems to be a patch for it already. https://artifex.com/news/ghostscript-security-resolved/ Hopefully distros will patch and go back to normal. Daniel
Re: Imagemagick might be banned from postscipt/pdf conversion soon on your distro too (was: 2.3.1 Binaries)
On 09/02/2018 10:50 AM, Scott Kostyshak wrote: > On Sun, Sep 02, 2018 at 12:59:22PM +0200, Pavel Sanda wrote: > >> In longer-term -- if this ban continues -- we might try to ask Qt to do the >> conversions instead of imagemagick, but that's is definitely not for 2.3.1. > That might be a good backup to get working well even if it weren't for > this issue. We should do a lot of testing. I'm certain I do not know enough about this part of the code to do this, but anything we can have Qt do for us here seems like the right thing to do. Then again, Ghostscript seems to be embedded in everything. Maybe Qt uses it. Riki
Re: Imagemagick might be banned from postscipt/pdf conversion soon on your distro too (was: 2.3.1 Binaries)
On Sun, Sep 02, 2018 at 12:59:22PM +0200, Pavel Sanda wrote: > Unfortuntaly there is very little we can directly for 2.3.1. > We should at least signalize in announcement for distro maintainers that this > *is* > issue and perhaps add some hint how to allow users to locally enable things > in policy.xml so they can continue their work. +1 > In longer-term -- if this ban continues -- we might try to ask Qt to do the > conversions instead of imagemagick, but that's is definitely not for 2.3.1. That might be a good backup to get working well even if it weren't for this issue. We should do a lot of testing. Scott signature.asc Description: PGP signature
