Turns out I was overly pessimistic - the ogdf simple demo appears to be working!

\documentclass{article}
\usepackage{tikz}
\usetikzlibrary{graphs,graphdrawing}
\usegdlibrary {ogdf.c.SimpleDemoOGDF}
\begin{document}
\tikz \graph [fast simple demo layout ogdf, my radius ogdf=1cm]
  { a -> b -> c -> d -> e -> a };
\end{document}

Good news: the C demo is working as expected (after putting the *.so files to the right location):

\documentclass{article}
\usepackage{tikz}
\usetikzlibrary{graphs,graphdrawing}
\usegdlibrary {examples.c.SimpleDemoC}
\begin{document}
\tikz \graph [fast simple demo layout, fast simple demo radius=1.25cm]
  { a -> b -> c -> d -> e -> a };
\end{document}

Bad news: the C++ demo is crashing:

\documentclass{article}
\usepackage{tikz}
\usetikzlibrary{graphs,graphdrawing}
\usegdlibrary {examples.c.SimpleDemoCPlusPlus}
\begin{document}
\tikz \graph [fast simple demo layout c++, fast simple demo radius c++=1.25cm]
  { a -> b -> c -> d -> e -> a };
\end{document}

(/usr/local/texlive/2024/texmf-dist/tex/latex/base/ts1cmr.fd) (/usr/local/texlive/2024/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) (/usr/local/texlive/2024/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty (/usr/local/texlive/2024/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg))...graphdrawing/lua/pgf/gd/interface/InterfaceToDisplay.lua:213: ...c/pgf/graphdrawing/lua/pgf/gd/control/LayoutPipeline.lua:247: attempt to index a nil value (local 'spanning_algorithm_class')
stack traceback:
	[C]: in function 'assert'
	...graphdrawing/lua/pgf/gd/interface/InterfaceToDisplay.lua:213: in function 'pgf.gd.interface.InterfaceToDisplay.resumeGraphDrawingCoroutine'
	...graphdrawing/lua/pgf/gd/interface/InterfaceToDisplay.lua:182: in function 'pgf.gd.interface.InterfaceToDisplay.runGraphDrawingAlgorithm'
	[\directlua]:1: in main chunk.

which means for some reason line 245 in LayoutPipeline.lua has nil assigned to spanning_algorithm_class:

      local spanning_algorithm_class = syntactic_component.options.algorithm_phases["spanning tree computation"]

I suspect somehow my C++ build was not done correctly. Since ogdf is built on top of the C++ interface/layer, it probably won't work either :(

I found two examples in SugiyamaLayout.lua that specifies something like:

\tikz \graph [SugiyamaLayout]

but the key SugiyamaLayout is never registered with the graph drawing system. I suspect it should be replaced by "layered layout" instead. SugiyamaLayout appears to be only used internally for some other purposes (such as documentation generation).

What do you think?

I found some examples in SugiyamaLayout.lua that specifies something like:

\tikz \graph [SugiyamaLayout]

but the key SugiyamaLayout is never registered with the graph drawing system. I suspect it should be replaced by "layered layout" instead. SugiyamaLayout appears to be only used internally for some other purposes (such as documentation generation).

What do you think?

I found some examples in SugiyamaLayout.lua that specifies something like:

\tikz \graph [SugiyamaLayout]

but the key SugiyamaLayout is never registered with the graph drawing system. I suspect it should be replaced by layered layout instead. SugiyamaLayout appears to be only used internally for some other purposes (such as documentation generation).

What do you think?

Under section 28.9 Hyperedges, it says "Currently, there is no default renderer for hyper edges." and then shows an example

\graph {
% The nodes: a, b, c, d;
% The edges:
  {[hyper] a,b,c};
  {[hyper] b,c,d};
  {[hyper] a,c};
  {[hyper] d}
};

Does this mean this example would not work. If so, why provide the example?

Under section 28.9 Hyperedges, it says "Currently, there is no default renderer for hyper edges." and then shows an example

