Texpad 1.9 has many changes from the 1.8 series, most notably a reworking of the iOS interface to bring all the features from Texpad macOS to Texpad iOS. The iOS ecosystem has gained a file management system, more powerful devices, and even keyboard/mouse devices in the last few years. With iOS capable of replacing a laptop now, we have updated Texpad iOS to take advantage of these new features, and for the first time make it no less capable than its desktop sibling.

As well as adding new features, in Texpad 1.9 we have also made the old features more efficient. Texpad 1.9 on both macOS and iOS runs faster using less memory than the 1.8 series. The biggest gains have come from integrating the internal TexpadTeX typesetter with the graphics card using Apple’s Metal framework. This post is a record of the history and development of TexpadTeX to give you an idea how it works under the hood.

Beginnings of TexpadTeX

Traditionally, to typeset with LaTeX your editor saves the .tex files to disk, and runs a separate program such as pdfLaTeX or XeLaTeX, which reads the .tex files and writes its output to the disk as a .pdf file. This .pdf is then loaded by the viewer, often part of the editor, and displayed.

A lot of data is read and written to disk in this workflow. Access times for even the fastest Solid State Drives are substantially slower than reading and writing to a program’s memory, so it slows down the process.

The design of iOS prohibits launching external programs in this way, so when building Texpad iOS we were forced to integrate LaTeX into Texpad. We forked KerTeX, a minimal, permissively licensed TeX distribution, to create the first version of TexpadTeX.

An unintended benefit was that the TexpadTeX typesetter could take its input directly from the editor and output it directly to the viewer. Removing the disk read and write greatly improved the efficiency of the typeset process. This was an early example for us of how an integrated typesetter could improve a user’s experience with Texpad, but it was difficult to progress due to the way TeX was written.

Converting TeX to C++

TeX, the core on which LaTeX is built, was written by Donald Knuth in the 70s. He did so in WEB, a fascinating programming system that blends Pascal code and documentation to create something in between a computer program and an essay. Unfortunately, WEB never caught on, and today it is almost exclusively used by TeX, and related programs such as BibTeX and MetaFont. No modern development tools support it, most relevantly Apple’s Xcode, which we use to build Texpad.

Texpad’s editor and viewer were written in Objective C++, a very different programming language to WEB, and any interaction between Texpad and TexpadTeX needed to be carefully, and time consumingly, bridged. Further, the programming language barrier stopped us from using the tooling in Xcode we use to debug and optimise Texpad, to do the same for TexpadTeX. We chose to translate TexpadTeX into the C++ programming language, so it could interact easily with the remainder of Texpad.

We wrote a tool to parse the original WEB source and extract the Pascal programming code, which was converted to modern C++. A difficulty was to preserve the prose part of the original WEB sources, along with its goldmine of information on the workings of TeX. We tagged all elements of the parse tree with the documentation leading up to it, and that was converted to C++ comments when we wrote the code out. As a result for the most part Knuth’s elucidating, and often amusing, essay is in tact in the C++ translation.

Live typeset

Divorced from the original WEB codebase, there was no longer a boundary between TexpadTeX and the rest of Texpad, and we were able to edit, debug and optimise the TexpadTeX code much more easily than before. Soon we had added extensions to TexpadTeX in line with XeTeX/LuaTeX’s Unicode extensions and it supported modern fonts through fontspec.

Even more excitingly the deeper editor/typesetter integration allowed us to move from the traditional typeset model to “Live typeset” in Texpad 1.8. Rather than starting at the beginning of a document, and working all the way to the end with each typeset, TexpadTeX could consult with the editor and the viewer, and typeset only the part of the document between a user’s cursor, and the end of what is visible in the output viewer. By typesetting just what the user needs to preview their work, this incremental model greatly reduces the time required for a typeset. This allowed us to run a typeset with each keystroke, which in most cases gives a user, an almost realtime preview of the output. The downside of moving from a typeset once every few minutes, to more than one a second, is that the extra computation made Texpad thirsty for battery power.

With TexpadTeX in C++, and fully integrated with the rest of the Texpad codebase, we we able to use Xcode’s energy profiler to analyse this problem. Although we weren’t creating an actual PDF on disk, we did create a similar intermediate representation when typesetting, which was passed to the viewer to decode and display. Although fast in comparison to the alternatives, these extra steps dominated the time required by the typesetting process, and increased both the CPU and memory footprint of Texpad.

Metal framework

In Texpad 1.9, we have altered the architecture of TexpadTeX so that rather than creating this intermediate representation, it uses Apple’s Metal framework to write the characters and shapes of the output directly into graphics memory. There is no longer a separate step where the viewer decodes the output of TexpadTeX and feeds it to a display framework, the data is in memory ready for the graphics card to use. This works especially well with Apple’s A-series, and M-series, System on a Chip processors, as the CPU and the GPU explicitly share memory, reducing any possibility that Metal might need to copy the data to send it to the graphics card.

On top of the performance improvements, moving the display of the output to the graphics card has had side benefits for users, such as smoother zoom and animations in the viewer, and a new dark mode for the viewer. A common request since Apple introduced dark mode in Mojave has been some way to make the bright white PDF output consistent with the dark theme. Texpad’s new viewer post-processes the output in the graphics card to swap light and dark colours, matching them precisely with the foreground and background colours selected for the editor theme as seen in the screenshot below. Although useful for text and diagrams, beta testers mentioned it could warp the colour of photographs, so it can be turned off for such images.

Public beta

We are coming to the end of a long beta now, fixing the final few tests, and we will be releasing Texpad 1.9 soon. If you are interested in beta testing please get in touch with us at support@vallettaventures.com, if not, your regular copy of Texpad will update automatically before long.