LaTeX3 Automatic Labels for Fun and No Profit(commutative.xyz)
commutative.xyz
LaTeX3 Automatic Labels for Fun and No Profit
https://commutative.xyz/~miguelmurca/blog/x/autoref.html
89 comments
Typst does look very nice based on the brief look I took at it, but besides the questions of adoption and entrenchment that have been raised in parallel comments, the choice of Rust as the implementation language is also concerning to me. I think that Rust and the community that surrounds it are associated with a newer, simultaneously somewhat trend-chasing and decidedly paternalistic culture of software engineering that does not mesh well with the longtermist demands of science and scientific publishing. Concretely,
* Where LaTeX evidently favours doing whatever it takes to achieve a desired result (exhibit 1 being the article we are discussing), Rust itself and the culture that begot it are clearly on the side of decreeing a Right Way from high above and treating the possibility of deviating from it as a bug. In the light of the discussion in Footnote 7, I could for example imagine a Rust-minded typesetting system designer decreeing that unnumbered "displaystyle" math will not be supported.
* Cultural acceptance of mandatory automatic updates means that backwards compatibility may actually be considered an anti-goal.
* Cultural acceptance of ideology/politics in software engineering brings the danger of invasive conditions. What if, by way of an aggressively interpreted CoC, {receiving funding from military/police-aligned agencies, working with Russian collaborators, working with Iranian collaborators} becomes grounds for being excluded from issue discussions or package repositories? (I do take note that Typst does not currently show signs of doing anything like this, but the tone of the wider Rust community does have to be taken into account.)
Of course all these concerns are speculative, but scientific papers can be a nightmare scenario of maintenance (half a year's worth of work, one-digit number of people in the world qualified to write, two-digit number of people who will bother to read). Under those constraints, some measure of paranoia feels appropriate.
* Where LaTeX evidently favours doing whatever it takes to achieve a desired result (exhibit 1 being the article we are discussing), Rust itself and the culture that begot it are clearly on the side of decreeing a Right Way from high above and treating the possibility of deviating from it as a bug. In the light of the discussion in Footnote 7, I could for example imagine a Rust-minded typesetting system designer decreeing that unnumbered "displaystyle" math will not be supported.
* Cultural acceptance of mandatory automatic updates means that backwards compatibility may actually be considered an anti-goal.
* Cultural acceptance of ideology/politics in software engineering brings the danger of invasive conditions. What if, by way of an aggressively interpreted CoC, {receiving funding from military/police-aligned agencies, working with Russian collaborators, working with Iranian collaborators} becomes grounds for being excluded from issue discussions or package repositories? (I do take note that Typst does not currently show signs of doing anything like this, but the tone of the wider Rust community does have to be taken into account.)
Of course all these concerns are speculative, but scientific papers can be a nightmare scenario of maintenance (half a year's worth of work, one-digit number of people in the world qualified to write, two-digit number of people who will bother to read). Under those constraints, some measure of paranoia feels appropriate.
I think the idea in this comment -- that users of languages inherit all of the perceived negatives of the community developing the language -- is just wrong. (I say "perceived" because some of the claims in this post are simply incorrect, such as the claim the Rust language developers think "backwards compatibility may actually be considered an anti-goal".)
For example, over the last couple of years I've been re-implementing some of Knuth's typesetting work in Rust. Contrary to your claim, my project is obsessed with backwards compatibility and making sure the output is identical to Knuth's. Last weekend I even discovered a ~30-year old bug in one of Knuth's programs [1] as part of an extensive fuzzing effort. (Of course, I re-implemented Knuth's bug in my Rust code [2].)
[1] https://tug.org/pipermail/tex-k/2024-March/004031.html [2] https://github.com/jamespfennell/texcraft/commit/e89b7461780...
For example, over the last couple of years I've been re-implementing some of Knuth's typesetting work in Rust. Contrary to your claim, my project is obsessed with backwards compatibility and making sure the output is identical to Knuth's. Last weekend I even discovered a ~30-year old bug in one of Knuth's programs [1] as part of an extensive fuzzing effort. (Of course, I re-implemented Knuth's bug in my Rust code [2].)
[1] https://tug.org/pipermail/tex-k/2024-March/004031.html [2] https://github.com/jamespfennell/texcraft/commit/e89b7461780...
I didn't claim anything about your project at all. A claim about a perceived tendency does not amount to asserting an absolute rule.
That being said, though, for any major project, it's hard to overstate the long-term effect of community pressure. I maintain a moderately-sized project using Gtk for its GUI, and am personally deeply opposed to the RHEL blob (which Gtk/Gnome belongs to)'s culture of "windowsification"/switching away from simple composable interfaces to overengineered proprietary ones. Yet, recently contributors successfully browbeat me into switching the config system from a legible textual one to gsettings (basically Gtk's implementation of the Win32 registry, with all this implies) - it was just too much pressure over what seemed like an ultimately minor thing, and I didn't want to alienate people who I depend on for a lot of work that being well-embedded in the wider community conveys competitive advantage in, such as getting packages into distro repositories. I'm left wondering what principles/preferences I would not compromise on, if the resident Gnome wizards were to all disagree. If your project grew so large that you couldn't do without the help of random Rust community members, and the majority of them got very insistent that you should not reproduce Knuth's idiosyncrasies, can you say with confidence that you would resist?
That being said, though, for any major project, it's hard to overstate the long-term effect of community pressure. I maintain a moderately-sized project using Gtk for its GUI, and am personally deeply opposed to the RHEL blob (which Gtk/Gnome belongs to)'s culture of "windowsification"/switching away from simple composable interfaces to overengineered proprietary ones. Yet, recently contributors successfully browbeat me into switching the config system from a legible textual one to gsettings (basically Gtk's implementation of the Win32 registry, with all this implies) - it was just too much pressure over what seemed like an ultimately minor thing, and I didn't want to alienate people who I depend on for a lot of work that being well-embedded in the wider community conveys competitive advantage in, such as getting packages into distro repositories. I'm left wondering what principles/preferences I would not compromise on, if the resident Gnome wizards were to all disagree. If your project grew so large that you couldn't do without the help of random Rust community members, and the majority of them got very insistent that you should not reproduce Knuth's idiosyncrasies, can you say with confidence that you would resist?
Thank you for your very thoughtful response. This has given me food for thought.
Rust has enabled much better science at least in my field of Cryptography than whatever nonsense people wrote in C/C++ before. I have the feeling the same is true for other areas like Systems.
And it's also laughable to claim that any research paper written in LaTeX is "maintained". It's a one-off job. Nobody is reusing their previous papers as submodules in new ones.
And it's also laughable to claim that any research paper written in LaTeX is "maintained". It's a one-off job. Nobody is reusing their previous papers as submodules in new ones.
> better code
I'm not disputing that Rust has its advantages; the issues I talk above are mostly problems with the community than the language per se. (On the other hand, we are yet to see how the "import antigravity" attitude will play out once the bits had enough time to rot - it does matter whether your ten-liner test program is only using libc because it was too much work to get a nice pretty-printing library, or whether you imported a pretty-printing library because you could, resulting in 2GB of transitive dependencies of which some have 10 users and 0 active maintainers. And then there's the supply chain security issues)
> maintenance
Surely depends on how fast-moving your field is - I have reused diagram code from late-'90s category theory papers, and recompiled more from source just to get the benefits of the pdflatex pipeline over the latex-dvips-ps2pdf one (selectable text, proper font rendering, hyperref). Repositories like arXiv also may need the ability to recompile old submissions automatically.
I'm not disputing that Rust has its advantages; the issues I talk above are mostly problems with the community than the language per se. (On the other hand, we are yet to see how the "import antigravity" attitude will play out once the bits had enough time to rot - it does matter whether your ten-liner test program is only using libc because it was too much work to get a nice pretty-printing library, or whether you imported a pretty-printing library because you could, resulting in 2GB of transitive dependencies of which some have 10 users and 0 active maintainers. And then there's the supply chain security issues)
> maintenance
Surely depends on how fast-moving your field is - I have reused diagram code from late-'90s category theory papers, and recompiled more from source just to get the benefits of the pdflatex pipeline over the latex-dvips-ps2pdf one (selectable text, proper font rendering, hyperref). Repositories like arXiv also may need the ability to recompile old submissions automatically.
Typst has nowhere the control and reproducibility of LuaTeX. It's core syntax is quite weak and will be a bottleneck in future. It is especially weak for structure of huge documents, and for mathematics.
LuaTeX is stupid but it still has features needed which none of the other markup languages posses.
LuaTeX is stupid but it still has features needed which none of the other markup languages posses.
This is quite baseless without any proof or at least example.
Many of the equations and syntax I used in my PhD work can't be written in Typst. For instance, Young Tableaus, or commutation diagrams. Or circuits generated from inline code. I am not even sure if it has been coded in a way to support such extensions.
So I would not recommend a new PhD student (actually undergrad student) to learn Typst just yet.
So I would not recommend a new PhD student (actually undergrad student) to learn Typst just yet.
Could you give some examples of these equations?
The ecosystem for the kind of things you mention is expanding rapidly, have a look at these:
https://typst.app/universe/package/fletcher
https://typst.app/universe/package/quill
https://github.com/fenjalien/cirCeTZ
These are based on CeTZ: https://github.com/johannes-wolf/cetz , a kind of TikZ for typst. I don't see anything for Young Tableaux but it should be easy to do based on that.
The ecosystem for the kind of things you mention is expanding rapidly, have a look at these:
https://typst.app/universe/package/fletcher
https://typst.app/universe/package/quill
https://github.com/fenjalien/cirCeTZ
These are based on CeTZ: https://github.com/johannes-wolf/cetz , a kind of TikZ for typst. I don't see anything for Young Tableaux but it should be easy to do based on that.
[deleted]
> The author is a PhD student that has been using LaTeX heavily for 10 years. But what should a new student use, and why? When the only reason to choose LaTeX is old colleagues and gatekeeping publishers, I know it's a matter of time.
Sadly its more than that. Will we be able to compile a typst file made today in 10 years? I have to do that regularly with latex. Will everybody one collaborates with also use typst? Very unlikely. A new PhD student may find it beneficial to write papers with someone who only uses latex. then why bother with typst? (and I really want typst to win)
Sadly its more than that. Will we be able to compile a typst file made today in 10 years? I have to do that regularly with latex. Will everybody one collaborates with also use typst? Very unlikely. A new PhD student may find it beneficial to write papers with someone who only uses latex. then why bother with typst? (and I really want typst to win)
I regularly can't do that in LaTeX due to changes in packages. Yeah, the core is stable, but dependencies are still an issue in TeX land.
That's only true if you need a lot of speciality packages. For the vast majority of people using LaTeX, they only need the core packages like the basic features of hyperref, geometry, amsmath, amsthm, and in that case, they are quite stable.
I've never had a problem recompiling documents. Yeah, you might have a problem if you're using LaTeX for a fringe use but most people don't.
I've never had a problem recompiling documents. Yeah, you might have a problem if you're using LaTeX for a fringe use but most people don't.
> Will we be able to compile a typst file made today in 10 years?
Yes! typst is actually better than LaTeX in this regard:
LaTeX: contrary to how it sells itself, it's not good at compiling old files. The TeX core is fine but the packaging story is awful. Once I found a beamer presentation about LaTeX itself, including of course some slides about the amazing backward compatibility. Well, the slides failed to compile in multiple places due to the fancy packages used by the author, which had made breaking changes between whatever they were using and my own TeX Live installation. And using an older version of TeX Live is not trivial. Another example: a few weeks ago a colleague found himself unable to compile a document that worked before the system (Linux distribution) update. It took us two hours to figure out that one of the LaTeX packages had made a change which made it incompatible with another package unless you switch the order of \usepackage. Fun!
typst: it's a single binary, statically linked. That's it! If you care about this, you can literally commit this one file (30MB or so) in your repository and it will run flawlessly in 10 years. The packaging system is very recent and still a preview, but it's already better than LaTeX since packages are imported by specific versions. And if you're worried that the typst package server will go down it's easy to mirror it locally.
> Will everybody one collaborates with also use typst? Very unlikely. A new PhD student may find it beneficial to write papers with someone who only uses latex.
That's the reason I mention. If it's the only reason left for learning LaTeX, good luck LaTeX. Very soon it will be "Will everybody one collaborates with also use LaTeX? Very unlikely".
Yes! typst is actually better than LaTeX in this regard:
LaTeX: contrary to how it sells itself, it's not good at compiling old files. The TeX core is fine but the packaging story is awful. Once I found a beamer presentation about LaTeX itself, including of course some slides about the amazing backward compatibility. Well, the slides failed to compile in multiple places due to the fancy packages used by the author, which had made breaking changes between whatever they were using and my own TeX Live installation. And using an older version of TeX Live is not trivial. Another example: a few weeks ago a colleague found himself unable to compile a document that worked before the system (Linux distribution) update. It took us two hours to figure out that one of the LaTeX packages had made a change which made it incompatible with another package unless you switch the order of \usepackage. Fun!
typst: it's a single binary, statically linked. That's it! If you care about this, you can literally commit this one file (30MB or so) in your repository and it will run flawlessly in 10 years. The packaging system is very recent and still a preview, but it's already better than LaTeX since packages are imported by specific versions. And if you're worried that the typst package server will go down it's easy to mirror it locally.
> Will everybody one collaborates with also use typst? Very unlikely. A new PhD student may find it beneficial to write papers with someone who only uses latex.
That's the reason I mention. If it's the only reason left for learning LaTeX, good luck LaTeX. Very soon it will be "Will everybody one collaborates with also use LaTeX? Very unlikely".
> LaTeX: contrary to how it sells itself, it's not good at compiling old files.
yes and no, that bit me last week, some packages decided to become incompatible. but in my case 99% of old files compile fine today.
yes and no, that bit me last week, some packages decided to become incompatible. but in my case 99% of old files compile fine today.
A legitimate concern given that Typst is still maturing. But I have at least one thing to say in its favour: you can lock the version of packages that you import. The only reason LaTeX documents full of \usepackages are reproducible ten years later is because packages are in maintenance mode, not because of well-thought-out future-proof design.
Typst is a single file binary. The preview packages are versioned too. If typst breaks the API in ten years, I'd still be able to download the old binary and make a PDF from scratch. I can't begin to imagine the complexity in installing multiple texlive distributions side by side.
Yes, but its more complicated. In my case I have slides with a number of include files, some have not changed since 2006 (just checked), one does not want to maintain slides with same ancient version of typst, and then possibly have many floating around.
For me, they need to promise full backwards compatibility.
For me, they need to promise full backwards compatibility.
That's a valid point: if you don't want a language that makes breaking changes (so you can always compile old files with the latest version), it's not the right time to use typst. It's just moving too fast now. It's currently at version 0.11. Come back when they release 1.0.
That old binary won't link with the shared libraries on your machine 10 years from now. Depends on 280 other crates. Ye gads.
"Yeah just use ancient binaries" is not a viable strategy for future-proofing.
It's a lot easier to move fast and break things when you don't care about stability.
"Yeah just use ancient binaries" is not a viable strategy for future-proofing.
It's a lot easier to move fast and break things when you don't care about stability.
$ ldd bin/typst
statically linkedYou faked this. `ldd` never prints just the text `statically linked` for a statically-linked binary.
Here's the real output.
You faked your console output.
Here's the real output.
$ ldd result/bin/typst
linux-vdso.so.1 (0x00007ffd2c4e5000)
libgcc_s.so.1 => /nix/store/28d6zz06v3mpwdbi72fdw64qmmq8rhfm-gcc-13.2.0-lib/lib/libgcc_s.so.1 (0x00007f4fe68b9000)
libm.so.6 => /nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/libm.so.6 (0x00007f4fe67d9000)
libc.so.6 => /nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/libc.so.6 (0x00007f4fe4619000)
/nix/store/7x591g0d1kydp4dci0jvksi0qbn013v3-glibc-2.38-27/lib/ld-linux-x86-64.so.2 => /nix/store/7v29y7b3b38x2hpgld698fw6k5mffam8-glibc-2.38-44/lib64/ld-linux-x86-64.so.2 (0x00007f4fe68e1000)
You faked your console output.
It's not faked. I guess the nix recipe does things differently from the official binary. Try yourself: https://github.com/typst/typst/releases/download/v0.11.0/typ...
But it's true that when I tried ldd on a trivial static binary (compiling "int main() { return 0; }" with "gcc -static a.c") I got a different message: "not a dynamic executable". I don't know why you'd get sometimes one message sometimes the other...
But it's true that when I tried ldd on a trivial static binary (compiling "int main() { return 0; }" with "gcc -static a.c") I got a different message: "not a dynamic executable". I don't know why you'd get sometimes one message sometimes the other...
[deleted]
Having to use magically-blessed (what you call "official") binaries is not a viable strategy either.
If you don't know how to build a statically linked rust binary yourself, then why bother posting about the downsides of dynamic linking?
And obviously you can also link statically against musl on glibc systems. It's just another library.
And obviously you can also link statically against musl on glibc systems. It's just another library.
Come on, it's a really good strategy if you care about this (use the official binary, or make the effort of making a static binary yourself).
And even your linked binary will probably work in 10 years, these libraries are not likely to break. See for example https://superuser.com/questions/1450027/how-exactly-a-system...
I couldn't say the same thing about the LaTeX binaries:
PS: you could edit your previous comment and/or apologize for accusing me twice of forgery.
And even your linked binary will probably work in 10 years, these libraries are not likely to break. See for example https://superuser.com/questions/1450027/how-exactly-a-system...
I couldn't say the same thing about the LaTeX binaries:
$ ldd /usr/bin/pdflatex
linux-vdso.so.1 (0x00007ffe347f7000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007e699d5bf000)
libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007e699d5a3000)
libkpathsea.so.6 => /usr/lib/x86_64-linux-gnu/libkpathsea.so.6 (0x00007e699d587000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007e699ce00000)
libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007e699d4a0000)
libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007e699d47e000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007e699ca00000)
/lib64/ld-linux-x86-64.so.2 (0x00007e699d624000)
$ ldd /usr/bin/lualatex
linux-vdso.so.1 (0x00007ffe4f8d6000)
libtexlua53.so.5 => /usr/lib/x86_64-linux-gnu/libtexlua53.so.5 (0x00007eccb87c1000)
libzzip-0.so.13 => /usr/lib/x86_64-linux-gnu/libzzip-0.so.13 (0x00007eccb9392000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007eccb8786000)
libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0 (0x00007eccb86b7000)
libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x00007eccb9376000)
libkpathsea.so.6 => /usr/lib/x86_64-linux-gnu/libkpathsea.so.6 (0x00007eccb8699000)
libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007eccb85b2000)
libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007eccb8592000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007eccb8200000)
libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007eccb8458000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007eccb8138000)
libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3 (0x00007eccb842f000)
/lib64/ld-linux-x86-64.so.2 (0x00007eccb93c5000)
libpcre.so.3 => /usr/lib/x86_64-linux-gnu/libpcre.so.3 (0x00007eccb80c2000)
libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007eccb80b4000)
libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007eccb8091000)
PS: you could edit your previous comment and/or apologize for accusing me twice of forgery.
Yeah, this is also not a fair fight.
The "will it work in 10 years?" just swayed _immensely_ in Typst's favor.
The "will it work in 10 years?" just swayed _immensely_ in Typst's favor.
Typst is exciting, but I wish their roadmap would prioritize features in common use in LaTeX like microtype rather than niche new features like style revocation.
Yeah, I'm curious if anyone with experience has comments on the typography quality of Typst, or whether that's even a focus at this point in time. There are a million document languages (DocBook, AsciiDoc, Markdown+extensions, LaTeX, etc etc) but LaTeX has the foothold it does (other than academic entrenchment) because of the output quality.
I sometimes use Typst as an intermediate renderer with Pandoc, but for my highest quality work I insist on features like protrusion. I was using LibreOffice just yesterday and actually had to check multiple times whether there was a space at the beginning of the line because the lack of protrusion support meant unsightly visual gaps.
I sometimes use Typst as an intermediate renderer with Pandoc, but for my highest quality work I insist on features like protrusion. I was using LibreOffice just yesterday and actually had to check multiple times whether there was a space at the beginning of the line because the lack of protrusion support meant unsightly visual gaps.
Probably not as developed as microtype, but they have overhang, kerning and ligatures: https://typst.app/docs/reference/text/text
Microtype features are already incorporated. See this issue:
https://github.com/typst/typst/issues/261#issuecomment-14886...
The only microtype feature currently supported in typst is overhang, and only for seven hardcoded punctuation characters. See the code here:
https://github.com/typst/typst/blob/10a3fbd174fc1a3f95937c91...
It's basically a kludge; there's a lot more work needed to actually implement even overhang properly.
https://github.com/typst/typst/blob/10a3fbd174fc1a3f95937c91...
It's basically a kludge; there's a lot more work needed to actually implement even overhang properly.
> Then the LuaTeX devs moved their efforts to LuaMetaTeX and I found myself scratching my head.
This makes sense: They're essentially “done” with LuaTeX; it works fine and is distributed with TeX Live; it's up to others to use it. Many people are in environments (submission to journals that insist on pdfTeX etc) where they cannot use LuaTeX; the LuaTeX developers cannot change that. (It has minor differences from TeX/pdfTeX but they don't seem keen to fix it.) Meanwhile for those who are willing to use a new system, they might as well simplify (remove the backward-compatibility requirements) and make a better typesetting system more suited to the needs of ConTeXt.
In other words, users can be divided into:
- those who insist/need to use pdfTeX + LaTeX
- those who are willing to try something different, for which there's ConTeXt (with lmtx) or (further afield) Typst, etc.
This makes sense: They're essentially “done” with LuaTeX; it works fine and is distributed with TeX Live; it's up to others to use it. Many people are in environments (submission to journals that insist on pdfTeX etc) where they cannot use LuaTeX; the LuaTeX developers cannot change that. (It has minor differences from TeX/pdfTeX but they don't seem keen to fix it.) Meanwhile for those who are willing to use a new system, they might as well simplify (remove the backward-compatibility requirements) and make a better typesetting system more suited to the needs of ConTeXt.
In other words, users can be divided into:
- those who insist/need to use pdfTeX + LaTeX
- those who are willing to try something different, for which there's ConTeXt (with lmtx) or (further afield) Typst, etc.
> The author is a PhD student that has been using LaTeX heavily for 10 years. But what should a new student use, and why? When the only reason to choose LaTeX is old colleagues and gatekeeping publishers, I know it's a matter of time.
From what I have seen, it's Overleaf.
Do newer students know or care what flavour of Tex Overleaf uses in the background? Not as far as I have seen.
From what I have seen, it's Overleaf.
Do newer students know or care what flavour of Tex Overleaf uses in the background? Not as far as I have seen.
"Typst Overleaf" sounds like a fine business idea to me, if you give the user the option to export TeX (so that they can then submit it to a journal).
(If you support both LaTeX and Typst, and improve the Overleaf experience somewhat -- which is definitely possible -- I can't imagine you wouldn't steal some market share from Overleaf.)
(If you support both LaTeX and Typst, and improve the Overleaf experience somewhat -- which is definitely possible -- I can't imagine you wouldn't steal some market share from Overleaf.)
The Typst webapp [1] seems like it is already pretty similar to Overleaf.
LaTeX output seems not to be on the roadmap [2], which I can respect. The amount of weirdness you would have to workaround to get good Typst to LaTeX translation sounds like a pain. I guess the hope is that the publishing industry starts adopting Typst...
[1] https://typst.app/ [2] https://github.com/typst/typst/issues/149
LaTeX output seems not to be on the roadmap [2], which I can respect. The amount of weirdness you would have to workaround to get good Typst to LaTeX translation sounds like a pain. I guess the hope is that the publishing industry starts adopting Typst...
[1] https://typst.app/ [2] https://github.com/typst/typst/issues/149
> Yes, it’s $YEAR and we’re still producing PDFs. Again, historical reasons plus the fact that most people doing maths are not necessarily very interested in computers.
I generally find PDFs to be a very agreeable way to read the sort of content LaTeX is typically used to write. And in writing it myself I don't need to think about what weird layout issues someone else might encounter when viewing my content. There are certainly accessibility issues with PDFs, but also ways to mitigate that[0].
[0] https://libguides.lib.msu.edu/c.php?g=995742&p=8207771
I generally find PDFs to be a very agreeable way to read the sort of content LaTeX is typically used to write. And in writing it myself I don't need to think about what weird layout issues someone else might encounter when viewing my content. There are certainly accessibility issues with PDFs, but also ways to mitigate that[0].
[0] https://libguides.lib.msu.edu/c.php?g=995742&p=8207771
> Yes, we are aware of typst. I think it’s cool, but C++ hasn’t replaced C, Rust hasn’t replaced C++, Typst is unlikely to replace LaTeX. Likewise, many are aware of LuaTeX, but, again, the entrenching of a 40-odd year system is not to be underestimated. I am rooting for typst, anyway, and hope it finds its place. A good place to start would be to provide a compilation toolchain from typst to TeX, if they really want to replace TeX.
Pandoc[0] can convert Typst to LaTeX.
IMO If you are able to write in Typst, write in Typst, it's so much better and readable. Your final LaTeX3 macro are hard to read and difficult to parse with the eyes... Also Typst is easier to learn.
[0] -- https://pandoc.org/try/
Pandoc[0] can convert Typst to LaTeX.
IMO If you are able to write in Typst, write in Typst, it's so much better and readable. Your final LaTeX3 macro are hard to read and difficult to parse with the eyes... Also Typst is easier to learn.
[0] -- https://pandoc.org/try/
pandoc is seriously under-powered for the kinds of things that LaTeX and Typst can do. Much of the information in Typst/LaTeX source code would simply be ignored during the conversion. It is fine for simple documents, but cannot handle a lot of stuff.
Pandora offers a superset of LaTeX and any other markup languages as long as you’re not using it for final rendering. I have a Markdown+LaTeX project I’m working on and try to write mostly in markdown, but can drop down into LaTeX in-line if need be. I compile a tex file with Pandoc and render with pdflatex, bibtex, makeindex, etc., etc.
This is not the workflow being discussed. Yes, you can use Pandoc Markdown (in which you can embed LaTeX) and then Pandoc can parse the markdown and produce a LaTeX file. But the actual typesetting is still done by LaTeX; here Pandoc is basically just a preprocssing step.
what was being discussed is using Pandoc to convert from Typst to LaTeX, which it can't really do because its internal document representations are not as expressive as either Typst or LaTeX.
what was being discussed is using Pandoc to convert from Typst to LaTeX, which it can't really do because its internal document representations are not as expressive as either Typst or LaTeX.
Come on, be serious.
Pandoc can "convert" html to things too, but you wouldn't use it as a web browser.
Pandoc can "convert" html to things too, but you wouldn't use it as a web browser.
I can't remember not being disappointed in pandoc. I used to try pandoc first for file conversions but at this point I try it last, only after exhausting format specific tools first. For example, the conversion from latex to html in pandoc is a joke, just unusable garbage, compared to the results of tex4ht.
A nice intro to making macros, which is one of the most powerful parts of LaTeX indeed.
Autoref itself seems a fine way of messing up your references and making your source code less readable. The beauty of naming is that you have the context at hand. Moving around blocks of text, or adding and removing text, happens throughout the process. With autoref, you now have to remember to _sometimes_ update the refs or get subtly different references. I wouldn't trust myself to get that right.
Autoref itself seems a fine way of messing up your references and making your source code less readable. The beauty of naming is that you have the context at hand. Moving around blocks of text, or adding and removing text, happens throughout the process. With autoref, you now have to remember to _sometimes_ update the refs or get subtly different references. I wouldn't trust myself to get that right.
Markdown does not specify how to add labels and cross-references for figures, equations, tables, etc. Many moons ago, I asked about them on the CommonMark forum[1] and described a syntax that was general and internationalizable. Given that CommonMark has frozen the Markdown specification, I implemented a consistent label and cross-reference syntax for my editor[2], KeenWrite[3]. These labels and cross-references are translated to XHTML, then transformed from XHTML into ConTeXt macros that are subsequently typeset.
[1]: https://talk.commonmark.org/t/cross-references-and-citations...
[2]: https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/docs/ref...
[3]: https://keenwrite.com/
[1]: https://talk.commonmark.org/t/cross-references-and-citations...
[2]: https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/docs/ref...
[3]: https://keenwrite.com/
I still wonder why anyone would create such awful grammar for a programming language. Considering LaTeX's initial release was 40 years ago, there were certainly other programming languages from which to draw inspiration.
And I certainly don't believe that LaTeX DSL was the most suitable solution for solving typesetting problems.
And I certainly don't believe that LaTeX DSL was the most suitable solution for solving typesetting problems.
I would say that the TeX language was designed for the final user to add the "last mile", not for piling layers of macrosubstitution on top of something akin to lambda calculus. As amazing a feat of engineering LaTeX is, it has abused the TeX language beyond its natural limits. The price paid in complexity for abstraction was high. But the TeX language itself is a tiny elegant language.
LaTeX grammar is actually very good to type and quite powerful and compact. It's not a programming grammar, it's a markup language.
The problem with LaTeX was always the lack of underlying proper programming language and data model. The syntax always has been excellent.
The problem with LaTeX was always the lack of underlying proper programming language and data model. The syntax always has been excellent.
The syntax is full of inconsistencies and it generally user-unfriendly: why is _ allowed only in math mode? Why can't macros have numbers in their names? Why does a simple thing like bolding text require a \textbf?
LaTeX is powerful and I use it every day, but let's not pretend it's got qualities it doesn't.
LaTeX is powerful and I use it every day, but let's not pretend it's got qualities it doesn't.
> why is _ allowed only in math mode?
Because it has different meaning in different context. It's a nice shorthand for subscript in math mode and you still need it as an underscore when you write code or normal text.
> Why can't macros have numbers in their names?
I give you that. That's due to underlying lack of proper programming language.
> Why does a simple thing like bolding text require a \textbf?
What else do you want there? The markdowns * has famously bitten me multiple times when it interfered with my multiplication in math (math + mathjax). Or when the bold needs to cover a full paragraph. I don't have a better suggestion. I'll be happy to hear another one.
Because it has different meaning in different context. It's a nice shorthand for subscript in math mode and you still need it as an underscore when you write code or normal text.
> Why can't macros have numbers in their names?
I give you that. That's due to underlying lack of proper programming language.
> Why does a simple thing like bolding text require a \textbf?
What else do you want there? The markdowns * has famously bitten me multiple times when it interfered with my multiplication in math (math + mathjax). Or when the bold needs to cover a full paragraph. I don't have a better suggestion. I'll be happy to hear another one.
[deleted]
Having studied a lot of the TeX source code and re-implemented portions of it, my theory is that it's the result of the TeX language evolving organically in a software development environment in which large scale refactoring is impossible. (Knuth didn't have source control, or unit tests, and the language he wrote TeX in has little-to-no support for meaningful abstractions. All of these make refactoring safely hard or impossible.) If you can't refactor, but still want to add a new feature, your only option is to implement things in a hacky way on top of existing features. This then bleeds into the TeX language itself.
I would say that the TeX language was designed for the final user to add the "last mile", not for piling layers of macrosubstitution on top of something akin to lambda calculus. As amazing a feat of engineering LaTeX is, it has abused the TeX language beyond its natural limits. The price paid in complexity for abstraction was high.
LaTeX grammar makes much more sense when you spend some time using raw TeX with no macros at all - it's surprisingly capable on its own and the LaTeX becomes much more obviously "slight improvements".
Many things people think of as LaTeX are actually just TeX.
Many things people think of as LaTeX are actually just TeX.
The reason for LaTeX is the output quality, not the input.
Real LaTeX users don't use LaTeX to write documents.
Real LaTeX users don't use LaTeX to write documents.
whatever -> pandoc -> LaTeX -> perfect document
^
|
LaTeX template ----+I was formerly in academia and I've never seen anyone use Pandoc. I've seen lots of people using straight LaTeX though.
Nice in theory, in practice you have LaTeX tools with synctex, command, environment and references autocompletion, live math preview, proper syntax highlighting, jump to error line, etc. Nothing like that is available for pandoc markdown AFAIK, except perhaps for Quarto, which may have its uses but is too slow for small/medium sized documents and its tooling is not that capable anyway. Besides, it adds yet another complex layer on top of an already way too layered stack.
> Real LaTeX users don't use LaTeX to write documents.
Really? That's a bold claim. Got any source or stats for that?
I assure you I am a real LaTeX user and I use LaTeX to write documents. I see everyone around me doing the same.
Really? That's a bold claim. Got any source or stats for that?
I assure you I am a real LaTeX user and I use LaTeX to write documents. I see everyone around me doing the same.
Most of the things that need to be written in LaTeX (math) cannot be written in any other language yet.
There are lots of applications that can be used to write math that is converted into LaTeX equations. You can also use MathML -> Latex
The equation subset is the best part of LaTeX syntax and so many people learn it. It's very compact compared to alternatives.
The equation subset is the best part of LaTeX syntax and so many people learn it. It's very compact compared to alternatives.
I find the typst syntax nicer and more compact: https://typst.app/docs/guides/guide-for-latex-users/#maths
I was initially suprised to see that the typst devs chose to go with their own syntax, but I'm now very happy they did.
I was initially suprised to see that the typst devs chose to go with their own syntax, but I'm now very happy they did.
I would be interested to see how the formula looks for a more complicated equation. For example, Eq 3.12 or 3.31 in the link https://arxiv.org/pdf/2203.09346.pdf
here's 3.31:
$
cal(C)(M) = cal(E)_T^t (theta, cal(S)_t)^2 + C_t M_t^(-2/d)
+ cal(E)_T^"PDE" (theta_t, cal(S)_"int")^2 + C_"PDE" M_"int"^(-2/(d+1)) \
+ C_1T^(1/2) [cal(E)_T^"div" (theta, cal(S)_"int") + C_"div" M_"int"^(-1/(d+1))
+ (1+nu)(cal(E)_T^s (theta, cal(S)_s) + C_s M_s^(-1/d))]
$
It should be in the LaTeX sources on the website. This does look much more compact though.
Just to now push it a little. I wonder if I can make the `1/(d+1)` in the superscript be not a real fraction but inline fraction.
Just to now push it a little. I wonder if I can make the `1/(d+1)` in the superscript be not a real fraction but inline fraction.
Here are the LaTeX versions from the article source:
\begin{align}
\begin{split}
\mathcal{C}(M) = &\: \Et^t(\theta,\S_t)^2
+ C_t M_t^{-\frac{2}{d}}
+ \Et^\pde(\theta,\S_\inte)^2 +C_\pde
M_\mathrm{int}^{-\frac{2}{d+1}}\\&+ C_1{T}^{\frac{1}{2}}
\bigg[\Et^\divv(\theta,\S_\inte) +C_\divv
M_\mathrm{int}^{-\frac{1}{d+1}}+(1+\nu)
big( \Et^s(\theta,\S_s) + C_s M_s^{-\frac{1}{d}}\big)\bigg],\\
\end{split}
\end{align}
\begin{align}
\begin{split}
\norm{(u_0)_j-\hu_j(t=0)}_{L^2(\mathbb{T}^d)} &\leq
\norm{u_j-\hu_j}_{L^2(\partial \Omega)} \\&\leq
\sqrt{\frac{2\max\left\{2h_\Omega,d+1\right\}}
{\rho_\Omega}}\norm{u_j-\hu_j}_{H^1(\Omega)}\\
&\leq \sqrt{\frac{2\max\left\{2h_\Omega,d+1\right\}}
{\rho_\Omega}}C_{1,k,d+1, u_1} \lambda_{1}(N)N^{-k+1},
\end{split}
\end{align}
Yup. Much more verbose. However, I must admit, all the unescaped names in Typst leaves me with any eerie feeling. It seems a ground ripe for a name conflict at some point. Or a bottleneck for customization like calligraphic C or script C.
Thanks for your effort. With this example, I started testing typst again and it does look to have improved quite a bit. And it is of course extremely fast.
You're welcome, I hope you'll like it this time!
should be close to 3.12
$
norm((u_0)_j-hat(u)_j (t=0))_(L^2 TT^d) &<= norm(u_j - hat(u)_j)_(L^2 delta Omega) \
&<= sqrt(2 max {2h_Omega,d+1} / rho_Omega) norm(u_j - hat(u)_j)_(H^1 (Omega)) \
&<= sqrt(2 max {2h_Omega,d+1} / rho_Omega) C_(1,k,d+1,u_1) lambda_1 (N) N^(-k+1)
$Thanks for your effort. This was instructive. Seems there's a decent alternative to LaTeX. May be over time it becomes as powerful in all respects.
What nonsense lol. Nobody in computer science writes their papers in markdown.
Am i missing something, or is this useless when you want to refer to an equation from "the past"? I find myself doing that often. For example a methods section might pose an optimization problem, then the experiments section a page or two later says "we solve the optimization `\eqref{main-problem}` using Solver X".
Nice piece, and his comment on typst is spot on. I would love for typst to displace LaTex, I hate LaTex and use it every day, and deep inside know it will never go away, unless a much better programmer than I writes a LaTex -> typst converter that covers all the corner cases. One can always hope.
> but C++ hasn’t replaced C, Rust hasn’t replaced C++, Typst is unlikely to replace LaTeX.
Weird conclusion, because LaTeX has mostly replaced TeX.
There is a nice symmetry here:
C -> C++ -> Rust ~ Typst <- LaTeX <- TeX
Weird conclusion, because LaTeX has mostly replaced TeX.
There is a nice symmetry here:
C -> C++ -> Rust ~ Typst <- LaTeX <- TeX
> It’s weird I even have to say this, but don’t stalk me and email me at my personal address.
I am not sure of what happened, and it must have been unpleasant, but someone going up on your website hierarchy, they reach https://commutative.xyz/~miguelmurca/, they click the only link, and you personally list your profiles there, including email, github and insta. It is OK if someone contacts you for whatever reason on addresses and profiles that you explicitly shared.
> If you email me anywhere else, I will not respond. I also cannot force you to follow basic etiquette if you do write, but it would be appreciated.
This is rude, it looks bad in the article, and you are the one who doesn't follow basic netiquette.
I am not sure of what happened, and it must have been unpleasant, but someone going up on your website hierarchy, they reach https://commutative.xyz/~miguelmurca/, they click the only link, and you personally list your profiles there, including email, github and insta. It is OK if someone contacts you for whatever reason on addresses and profiles that you explicitly shared.
> If you email me anywhere else, I will not respond. I also cannot force you to follow basic etiquette if you do write, but it would be appreciated.
This is rude, it looks bad in the article, and you are the one who doesn't follow basic netiquette.
Hey, hope you enjoyed the article itself.
I'm sorry if you felt that addendum was aggressive. However, I still feel like I'm justified in making it absolutely clear how (and if) I want to be contacted. I am in a complicated position where I'm speaking to a niche -- not an imaginary niche, by any means -- but actually addressing every reader. In the face of this, my option was to clearly state my boundaries, regardless.
I list an email address at the end of every article, for the purposes of discussing the content of the article. I add a "+ext" to every email I list (including the one on my personal home page). I had people ignore the email I stated in the article, find a different email, strip it of the + tags, and email me there in a foreign language and opening with "I assume you speak X" (presumably because of my name?).
I disagree with you that it's fair game to do the above. OSINT is, well, legal, and I'm not trying to hide my identity, clearly. But I would still be upset if, for example, someone wrote to my university email (which is not hard to find out, by your own procedure) regarding this post.
Nonetheless, again, it is not my goal to sound rude, but simply to set boundaries and expectations. I will remove the second sentence towards this goal, but stand by its objective meaning, and will keep the rest as is.
Cheers
I'm sorry if you felt that addendum was aggressive. However, I still feel like I'm justified in making it absolutely clear how (and if) I want to be contacted. I am in a complicated position where I'm speaking to a niche -- not an imaginary niche, by any means -- but actually addressing every reader. In the face of this, my option was to clearly state my boundaries, regardless.
I list an email address at the end of every article, for the purposes of discussing the content of the article. I add a "+ext" to every email I list (including the one on my personal home page). I had people ignore the email I stated in the article, find a different email, strip it of the + tags, and email me there in a foreign language and opening with "I assume you speak X" (presumably because of my name?).
I disagree with you that it's fair game to do the above. OSINT is, well, legal, and I'm not trying to hide my identity, clearly. But I would still be upset if, for example, someone wrote to my university email (which is not hard to find out, by your own procedure) regarding this post.
Nonetheless, again, it is not my goal to sound rude, but simply to set boundaries and expectations. I will remove the second sentence towards this goal, but stand by its objective meaning, and will keep the rest as is.
Cheers
The sentiment you have is fine, but if you really wanted to you could rewrite it like this:
If you wish to contact me by email, by all means do so to miguelmurca+autoref [æt] cumperativa.xyz - I may not be able to respond. If I don't please don't try to find other emails to send to me, as I'll not respond to those, either, and just delete them. This post is in English. If you wish to write me, please do so in English. Other languages will be deleted.
(The key is assholes won't read it anyway, so there's no reason to snark them, just delete.)
If you wish to contact me by email, by all means do so to miguelmurca+autoref [æt] cumperativa.xyz - I may not be able to respond. If I don't please don't try to find other emails to send to me, as I'll not respond to those, either, and just delete them. This post is in English. If you wish to write me, please do so in English. Other languages will be deleted.
(The key is assholes won't read it anyway, so there's no reason to snark them, just delete.)
> However, I still feel like I'm justified in making it absolutely clear how (and if) I want to be contacted.
> I list an email address at the end of every article, for the purposes of discussing the content of the article.
I am maybe blind, or because of adblockers, or because of cloudflare, but they don't show up for me, in edge, and in firefox.
You definitely should make it easy for the people to contact you in your preferred way. Put it under the articles, under the blog home page https://commutative.xyz/~miguelmurca/blog/ , and maybe under your HN about section.
My previous message was under the impression that you don't put a contact info in this blog, and I tried to demonstrate that getting messages at your other contact is your fault, not the public's fault or "HN reader"'s fault. (I wonder if
> I list an email address at the end of every article, for the purposes of discussing the content of the article.
I am maybe blind, or because of adblockers, or because of cloudflare, but they don't show up for me, in edge, and in firefox.
You definitely should make it easy for the people to contact you in your preferred way. Put it under the articles, under the blog home page https://commutative.xyz/~miguelmurca/blog/ , and maybe under your HN about section.
My previous message was under the impression that you don't put a contact info in this blog, and I tried to demonstrate that getting messages at your other contact is your fault, not the public's fault or "HN reader"'s fault. (I wonder if
But, 1. famously, HN can be quite predictable in some of their responses (by what I expect is, essentially, a meme effect), and 2. I’ve had some unexpected experiences resulting from previously reaching FP in HN.
The article itself is great.
> I will remove the second sentence towards this goal
Your critic decided their negative emotions about a miniscule matter are more important than the actual contents of your post and worthy of derailing the conversation. And then they called you rude.
There is really no need to cater to such people. It obviously has zilch to do with you in actuality.
> I will remove the second sentence towards this goal
Your critic decided their negative emotions about a miniscule matter are more important than the actual contents of your post and worthy of derailing the conversation. And then they called you rude.
There is really no need to cater to such people. It obviously has zilch to do with you in actuality.
[deleted]
Well here's the process I went through in the last few years:
I found out about LuaTeX, saw it was supposed to replace pdfTeX and thought the future of TeX was bright.
Then I saw the continued efforts in LaTeX3 and thought that was weird and wasteful: code now looks even worse with all \ExplSyntaxOn ... \ExplSyntaxOff sections and the new command syntax like \exp_args:Ne. If you're going to have a mix of two languages anyway, it makes much more sense for the second language to be a a minimal but real programming language like Lua.
Then the LuaTeX devs moved their efforts to LuaMetaTeX and I found myself scratching my head.
Then I spent some time with typst. Now I don't care what happens in TeX land... The experience with typst is incomparably better, and the pace of development is high in both the core language and the ecosystem. Features that took a decade to be fleshed out in LaTeX are sprouting like mushrooms in typst. It's not a fair fight.
The author is a PhD student that has been using LaTeX heavily for 10 years. But what should a new student use, and why? When the only reason to choose LaTeX is old colleagues and gatekeeping publishers, I know it's a matter of time.