• Not all the source code is on GitHub; crucially their modification of the TeX engine seems to be distributed only as the two `.wasm` binary files). Not sure if they plan to share more or not.
• As mentioned in the FAQ/docs page, this is the work of just two people from New Zealand (Gerald Weber and Elliott Wen), and they have a paper about it from 2018 (“SwiftLaTeX: Exploring Web-based True WYSIWYG Editing for Digital Publishing”, DOI: 10.1145/3209280.3209522). Based on a quick skim so far, the paper looks fantastic, looking forward to reading it in more detail.
• In the paper, Figure 5 and the surrounding text describe how TeX was modified (the part of most interest to me); it's really clever! To avoid modifying the data structures and introducing new bugs, they hook only into TeX's internal allocation functions for tokens. (TeX as originally written by Knuth does not use malloc() or equivalent; it does all its own allocation out of giant arrays called "mem" and "str".) They can then look up this bookkeeping when the token lists are being shipped out to PDF format.
• Looks like it has some limitations as far as PS/PDF specials goes (aka “drivers” in the TeX world), so TikZ or tcolorbox don't work too well for example. However my guess is that this is just an issue with their PDF rendering (per the paper they use something like Pdf2htmlEX rather than pdf.js, for speed), and not a fundamental issue.
• But otherwise most of the standard LaTeX features and packages seem to work (labels and cross-references, etc); you can \usepackage anything and it will download the corresponding files but no data leaves your system; everything happens in the browser. Heck I even pasted in xii.tex (without the final "jbye") and it works (can click on “partridge” in the PDF and go to the corresponding part of the source).
• This sort of WYSIWYG editing for LaTeX has been done in a couple of proprietary systems before (BaKoMa TeX / Texpad), and some ancient systems as well (VorTeX), but they've been buggy in my limited experience. There was also a very impressive demo at this year's TUG meeting, by David Fuchs (who Knuth described as his “right-hand man” on the TeX project). All these projects have had to grapple with the same issues (achieving quiescence etc). This one seems to have its share of minor bugs (some artefacts seem to be visible in their published paper too!), so e.g. a feature to fully update the PDF after a (very) long typing pause (or manual user request) seems desirable. Nevertheless it's very impressive as it is.
• I think some sort of engagement with the TeX community (the mailing lists at http://tug.org/texlive/lists.html etc) may help: it appears their code is currently based on pdfTeX; they should probably consider XeTeX / LuaTeX as well (given that the doc page at https://swiftlatex.readthedocs.io/en/latest/ mentions “Lack of Unicode Support”). There are experts there with some idea of corner cases, the weird things that users want, etc. Hope this becomes part of the TeX mainstream (what little there is of it) to benefit all users (good typesetting for everyone!) and not some sort of edge case that dies when/if the authors lose interest.
Overall, am really awestruck by all this. Congratulations and good luck to the authors!
I'm interested if it can be self hosted for using in a commercial environment.
This would be a killer feature for increasing Latex adoption at corporations stuck with MS Word.
Even with AGPL-3 a corporation could still use it internally (which I think was the GP’s point). It can’t be used to start an Overleaf competitor though, since you’d have to release all of your changes.
Iirc AGPL states that basically you must make the source to your entire application available to users, both the client and server side. I believe many misinterpret this to mean your entire application must be open sourced publicly, but this is not entirely true. If a corporation develops something using AGPL code and none of their users are external to the company, then they are under no obligation to distribute their source (or they must distribute it to themselves, which is effectively the same thing).
I think GP is saying that you could not use it as a basis for proprietary software but you could build on it it and sell it to people as long as you published your modifications.
> • Not all the source code is on GitHub; crucially their modification of the TeX engine seems to be distributed only as the two `.wasm` binary files). Not sure if they plan to share more or not.
PdfTeX is GPL-licensed, so if this is derived from pdfTeX (is it?), I assume they'd be required to make their source available. (Note that the GPL says that "the source code for a work means the preferred form of the work for making modifications to it", which I don't think would be a .wasm binary file.)
TeXmacs is also completely distinct from TeX!
It does use TeX-inspired layout algorithms, with modifications to make them better fit real-time typesetting as you type.
It's also striving to be an environment for interaction with other tools, (not unlike Jupyter Notebook).
If you want a structured scientific web editor with collaboration, check out also https://www.fiduswriter.org/. Built on top of ProseMirror.
But Fidus is closer to "WYSIWYM" like LyX — structured editing with "acceptable" typesetting, and TeX export for high-quality typesetting.
TeXmacs shoots for true "what you get" high-quality typesetting as you edit. Mind you, the edited model is structured in "what you mean" spirit (with quite good UX to "see" the structure), not flat "slap formatting on characters" model typical of WYSIWYG editors.
Technically, yes. It's possible to easily disassemble the wasm into wasm code. The good part is that now the target format is a standard instead of something like asm.js or minimized javascript.
We reached a point where everyone was distributing browser code as minimized javascript to the point where reading the source of web pages wasn't really meaningful anymore. At least this way you can technically read the webassembly in something that is standardized. Anything can still be obfuscated though. The idea of a pure, readable webpages is long gone, but if they made the code clean and didn't do any trickery then it's still possible to read if you know the format.
Why you'd think that? It's assembly meant to run on a virtual machine in browsers. The textual representation is similar to your normal assembly code, albeit a bit more high-level.
WebAssembly is designed to be pretty-printed in a textual format for debugging, testing, experimenting, optimizing, learning, teaching, and writing programs by hand. The textual format will be used when viewing the source of Wasm modules on the web.
Will WebAssembly support View Source on the Web?
Yes! WebAssembly defines a text format to be rendered when developers view the source of a WebAssembly module in any developer tool. Also, a specific goal of the text format is to allow developers to write WebAssembly modules by hand for testing, experimenting, optimizing, learning and teaching purposes. In fact, by dropping all the coercions required by asm.js validation, the WebAssembly text format should be much more natural to read and write than asm.js. Outside the browser, command-line and online tools that convert between text and binary will also be made readily available. Lastly, a scalable form of source maps is also being considered as part of the WebAssembly tooling story.
• This seems to be their main page: https://www.swiftlatex.com/
• Not all the source code is on GitHub; crucially their modification of the TeX engine seems to be distributed only as the two `.wasm` binary files). Not sure if they plan to share more or not.
• As mentioned in the FAQ/docs page, this is the work of just two people from New Zealand (Gerald Weber and Elliott Wen), and they have a paper about it from 2018 (“SwiftLaTeX: Exploring Web-based True WYSIWYG Editing for Digital Publishing”, DOI: 10.1145/3209280.3209522). Based on a quick skim so far, the paper looks fantastic, looking forward to reading it in more detail.
• In the paper, Figure 5 and the surrounding text describe how TeX was modified (the part of most interest to me); it's really clever! To avoid modifying the data structures and introducing new bugs, they hook only into TeX's internal allocation functions for tokens. (TeX as originally written by Knuth does not use malloc() or equivalent; it does all its own allocation out of giant arrays called "mem" and "str".) They can then look up this bookkeeping when the token lists are being shipped out to PDF format.
• Looks like it has some limitations as far as PS/PDF specials goes (aka “drivers” in the TeX world), so TikZ or tcolorbox don't work too well for example. However my guess is that this is just an issue with their PDF rendering (per the paper they use something like Pdf2htmlEX rather than pdf.js, for speed), and not a fundamental issue.
• But otherwise most of the standard LaTeX features and packages seem to work (labels and cross-references, etc); you can \usepackage anything and it will download the corresponding files but no data leaves your system; everything happens in the browser. Heck I even pasted in xii.tex (without the final "jbye") and it works (can click on “partridge” in the PDF and go to the corresponding part of the source).
• This sort of WYSIWYG editing for LaTeX has been done in a couple of proprietary systems before (BaKoMa TeX / Texpad), and some ancient systems as well (VorTeX), but they've been buggy in my limited experience. There was also a very impressive demo at this year's TUG meeting, by David Fuchs (who Knuth described as his “right-hand man” on the TeX project). All these projects have had to grapple with the same issues (achieving quiescence etc). This one seems to have its share of minor bugs (some artefacts seem to be visible in their published paper too!), so e.g. a feature to fully update the PDF after a (very) long typing pause (or manual user request) seems desirable. Nevertheless it's very impressive as it is.
• I think some sort of engagement with the TeX community (the mailing lists at http://tug.org/texlive/lists.html etc) may help: it appears their code is currently based on pdfTeX; they should probably consider XeTeX / LuaTeX as well (given that the doc page at https://swiftlatex.readthedocs.io/en/latest/ mentions “Lack of Unicode Support”). There are experts there with some idea of corner cases, the weird things that users want, etc. Hope this becomes part of the TeX mainstream (what little there is of it) to benefit all users (good typesetting for everyone!) and not some sort of edge case that dies when/if the authors lose interest.
Overall, am really awestruck by all this. Congratulations and good luck to the authors!