\graph {
% The nodes: a, b, c, d;
% The edges:
  {[hyper] a,b,c};
  {[hyper] b,c,d};
  {[hyper] a,c};
  {[hyper] d}
};

Does this mean this example would not work? If so, why provide the example?

Under section 28.9 Hyperedges, it says "Currently, there is no default renderer for hyper edges." and then shows an example

\graph {
% The nodes: a, b, c, d;
% The edges:
  {[hyper] a,b,c};
  {[hyper] b,c,d};
  {[hyper] a,c};
  {[hyper] d}
};

Does this mean this example would not work? If so, why provide the example?

I tried out the 36.2.1 The Hello World of Graph Drawing at https://tikz.dev/gd-algorithm-layer with:

\documentclass{standalone}
\usepackage{fp,pgf,tikz,xcolor}
\usetikzlibrary{graphs,graphdrawing}
\usegdlibrary{simpledemo}
\begin{document}
\tikz [very simple demo layout]
  \graph { f -> c -> e -> a -> {b -> {c, d, f}, e -> b}};
\end{document}

which didn't compile. Digging into the code, it seems to me the culprit is because the actual implementation in Simple.lua$L25-L39 differs from that in the documentation. Specifically,

1. Instead of declaring the key "very simple demo layout", the existing implementation declares "simple demo layout".
2. Instead of calculating the (x,y) coordinates linearly as claimed in the doc, the existing implementation multiply each with an seemingly spurious "radius" which always have a zero value thus causing incorrect rendering.

Does this sound right?

I tried out the 36.2.1 The Hello World of Graph Drawing at https://tikz.dev/gd-algorithm-layer with:

\documentclass{standalone}
\usepackage{fp,pgf,tikz,xcolor}
\usetikzlibrary{graphs,graphdrawing}
\usegdlibrary{simpledemo}
\begin{document}
\tikz [very simple demo layout]
  \graph { f -> c -> e -> a -> {b -> {c, d, f}, e -> b}};
\end{document}

which didn't compile. Digging into the code, it seems to me the culprit is because the actual implementation in Simple.lua#L25-L39 differs from that in the documentation. Specifically,

1. Instead of declaring the key "very simple demo layout", the existing implementation declares "simple demo layout".
2. Instead of calculating the (x,y) coordinates linearly as claimed in the doc, the existing implementation multiply each with an seemingly spurious "radius" which always have a zero value thus causing incorrect rendering.

Does this sound right?

I tried out the 36.2.1 The Hello World of Graph Drawing at https://tikz.dev/gd-algorithm-layer with:

\documentclass{standalone}
\usepackage{fp,pgf,tikz,xcolor}
\usetikzlibrary{graphs,graphdrawing}
\usegdlibrary{simpledemo}
\begin{document}
\tikz [very simple demo layout]
  \graph { f -> c -> e -> a -> {b -> {c, d, f}, e -> b}};
\end{document}

which didn't compile. Digging into the code, it seems to me the culprit is because the actual implementation in Simple.lua#L25-L39 differs from that in the documentation. Specifically,

1. Instead of declaring the key "very simple demo layout", the existing implementation declares "simple demo layout".
2. Instead of calculating the (x,y) coordinates linearly as claimed in the doc, the existing implementation multiplies further with an seemingly spurious "radius" which always have a zero value thus causing incorrect rendering.

Does this sound right?

I tried out the 36.2.1 The Hello World of Graph Drawing at https://tikz.dev/gd-algorithm-layer with:

\documentclass{standalone}
\usepackage{fp,pgf,tikz,xcolor}
\usetikzlibrary{graphs,graphdrawing}
\usegdlibrary{simpledemo}
\begin{document}
\tikz [very simple demo layout]
  \graph { f -> c -> e -> a -> {b -> {c, d, f}, e -> b}};
\end{document}

which didn't compile. Digging into the code, it seems to me the culprit is because the actual implementation in SimpleDemo.lua#L25-L39 differs from that in the documentation. Specifically,

