The C code cannot quite be executed directly out of the box: a few trivial customisations are needed, which are in the <kbd>controls.c</kbd> file.

The optional customisations are also within the <kbd>controls.c</kbd> file.

There is a single header file, <kbd>penrose.h</kbd>, which:

As explained above, in <kbd>controls.c</kbd> are multiple definitions needing, or perhaps needing, user attention.

<kbd>main.c</kbd> asks <samp>"What is to be the recursion depth = numTilings?"</samp>, with an `fscanf()` into `numTilings`.

These two, `tiling_initial()` and `tiling_descendant()`, are in <kbd>tilings.c</kbd>.

* For each rhombus in the ancestor tiling, appends its descendants to the descendant tiling by repeated calls of `rhombus_append_descendants` (which is in <kbd>rhombii.c</kbd>).

When almost `rhombii_NumMax` rhombii have been created, space is freed by `rhombii_purgeDuplicates()` (which is in <kbd>purgeDuplicates.c</kbd>), which is called again after the loop.

* Then `neighbours_populate()` (which is in <kbd>neighbours.c</kbd>), and self-evidently populates the neighbours of each rhombus.

Both this and the earlier duplicate-purging work with rhombii sorted by the *y* position, as done by `rhombii_sort()` in <kbd>sortRhombii.c</kbd>.

* <kbd>paths.c</kbd> finds paths. Naturally enough, start at an as-yet-unpathed fat rhombus, and trace using neighbours. If it is an open path, then on coming to an end it restarts from there. For closed paths, there a rhombus must be chosen to have zero `.withinPathNum`, so to be the first rhombus of the path. This is chosen by `rhWithinPathMoreSpecial()` to be one of the rhombii that is as close as possible to the centre of the path, and in the first quadrant.

Insideness is computed in <kbd>insideness.c</kbd>, which makes much use of <kbd>windingNumber.c</kbd>.

This data is gathered by <kbd>pathStats.c</kbd>.

* When making `holesFill()`, some properties were observed, and were checked over some good-size tilings by a routine `verifyHypothesisedProperties()` in <kbd>propertyVerifying.c</kbd>.

* Arrays needs sorting, requiring renumbering of pointers into into them. Already mentioned are `rhombii_sort()` in <kbd>sortRhombii.c</kbd>; also `paths_sort()` in <kbd>sortPaths.c</kbd>; and `pathStats_sort()` in <kbd>sortPathStats.c</kbd>.

In <kbd>controls.c</kbd> there are functions `wantedPostScriptCentre()` which returns the centre of the desired region, and `wantedPostScriptAspect()` which returns the desired _y_/_x_ aspect ratio.

* Some minor and small administration functions are in <kbd>smalls.c</kbd>. Numbers comparisons (which perhaps should have been overloaded, but which weren&rsquo;t): `max_2()`, `min_2()`, `max_4()`, `min_4()`, `avg_2()`, `median_3()`, `median_4()`. Point comparisons (ditto): `points_different_2()`, `points_same_2()`, `points_different_3()`, `points_same_3()`, `points_different_4()`, `points_same_4()`, `collinear()`. Small exporting helpers: `newlinesInString()`, `fileExtension_from_ExportFormat()`.

* There is occasional need to `sprintf()` to a string, for subsequent use. So <kbd>exportTilings.c</kbd> creates `scratchString[]` of length 32767, which many export routines access with `extern char scratchString[];`.

* Some of the output files are large. There should be some effort to not enlarge them needlessly. In particular, the likes of &ldquo;<samp>1.000000000</samp>&rdquo; should be trimmed to &ldquo;<samp>1</samp>&rdquo;. This should not be done with scientific notation: if an _x_ or _y_ value is almost zero, then it should be &ldquo;<samp>0</samp>&rdquo; rather than &ldquo;<samp>-1.234567E-89</samp>&rdquo;. So there is a routine `stringClean()`, in <kbd>stringClean.c</kbd>, which cleans a string in this style. Almost always, the string passed to this is `scratchString`.

* Those with `enum` `ExportFormat` values {`JSON`, `TSV`, `PS_data`} hold data from multiple tilings, for subsequent processing. In <kbd>exportTilings.c</kbd> it loops over tilings, calling code in <kbd>exportTiling.c</kbd>. Each of these loops over arrays, so repeatedly calling code in <kbd>exportPathStats.c</kbd>, in <kbd>exportPath.c</kbd>, and in <kbd>exportRh.c</kbd>. For `TSV`the passed item can be a `NULL` pointer, instructing thar that the header row be output.

* Those with `enum` `ExportFormat` values {`PS_rhomb`, `PS_arcs`, `SVG_rhomb`, `SVG_arcs`} output something useful as-is. That is, an SVG can be viewed; a PostScript file can be distilled (using [Adobe Distiller](https://en.wikipedia.org/wiki/Adobe_Distiller) or [Ghostscript](https://en.wikipedia.org/wiki/Ghostscript)) into a PDF. For these, code in <kbd>export_SoloTiling.c</kbd> calls the appropriate one of <kbd>export_PaintArcsPS.c</kbd>, <kbd>export_PaintArcsSVG.c</kbd>, <kbd>export_PaintRhPS.c</kbd>, <kbd>export_PaintRhSVG.c</kbd>. Some SVG processing is in <kbd>Smalls_SVG.c</kbd>.