Conversation
9e4f364 to
9414aff
Compare
This requires using another LaTeX package (here we chose ulem).
So this induces some risk of breakage for anyone building PDFs:
if that package is not installed, it will fail.
So in particular we should first update the Docker contain to
make sure it provides this package.
In addition, I wonder if one could arrange it so that
`\usepackage[normalem]{ulem}` is only used if in fact anything
is using strike through... ?
9414aff to
e8f02f0
Compare
|
@ViralBShah I've reverted your changes here as one caused a merge conflict, the other was a new changelog entry but I deliberately did not want to have one here yet (it just has to be moved around when releases are made, plus this is a draft, and the failing changelog entry test doesn't matter there. |
|
@fingolfin Apologies for the unnecessary work I created here. Thank you for reverting and I will create separate new issues and PRs for review. |
|
@ViralBShah no problem and it wasn't much work. I appreciate that you had best intentions only. And I also would like to get this done, and your nice PDF improvements in. Hopefully someone who knows more than me about Docker, container registries etc. can pick up the Documenter Docker container/image thingy and drag it into the year 2026 :-) |
|
Thanks @fingolfin. I chimed in on the other issue - that we should deprecate the Docker method. I believe it made sense back in the day when CI tooling was not what it is today. The big user of that was the Julia pdf manual generation, which I have now switched over to installing a modern latex directly. |
This requires using another LaTeX package (here we chose ulem). So this induces some risk of breakage for anyone building PDFs: if that package is not installed, it will fail.
So in particular we should first update the Docker contain to make sure it provides this package.
In addition, I wonder if one could arrange it so that
\usepackage[normalem]{ulem}is only used if in fact anything is using strike through... ?