1. Instead of declaring the key "very simple demo layout", the existing implementation declares "simple demo layout".
2. Instead of calculating the (x,y) coordinates linearly as claimed in the doc, the existing implementation multiplies further with an seemingly spurious "radius" which always have a zero value thus causing incorrect rendering.

Does this sound right? (Once I fixed the code in SimpleDemo.lua, it started to work as expected.)

I tried out the 36.2.1 The Hello World of Graph Drawing at https://tikz.dev/gd-algorithm-layer with:

\documentclass{standalone}
\usepackage{fp,pgf,tikz,xcolor}
\usetikzlibrary{graphs,graphdrawing}
\usegdlibrary{simpledemo}
\begin{document}
\tikz [very simple demo layout]
  \graph { f -> c -> e -> a -> {b -> {c, d, f}, e -> b}};
\end{document}

which didn't compile. Digging into the code, it seems to me the culprit is because the actual implementation in SimpleDemo.lua#L25-L39 differs from that in the documentation. Specifically,

1. Instead of declaring the key "very simple demo layout", the existing implementation declares "simple demo layout".
2. Instead of calculating the (x,y) coordinates linearly as claimed in the doc, the existing implementation multiplies further with a seemingly spurious "radius" which always have a zero value thus causing incorrect rendering.

Does this sound right? (Once I fixed the code in SimpleDemo.lua, it started to work as expected.)

I tried out the 36.2.1 The Hello World of Graph Drawing at https://tikz.dev/gd-algorithm-layer with:

\documentclass{standalone}
\usepackage{fp,pgf,tikz,xcolor}
\usetikzlibrary{graphs,graphdrawing}
\usegdlibrary{SimpleDemo}
\begin{document}
\tikz [very simple demo layout]
  \graph { f -> c -> e -> a -> {b -> {c, d, f}, e -> b}};
\end{document}

which didn't compile. Digging into the code, it seems to me the culprit is because the actual implementation in SimpleDemo.lua#L25-L39 differs from that in the documentation. Specifically,

1. Instead of declaring the key "very simple demo layout", the existing implementation declares "simple demo layout".
2. Instead of calculating the (x,y) coordinates linearly as claimed in the doc, the existing implementation multiplies further with a seemingly spurious "radius" which always have a zero value thus causing incorrect rendering.

Does this sound right? (Once I fixed the code in SimpleDemo.lua, it started to work as expected.)

In reply to @some.knowit:matrix.org
Let me try to submit a pull request on this.

In reply to @muzzi:matrix.org
Probably a poppler issue, see https://github.com/DominikPeters/tikz.dev-issues/issues/42.

This is kind of like a fun quiz. Suppose:

\def\foo#1{\textbf{#1}}
\def\abc{Hello}
\def\xyz{, World!}
\def\bar{\abc\xyz}

What do you expect to see in the following cases:

Case 1: \foo\bar

Case 2: \expandafter\foo\bar

Case 3: \expandafter\expandafter\foo\bar

Case 4: \expandafter\expandafter\expandafter\foo\bar

After fixing all the missing preamble and extending the existing extractor.lua (in my local branch), it extracted 2,503 tex document. I managed to compile them all successfully. The generated pgfmanual.pdf also looking good.

I plan to submit two pull requests - one for fixing the preamble, etc. so that readers of the manual can copy-and-paste any of the examples in the pdf and have them successfully compiled, and another for the extended extractors and scripts.

I've got other things fixed as well, but I'll delay those to future pull requests.

After fixing all the missing preambles and extending the existing extractor.lua (in my local branch), it extracted 2,503 tex documents. I managed to compile them all successfully. The generated pgfmanual.pdf is also looking good.

I plan to submit two pull requests - one for fixing the preamble, etc. so that readers of the manual can copy-and-paste any of the examples in the pdf and have them successfully compiled, and another for the extended extractors and scripts.

