Cannot generate PDF

[Hibou57]

Invoking latexmk -pdf root as indicated in the README file, cannot generate the expected PDF. It complains about a missing “changes.sty” and there is no file matching “changes*” in the archive. Pressing Enter to still expect to resume, it enters in a series of “unknown sequence” errors. Tried adding the -f command line option ( latexmk -f -pdf root) as suggested by an error message, but it solved nothing.

[pclayton]

changes.sty is typically provided by a TeX distribution. todonotes.sty is also requried. On Fedora, with the texlive packages, you should be able to resolve this with

sudo dnf install texlive-changes texlive-todonotes

[Hibou57]

Thanks,

There was no dnf command for me, and could not find textlive-changes nor textlive-todonotes in Debian packages, so installed texlive-full, since the simple textlive. package was not enough.

I uploaded the PDF here: https://github.com/Hibou57/Successor-ML-PDF . It may help since I found it nowhere.

By the way, I had a question which I did not know where to post, and it's not the first time this question comes to my though.

Is Tex there to stay or will scientific publication switch to something like DITA (XML) and MathML in a more or less far future? I was wondering if MathML provides enough to express things like in formal language areas, but you comment made me think there may be more, like with common convention for notes, changes, and the like. I’m not sure, I feel guess DITA is versatile enough for that, but there may be other issue, like wide spread use of Tex, which I am not familiar with.

The issue I personally have, is with PDF (or Postscript) and how characters are expressed. It's easier to search/index in a group of HTML/text files that in a group PDF files and with Tex, I also noticed with math and logic in Tex, some characters are written using some kind of drawing rather than using plain Unicode character references, which cause issue for searchability (well, font are not always that good, like with logical symbols too small to be readable, but it just needs to create a readable font for logic and the likes). Also, it's seems easier to cross-link between HTML pages, including linking to a particular part of a document, than to do the same between PDF files.

May be that's not the place for such a comment, but if any one want to spontaneously answer this kind of question, you are welcome.

Thanks again for your help with the issue I encountered

[rossberg]

FWIW, for the WebAssembly specification, which also contains a lot of math, we have experimented with different representations. The document is currently generated as both PDF and HTML. The embedded math is generated from embedded Latex and in the HTML version it is rendered client-side by MathJax. We also have a bunch of hacky scripts to generate through Katex server-side instead, but that isn't as mature and functional as MathJax.

A year or two ago, I have experimented with generating MathML but that had two major problems:

1. Functionality: MathML Core, which is what browsers currently agree to implement, lacks some features especially with respect to tables and fonts.
2. Size: HTML/XML is a horribly inefficient format. Deploying the Wasm spec in MathML instead of embedded Latex blew up the HTML documents' size by a factor of 30-50. This has to do with the lack of macros, but also the inherent overhead of SGML syntax. Compression can only partially undo this disadvantage.

For the latter reason, it is unlikely that we will ever deploy the Wasm spec in MathML, even if the former problem should be addressed at some point in the future. A more likely path is that we will eventually configure MathJax to render into MathML, once that is viable again.

[Hibou57]

Thanks for your instructive experience based feedback.