I recently have a bit of time and was thinking of trying to help improve graphviz performance, since it’s a tool I seem to use often in my work, and it hasn’t speeded up as much as computer hardware has over the past few decades. But first I was trying to make sure that I can run all tests locally to make it easier to detect any changes in output.
However, I found that, on my Ubuntu 24.04(.03) AMD laptop, I’m unable to pass one test, due to slight variation in output sizes:
tests/test_rtest.py:382: AssertionError
----------------------------- Captured stdout call -----------------------------
+ dot -Kdot -Tgv -o /tmp/pytest-of-brm/pytest-5/test_graph_shapes_input1_dot_g0/shapes_dot.gv /home/brm/code/graphviz/tests/graphs/shapes.gv
=========================== short test summary info ============================
FAILED tests/test_rtest.py::test_graph[shapes-input1-dot-gv-flags1-0] - asser...
============================== 1 failed in 0.05s ===============================
Comparing my local run with a local but pristine Docker-based build-and-test run, I eventually determined (by comparing strace output when running the test in the two environments) that the problem is most likely that my deskotop system is loading “Times_New_Roman.ttf”, while the pristine Ubuntu environment doesn’t have that font, and seems to be using “DejaVuSerif.ttf” instead.
As the documentation indicates that “Times New Roman” will be used by default, it seems odd that one needs the not-very-free msttcorefonts package for the described behavior to happen, and that tests on Linux (at least Ubuntu) don’t seem to expect this font. But anyway…
Trying to reproduce this test unchanged in my own desktop environment (for future debugging convenience), I have noticed that there is an environment variable DOTFONTPATH which might be used to set the font to use, but I still seem to wind up with /usr/share/fonts/truetype/msttcorefonts/Times_New_Roman.ttf used even if I set and export DOTFONTPATH=/usr/share/fonts/truetype/dejavu.
Am I using this environment variable wrong? Not sure where the latest docs are, other than dotguide.pdf in the source, which seems about 10 years old.
Oops, I should have used an LLM before wasting human time. (But if noone asks questions and accepts answers in the forums, then how will LLMs datamine those questions and answers in the future?)
I now see that https://graphviz.org/faq/font/` probably answers my question about why DOTFONTPATH doesn’t work: fontconfig takes precedence if available. I still think it’s odd that the Linux tests aren’t using “Times Roman”, which is still mentioned as the default: fontname | Graphviz.
Guess I’ll just patch the reference test output locally while I’m debugging, and put it back before sharing.
I don’t know how the graphviz CI is set up, but for my work’s test environment I have a very minimal font config file and tiny set of fonts and force the use of these by setting the FONTCONFIG_FILE and XDG_DATA_HOME environment variables.
Well, I gave up on running the CI scripts directly, but FYI, I was able to manually execute build and test properly to pass on Ubuntu-24.04 by doing the following:
docker run -it --rm -v $(pwd):/work -w /work registry.gitlab.com/graphviz/graphviz/ubuntu-24.04
bin/bash
export PREFIX=$(mktemp -d)
./autogen.sh && ./configure --prefix=${PREFIX} && make clean && make && make install |& tee build.out2
env PATH=${PREFIX}/bin:/opt/virtualenv/bin:${PATH} C_INCLUDE_PATH=${PREFIX}/include \
LD_LIBRARY_PATH=${PREFIX}/lib LIBRARY_PATH=${PREFIX}/lib \
PYTHONPATH=${PREFIX}/lib/graphviz/python3 \
TCLLIBPATH=${PREFIX}/lib/graphviz/tcl \
PKG_CONFIG_PATH=${PREFIX}/lib/pkgconfig \
graphviz_ROOT=${PREFIX} \
python3 -m pytest tests
After the first line those are commands run in the docker image.
The specified image doesn’t have as many fonts as my dev machine, so the test passes. (Maybe I should slim down?)
I suspect that other CI jobs can be run similarly, though to run multiple configs one might want to figure out how to invoke the CI jobs directly.
Thanks for the hint. I was able to just create a minimal fonts.conf file and point FONTCONFIG_FILE to it to get consistent test output on my machine.
Not sure why you needed XDG_DATA_HOME, maybe for some other tests?
Well this certainly explains why I was getting different results for that test locally than CI One of my background tasks has been to resurrect the old “rtest” test suite that does these comparisons. But one of the problems, as you’ve experienced, is that a diff against a reference file doesn’t really work when some of these things are dependent on which fonts you have installed. We should probably explore how to isolate the tests and ensure they don’t see arbitrary local fonts the user has added.