dvisvgm needs rebuild to support ghostscript 10

[Sergio Callegari]

Understandable...

unfortunately, installing an older ghostscript is not very 
strightforward, at least on linux. First, the very ghostcript site 
*loudly* advertises version 10 as the current one and even has a large 
"Please update ghostscript" sign with a scary "!" in a triangular alert 
sign. Older releases are now hidden behind a small bottom line "Old 
releases available here". Secondly, the binaries provided on the site do 
not appear to split out "libgs" as needed by the TL dvisvgm.

The matter is similarly not so nice with dvisvgm. The software is so 
tied up with the specialized dvi format that finding binaries is not 
really very easy (e.g. in arch/manjaro it is not even available in the 
huge "aur" repo). Some distros only ship it as part of their TeX offer, 
which unfortunately should not be installed if you want to use the TL 
distro. Upstream does not provide binaries for linux.

All this basically mean that users in distros shipping gs 10 will need 
to install from source (either gs 9 or dvisvgm 2.1.4 or the pre-release 
of version 3).

It is clear that trying to fix this in TL 2022 might look inefficient. 
To avoid similar issues in the future, maybe TL could include its own 
libgs (e.g. as part of the very dvisvgm package, assuming that this is 
the only package needing it). As it is today, the situation is using 
your own words not ideal, because TL is expected to be compatible with 
many flavors of Unix and unfortunately the functionality is somehow 
reduced on a few Linuxes including some that are rather mainstream 
(arch, manjaro, debian sid, KaOS, OpenMandriva Rolling, with OpenSuse 
Tumbleweed expected to join shortly).

Best,

Sergio

On 23/11/2022 22:11, Karl Berry wrote:.
> I don't plan to ask for any rebuild of dvisvgm or anything else before
> TL23. The work (by all the builders) is not worth the benefit, IMHO.
> The users for whom it is critical can either install an older
> ghostscript, or install a newer dvisvgm, outside of TL. Admittedly it's
> not ideal, but I did not create this drastically gratuitous
> incompatibility and am not so interested in spending extra time dealing
> with it. Sorry. --best, karl.