Opened 2 years ago

Closed 21 months ago

#12105 closed enhancement (fixed)

dvisvgm-2.8

Reported by: ken@… Owned by: ken@…
Priority: normal Milestone: 9.1
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description

Until now we have installed dvisvgm as part of texlive, e.g. as /opt/texlive/2018/bin/x86_64-linux/dvisvgm

With the changes during the last year, the modified configure scripts / Makefiles of texlive no-longer permit this to be built when system libs are used, and texlive upstream is unwilling to change this. Debian will use separate dvisvgm. https://dvisvgm.de/

Unfortunately, the dependencies are "heavy" :

Clipper (http://www.angusj.com/delphi/clipper.php)

FontForge (a reduced version is bundled)

FreeType

Ghostscript

kpathsea

openssl - in LFS

potrace

woff2 and brotli (bundled)

xxHash (https://github.com/Cyan4973/xxHash)

For kpathsea, --with-kpathsea=/opt/texlive/2019 works.

Without brotli, it can only be built using --enable-bundle-libs which use all the bundled libs.

I've just apparently managed to built it with those two switches, but DESTDIR installing it (to /usr/local, to see what it produced) only created the basic directories.

Trying to run make check, I am unable to persuade it to find libkpathsea. I suspect it might be looking for a static version. The odd thing is that config.log shows things like

{{{configure:12824: checking for kpse_find_file in -lkpathsea configure:12849: gcc -o conftest -g -O2 -I/opt/texlive/2019/include -I/opt/texlive/2019/include -L/opt/texlive/2019/lib conftest.c -lkpathsea >&5 configure:12849: $? = 0 configure:12858: result: yes configure:12872: checking kpathsea version configure:12890: gcc -o conftest -g -O2 -I/opt/texlive/2019/include -I/opt/texlive/2019/include -L/opt/texlive/2019/lib conftest.c -lkpathsea >&5 configure:12890: $? = 0 configure:12890: ./conftest configure:12890: $? = 0 configure:12899: result: "6.3.1" }}} So at that point it apparently linked successfully to it.

I have little or no use for this (I've dropped eps files since I can no longer view them after last year's ghostscript changes, I don't use DVI files, and I have no reason to convert a page of a PDF to an SVG file.

I'm inclined to let it go.

Attachments (1)

torus12-svg.asy (597 bytes ) - added by ken@… 2 years ago.
Example asy file which worked with asy from the texlive binary

Download all attachments as: .zip

Change History (24)

comment:1 by Douglas R. Reno, 2 years ago

I'd be okay with Woff2 being added. That font engine will simplify WebKitGTK+ by an instruction at least, and add support for more fonts to it.

comment:2 by Bruce Dubbs, 2 years ago

"The command-line utility dvisvgm is a tool for TEX/LaTEX users. It converts DVI, EPS, and PDF files to the XML-based vector graphics format SVG."

It appears that this is a highly specialized tool. Is the benefit of adding this to the book worth the manpower cost of adding and maintaining all those dependencies? I would vote no.

Please note that I am quite familiar with TeX (but I've forgotten a lot). I created some substantial applications using TeX (LaTeX was insufficient) to publish recurring reports (100s of pages) about 20 years ago. In that case it was an incredible tool, but I've personally not found any need for it since. I have never heard of this tool before today.

comment:3 by ken@…, 2 years ago

I'm getting close to updating texlive. In the recommended dependencies, we currently say:

ghostscript-9.27 including libgs.so (for dvisvgm, which is used by e.g. asymptote-2.49)

So far, at [ https://sourceforge.net/p/asymptote/discussion/409349/thread/1b7792a4/] I've found an old example which John Bowman (the asy maintainer) said should work:

asy -V parabola.asy -f svg

but I have not yet found a parabola.svg file. I agree that producing svg from asy is not common, but it would be nice to at least prove if it worked in the past and still works on the binary.

Of course, in my testing I've ripped out the 2018 texlive build from current systems.

comment:4 by ken@…, 2 years ago

In fact, it ought to work on any asy file,so I took torus12.asy from the pdf directory of my latest version of my asy-test file and changed the output.format in it from "pdf" to "svg".

The -V switch means "view" (I assumed it was verbose), so using -d for debug:

ken@origin /tmp $asy -d torus12.asy 
Cannot execute dvisvgm
Please put in a file config.asy: 

import settings;
dvisvgm="LOCATION";

where LOCATION specifies the location of dvisvgm.

Alternatively, set the environment variable ASYMPTOTE_DVISVGM
or use the command line option -dvisvgm="LOCATION". For further details, see
http://asymptote.sourceforge.net/doc/Configuring.html
http://asymptote.sourceforge.net/doc/Search-paths.html
/opt/texlive/2019/texmf-dist/asymptote/three.asy: 2883.13: runtime: shipout failed

So technically, not providing a working *is* a regression.

in reply to:  4 comment:5 by ken@…, 2 years ago

Replying to ken@…:

So technically, not providing a working *is* a regression.

My keyboard seems to have swallowed a word : not providing a working dvisvgm is a regression.

I've now dug out an old 8.3 and installed the corresponding asymptote, and an old 8.4 and installed TL2018 and the corresponding (initial) asy - the joys of keeping scripts in git so I can checkout a past version ;-)

In each case, creating an svg file with asy worked (viewed in inkscape and firefox). When I looked at dvisvgm in gentoo and Arch the other day, both were on 2.7 (and using all the dependencies), I guess there is a slim chance that 2.7.1 broke the install with shipped versions of them. OTOH, my binary install of TL2019 is still using dvisvgm-2.6.3.

comment:6 by ken@…, 2 years ago

Owner: changed from blfs-book to ken@…
Status: newassigned

Now that I know what it is used for, I'll see if any recent version will actually install (initially with the shipped libs, /opt seems a good place to dump it until I can see what it installs).

comment:7 by ken@…, 2 years ago

Got back to this. Typo in my initial comment, should be --enable-bundled-libs (bundled, not bundle).

Looking again at 2.7.1, I've now got it building, and (DESTDIR) installing to the correct place with the bundled libs:

KPSE_LIBS="-L/opt/texlive/2019/lib -lkpathsea" \
 ./configure --bindir=/opt/texlive/2019/bin/x86_64-linux \
 --with-kpathsea=/opt/texlive/2019 \
 --enable-bundled-libs
make
make DESTDIR install

The installed program (unstripped) is 51 MB, my stripped version from 2018 was only 4 MB.

It links to a lot of graphics/security libraries (including kpathsea), not sure how many are direct dependencies (I didn't bother logging at this stage).

But the testsuite seems broken, at least for libkpathsea not in /usr or /usr/local. Even trying

 LD_FLAGS=-L/opt/texlive/2019/lib -lkpathsea" make check

it fails to find -lkpathsea and ignores the LD_FLAGS.

With make -k check it builds all of the test programs before failing (i.e. same error, so it cannot run them).

However, when I try to use it from asy (after adding the full DESTDIR to my PATH) it needs texmf.cnf:

ken@origin /tmp/dvisvgm-2.7.1 $PATH=$PATH:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux asy torus12-svg.asy 
warning: kpathsea: configuration file texmf.cnf not found in these directories: /tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux/share/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux/share/texmf-dist/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux/share/texmf/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux/texmf-dist/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux/texmf/web2c:/tmp/DVISVGM/opt/texlive/2019/bin:/tmp/DVISVGM/opt/texlive/2019/bin/share/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/share/texmf-dist/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/share/texmf/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/texmf-dist/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/texmf/web2c:/tmp/DVISVGM/opt/texlive/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019:/tmp/DVISVGM/opt/texlive/2019/share/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019/share/texmf-dist/web2c:/tmp/DVISVGM/opt/texlive/2019/share/texmf/web2c:/tmp/DVISVGM/opt/texlive/2019/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019/texmf-dist/web2c:/tmp/DVISVGM/opt/texlive/2019/texmf/web2c.

Before that, asy had created a png from the asy file as the first part of the conversion.

We do not install texmf.conf, until now nothing has needed it. Apparently it should go in ~/texmf/:

$kpsewhich -var-value TEXMFHOME
/home/ken/texmf

but I have no idea what to put in it.

Last edited 2 years ago by ken@… (previous) (diff)

in reply to:  7 comment:8 by ken@…, 2 years ago

Replying to ken@…:

However, when I try to use it from asy (after adding the full DESTDIR to my PATH) it needs texmf.cnf:

ken@origin /tmp/dvisvgm-2.7.1 $PATH=$PATH:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux asy torus12-svg.asy 
warning: kpathsea: configuration file texmf.cnf not found in these directories: /tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux/share/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux/share/texmf-dist/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux/share/texmf/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux/texmf-dist/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/x86_64-linux/texmf/web2c:/tmp/DVISVGM/opt/texlive/2019/bin:/tmp/DVISVGM/opt/texlive/2019/bin/share/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/share/texmf-dist/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/share/texmf/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/texmf-dist/web2c:/tmp/DVISVGM/opt/texlive/2019/bin/texmf/web2c:/tmp/DVISVGM/opt/texlive/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019:/tmp/DVISVGM/opt/texlive/2019/share/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019/share/texmf-dist/web2c:/tmp/DVISVGM/opt/texlive/2019/share/texmf/web2c:/tmp/DVISVGM/opt/texlive/2019/texmf-local/web2c:/tmp/DVISVGM/opt/texlive/2019/texmf-dist/web2c:/tmp/DVISVGM/opt/texlive/2019/texmf/web2c.

Before that, asy had created a png from the asy file as the first part of the conversion.

We do not install texmf.conf, until now nothing has needed it. Apparently it should go in ~/texmf/:

$kpsewhich -var-value TEXMFHOME
/home/ken/texmf

but I have no idea what to put in it.

In fact, I _do_ have texmf.conf in the correct place, /opt/texlive/2019/texmf-dist/web2c/texmf.cnf. No idea why find didn't return it. Oh, typo in my command.

Now, no reported error, but still did not create an svg file.

comment:9 by Bruce Dubbs, 2 years ago

Milestone: 8.59.0

Milestone renamed

comment:10 by ken@…, 2 years ago

Current release is 2.7.3, the release notes for 2.7.2 mentioned a change re ghostscript.

Gave this another try using same instructions as above but with a real install this time. No change. I noted that the program is linked to libgs.so.9.

Then I used asy to create a PDF from my asy-tests tarball. I passed that directly to dvisvgm:

$dvisvgm -P torus0.pdf 
processing PDF file
  graphic size: 0pt x 0pt (0mm x 0mm)
  output written to torus0.svg
1 of 1 page converted in 0.18623 seconds

$inkscape torus0.svg # inkscape opened with nothing

$cat torus0.svg 
<?xml version='1.0' encoding='UTF-8'?>
<!-- This file was generated by dvisvgm 2.7.3 -->
<svg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' width='0pt' height='0pt' viewBox='0 0 0 0'>
<defs/>
<g id='page1'/>

When I last tried this with the texlive binary, running asy on a file with settings.outformat = "svg";

produced a valid svg file.

by ken@…, 2 years ago

Attachment: torus12-svg.asy added

Example asy file which worked with asy from the texlive binary

comment:11 by ken@…, 2 years ago

Owner: changed from ken@… to blfs-book
Status: assignednew

I've added an example source file for asy in case anyone wants to take a look at this, but I'm out of ideas for getting the shipped version to work, and I can't see the point of trying to work out which deps are actually needed until I can persuade the shipped version to work. Giving up.

comment:12 by Bruce Dubbs, 2 years ago

It strikes me that this package is more effort than it's worth. AFAIK, Ken is the only BLFS user. I suggest we just leave it as an external dependency of asymptote and mark this as wontfix.

comment:13 by Douglas R. Reno, 2 years ago

Since we used to install this as part of texlive, do we know if it affects documentation generation using texlive in packages when dvisvgm is not present?

I did a grep and found that the following pages reference texlive as a dependency for documentation generation:

general/graphlib/graphite2.xml
general/graphlib/fontconfig.xml
general/graphlib/jasper.xml
general/graphlib/harfbuzz.xml
general/genlib/libksba.xml
general/genlib/libunistring.xml
general/genlib/libassuan.xml
general/genlib/libgcrypt.xml
general/sysutils/cpio.xml
general/genutils/imagemagick.xml
general/genutils/imagemagick6.xml
general/prog/valgrind.xml
general/prog/llvm.xml
general/prog/doxygen.xml
gnome/applications/evince.xml
multimedia/videoutils/ffmpeg.xml
multimedia/libdriv/libvorbis.xml
multimedia/libdriv/opus.xml
multimedia/libdriv/libtheora.xml
networking/mailnews/mutt.xml
postlfs/shells/zsh.xml
postlfs/filesystems/parted.xml
postlfs/security/gnutls.xml
postlfs/security/gnupg2.xml
pst/ps/a2ps.xml
pst/ps/enscript.xml
pst/scanning/sane.xml
pst/printing/gs.xml
pst/printing/gutenprint.xml
server/major/bind.xml
x/installing/libvdpau-va-gl.xml
x/installing/libvdpau.xml
x/lib/fltk.xml

Note that I've never had Texlive installed for any of this, but I didn't have docbook-utils installed before and that has led to problems. Is it possible that if texlive is installed on a system and it's used for documentation generation, that this will lead to problems?

comment:14 by Bruce Dubbs, 2 years ago

If you really need it, it is installed with the install-tl-unx procedure:

[ /opt/texlive ]$ ldd ./2019/bin/x86_64-linux/dvisvgm
        linux-vdso.so.1 (0x00007ffdcdb62000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f6342d2e000)
        libm.so.6 => /lib/libm.so.6 (0x00007f6342be9000)
        libc.so.6 => /lib/libc.so.6 (0x00007f6342a29000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6342d60000)

[ /opt/texlive ]$ ll ./2019/bin/x86_64-linux/dvisvgm -h
-rwxr-xr-x 1 root root 5.3M Mar 12 17:11 ./2019/bin/x86_64-linux/dvisvgm

It's obviously installed with static libraries.

If it's really needed by documentation (very doubtful), then users can install the binary to get it. Most documentation is pre generated anyway.

comment:15 by Bruce Dubbs, 2 years ago

Resolution: overcomebyevents
Status: newclosed

Made dvisvgm an external dependency of asymptote, avoiding the issues of building on BLFS.

Marking overcomebyevents at revision 21896.

comment:16 by ken@…, 21 months ago

Resolution: overcomebyevents
Status: closedreopened
Summary: dvisvgm-2.7.1dvisvgm-2.8

I've got it working enough for asy to produce svg files with only the shipped libs in dvisvgm.

The key change is to get it to properly find libkpathsea:

ln -svf /opt/texlive/${TEXYEAR}/lib/libkpathsea /usr/lib/libkpathsea.so

That might also be useful for evince, or maybe not.

dvisvgm can then be built and tested with:

./configure \
 --bindir=/opt/texlive/${TEXYEAR}/bin/${TEXARCH} \
 --with-kpathsea=/opt/texlive/${TEXYEAR} \
 --enable-bundled-libs 
make
make check
make install

All tests pass, and asy produces svg files. NB for svg files where 'settings.render = 0' is used (that disables freeglut, and produces slightly worse results), a lot of png files are created during the process and that takes a long time. With settings of 4 or 16 the process is quick.

If asy is told to produce html (Web GL and javascript), with render set to 0 it warns it will produce svg for a 2D diagram and similarly produces lots of pngs during the process. With settings of 4 or 16 asy appears to produce html with javascript, but I cannot see the resut in either firefox or falkon, although looking at https://get.webgl.org/ tells me that both support WebGL.

Will probably use -j4 for dvisvgm. I might also look at what is needed if using system libs.

comment:17 by ken@…, 21 months ago

Owner: changed from blfs-book to ken@…
Status: reopenednew

comment:18 by Bruce Dubbs, 21 months ago

Milestone: 9.09.1

comment:19 by ken@…, 21 months ago

Dependencies to use system libs (obviously in addition to ghostscript and fontconfig) are only potrace, brotli, and woff2. xxhash is tested for but it builds ok without it. Asciidoc is optional (to build the manpage(s)).

NB at this stage I have not reinstalled dvisvgm to use system libs.

Brotli is a compression program, it is an external optional dep for curl and can apparently be used by apache and libsoup (not yet confirmed). Unfortunately it insists on installing static libs as well as shared. It can provide bindings for both python2 and python3, and I guess those should be installed, at least while we still need 2 in some places.

Woff2 should recommend brotli.

And just to confirm my comments in asymptote: dvisvgm enables the creation of svg files by asymptote, which includes 2D drawings where html was specified (you get svg and a loud warning).

comment:20 by Douglas R. Reno, 21 months ago

Woff2 fonts can be used in WebKitGTK+ too when it's present on the system

in reply to:  20 comment:21 by ken@…, 21 months ago

Replying to renodr:

Woff2 fonts can be used in WebKitGTK+ too when it's present on the system

Thanks, yes I noticed that from your earlier post. Still sorting out brotli (which should be recommended for WOFF2) at the moment.

comment:22 by ken@…, 21 months ago

Digging into the details, it includes the current version of xxHash. AFAICS nothing else in the book uses that. The xHash website suggests mysql uses it, but in mariadb there are references to files provided by lz4, and a util/xxhash.cc in the rocksdb code. That is an embedded (probably older) version, nothing in the book apart from dvisvgm could use system xxHash so for the moment I'll go with the shipped version.

Meanwhile, the configure opts for dvisvgm need a bit more work. My impression was that it didn't install a man page, but that a manpage was supplied. But I've now got one in /usr/local, I think from building with asciidoc etc installed. Will investigate.

comment:23 by ken@…, 21 months ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.