Add PNG version of stdtolocal image for web rendering of dev guide

In Section 2.2 of the developer guide, figure 2.1, doesn't appear in the web-rendered version. The page is linking to a PNG version of the stdtolocal graphic while only a PDF seems to be in the repo.

Rather than simply change the link to PDF, I think a PNG version of the image is probably more sensible for the web version of the guide anyway so I've created a PNG version of the image and added this to the repo in addition to the existing (vector?) PDF version which I guess may be used for generating the PDF version of the guide.

(Since this MR only adds an image file and a symlink to the repo and doesn't change any existing files, I've skipped the vast majority of pipline jobs, leaving only those related to documentation to run.)

added documentation typedefect labels

requested review from @dmoxey and @ccantwel

changed the description

@jhc02 All the PDFs should be converted to PNGs automatically by post-build rules in CMake. Indeed these rules do seem to be generating the PNGs, but they are being put in sub-directories in the build path (matching the source PDF), while the HTML is being generated without these sub-directories in the URLs. I think this is a bug in tex4ht: https://tex.stackexchange.com/questions/116476/how-to-send-output-of-htlatex-to-different-folder-without-fixing-all-image-links

We could try building the documentation on Debian bookworm and see if the problem persists?

added 2 commits

• d56fb928 - Revert "Add PNG version of stdtolocal image for web rendering of dev guide"
• 1be482ee - Update dev guide CMake to change location of generated png

Compare with previous version

I've reverted the original change and now added an update to the CMake configuration that generates the PNG from the PDF. The nektar/docs/developer-guide/img directory is not being scanned for PDFs to convert and there are several other PDFs in there anyway. Instead, I opted to check whether we're handling PDFs from nektar/docs/developer-guide/introduction/img and then modify the output directory to put the resulting stdtolocal.png file in the correct location.

I appreciate that there are several different options here, I thought this seemed like the best since it avoids adding nektar/docs/developer-guide/img to the list of directories scanned for PDFs and the resulting unnecessary conversion of several files. However, happy to switch to an alternative solution if you prefer.

Just to note, after looking at the tex4ht bug mentioned above and how the image conversion is handled in the CMake config, this seems to be unrelated to that bug since we're simply searching for PDF files in "*/img/*.pdf" and then calling the convert tool from ImageMagick on each of the PDF files, specifying the input file name and the output PNG file name.

From discussion at MR meeting - decided that a preferred approach would be to simply edit the setup so that all files are output to the base /html/img directory. On this basis, we can then remove all the symlinks that result in the files from individual img directories also appearing in the top-level img directory. This will simplify the CMake changes and result in converted PDF files being output as PNGs directly in the top level directory.

added devs-meeting label

I think we probably just need to take a practical view on this, in that it's not critical for the code and people can't see the images in documentation and that this MR at least fixes that problem even if it's not perfect. I'll merge this for now and if we want to revisit this in the future then we can try to make a better patch.

removed devs-meeting label

changed milestone to %v5.3.0

resolved all threads

merged

mentioned in commit 89b39332