Remove PDF generation

[CyberShadow]

PDF generation using the LaTeX toolchain has proved to be extremely
fragile, extremely difficult to debug, and thus has consumed numerous
hours debugging and working around its problems.

If PDF generation is to be reintroduced in the future, it must be done
using a toolchain which the average dlang.org contributor is capable
of debugging. The current implementation is nowhere close to meeting
that requirement.

[dlang-bot]

Thanks for your pull request, @CyberShadow!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[CyberShadow]

CC @wilzbach @WalterBright @atilaneves and of course @andralex :)

[andralex]

Yah, that bug in the listings package is a complete bear.

One question would be how many folks are downloading the pdf.

[CyberShadow]

Yah, that bug in the listings package is a complete bear.

If only this was the only problem. See the linked thread for another example. I can try to dig out more instances from my emails, but, historically there have been just so many cases where we need to dance around the CI and do random changes just to make the PDF generation succeed.

[Geod24]

100% for it. I too have spent days fighting the unfriendly monster.

[adamdruppe]

If you really want pdf, it is easier to generate from html than from ddoc anyway.

[wilzbach]

Definitely in favor.

[quickfur]

I've always viewed PDF generation via LaTeX from ddoc as one gigantic hack. LaTeX input syntax has certain peculiar nuances that cannot be mechanically generated from an input that wasn't written with such nuances in view, and it's inevitable that the result would have problems. Ddoc's limited expressiveness does not help things. Furthermore, as Adam said, there are easier tools to use than LaTeX if the goal is just to generate a PDF, such as the various HTML-to-PDF tools out there.

I vote in favor of killing this monster with fire.

[andralex]

I've always viewed PDF generation via LaTeX from ddoc as one gigantic hack. LaTeX input syntax has certain peculiar nuances that cannot be mechanically generated from an input that wasn't written with such nuances in view, and it's inevitable that the result would have problems. Ddoc's limited expressiveness does not help things.

Not to launch into a side discussion here, but it's been beneficial in terms of fixing bugs and limitations in ddoc. Also, it did work for a large text and for a long time; if it weren't for the absolutely nuts heisenbug in the listings package there would be good steps to take to make it more robust. Conversely, once it gets removed I fear the text would increasingly make unwitting use of html-related particularities, meaning adding other formats later would be more difficult. But a time sink is a time sink and needs to be plugged.

[CyberShadow]

I think it's really little more than a nice coincidence that it's possible to generate HTML and LaTeX with DDoc. If you try to target anything slightly more complicated (e.g. context-sensitive), such as JSON or Markdown or RTF, the limitations of DDoc become apparent. For documentation, a macro system such as DDoc is a rather suboptimal approach. A more correct approach would be using syntax which can unambiguously describe the text in semantic terms, and thus can be easily parsed into some kind of DOM (or AST if you will), and then emitted into whatever arbitrary formats are desired.

Markdown is a nice format for this purpose though, and it's nice seeing progress with adding Markdown to DDoc for this reason. Unfortunately probably our syntax will never be fully compliant with any other Markdown standard out there.

[CyberShadow]

Failed to download package vibe-core from https://code.dlang.org/packages/vibe-core/1.4.0.zip

@wilzbach I don't suppose it would be possible to make Dub or our build scripts to auto-retry this?