I've got other things fixed as well, but I'll delay those to future pull requests.

After fixing all the missing preambles and extending the existing extractor.lua (in my local branch), it extracted 2,503 tex documents. I managed to compile them all successfully. The generated pgfmanual.pdf is also looking good.

I plan to submit two pull requests - one for fixing the preamble, etc. so that readers of the manual can copy-and-paste any of the examples in the pdf and have them successfully compiled, and another for the extended extractors and scripts.

I've got other things fixed as well, but I'll delay those to future pull requests.

However, these changes presume the fix in pull request #1339 has been merged. Any chance that can be done any time soon?

After fixing all the missing preambles and extending the existing extractor.lua (in my local branch), it extracted 2,503 tex documents. I managed to compile them all successfully. The generated pgfmanual.pdf is also looking good.

I plan to submit two pull requests - one for fixing the preamble, etc. so that readers of the manual can copy-and-paste any of the examples in the pdf and have them successfully compiled, and another for the extended extractors and scripts.

(I've got other miscellaneous things fixed as well, but I'll delay those to future pull requests.)

However, these changes presume the fix in pull request #1339 has been merged. Any chance that can be done any time soon?

After fixing all the missing preambles and extending the existing extractor.lua (in my local branch), it extracted 2,503 tex documents. I managed to compile them all successfully. The generated pgfmanual.pdf is also looking good. (You should be able to download the updated pdf from https://github.com/hansonchar/pgf/actions/runs/9750355245 once the workflow has completed.)

I plan to submit two pull requests - one for fixing the preamble, etc. so that readers of the manual can copy-and-paste any of the examples in the pdf and have them successfully compiled, and another for the extended extractors and scripts.

(I've got other miscellaneous things fixed as well, but I'll delay those to future pull requests.)

However, these changes presume the fix in pull request #1339 has been merged. Any chance that can be done any time soon?

After fixing all the missing preambles and extending the existing extractor.lua (in my local branch), it extracted 2,503 tex documents. I managed to compile them all successfully. The generated pgfmanual.pdf is also looking good. (You should be able to download the updated pdf from https://github.com/hansonchar/pgf/actions/runs/9750355245 once the workflow has completed.)

I plan to submit two pull requests - one for fixing the preamble, etc. so that readers of the manual can copy-and-paste any of the examples in the pdf and have them successfully compiled, and another for the extended extractors and scripts.

(I've got other miscellaneous things fixed as well, but I'll delay those to future pull requests.)

However, these changes presume the fixes in pull request #1339 has been merged. Any chance that can be done any time soon?

After fixing all the missing preambles and extending the existing extractor.lua (in my local branch), it extracted 2,503 tex documents. I managed to compile them all successfully. The generated pgfmanual.pdf is also looking good. (You should be able to download the updated pdf from https://github.com/hansonchar/pgf/actions/runs/9750355245 once the workflow has completed.)

I plan to submit two pull requests - one for fixing the preamble, etc. so that readers of the manual can copy-and-paste any of the examples in the pdf and have them successfully compiled, and another for the extended extractors and scripts.

(I've got other miscellaneous things fixed as well, but I'll delay those to future pull requests.)

However, these changes presume the fixes in pull request #1339 have been merged. Any chance that can be done any time soon?

After fixing all the missing preambles and extending the existing extractor.lua (in my forked main branch), it extracted 2,503 tex documents. I managed to compile them all successfully. The generated pgfmanual.pdf is also looking good. (You should be able to download the updated pdf from https://github.com/hansonchar/pgf/actions/runs/9750355245 once the workflow has completed.)

I plan to submit two pull requests - one for fixing the preamble, etc. so that readers of the manual can copy-and-paste any of the examples in the pdf and have them successfully compiled, and another for the extended extractors and scripts.

(I've got other miscellaneous things fixed as well, but I'll delay those to future pull requests.)

However, these changes presume the fixes in pull request #1339 have been merged. Any chance that can be done any time soon?