Are there plans to support the TikZ frontend for l3draw?

Question

In is current stage, l3draw is rather cumbersome to use. The same applies to pgf. Since both are background layers, I guess there are not really meant to be used extensively by regular users.

Are there plans to support TikZ as a frontend for l3draw?

This would have quite a few advantages for the end user, such as better numerical precision. I don't think that a new frontend would be a good idea, since TikZ has a vast user base and there are so many useful libraries.

Answer 1

Short answer: no.

One of the core aims of work on expl3 is to provide a way of programming LaTeX that does not rely on the mix of TeX primitives, internal LaTeX macros and documents programmer/designer/document commands that are seen in 'classical' LaTeX2e packages. Much of that is about provided the core programming layer, but extends to other areas that otherwise need primitive support.

Creating drawings using PDF/PostScript/SVG/... constructs at the most basic level is carried out using one or more primitives: \special, \pdfliteral, etc. Those clearly fall into 'TeX primitive' layer. What l3draw aims to do is abstract sufficiently that basic drawing constructs can be created using documented expl3 interfaces. The work started when the team were still imagining a future LaTeX format independent of LaTeX2e, but the central idea remains applicable now that this goal has been moved away from.

As such, l3draw could be used to implement various higher-level interfaces: for example, one can relatively easily make something that looks like picture mode. However, there are a couple of important considerations for anything TikZ-like

• Whilst l3fp is relatively fast for what it achieves, the dim-based approach in pgf is faster, particularly when skipping parsing and doing low-level calculations: this would be significant for a full-scale l3draw-based TikZ approach
• The TikZ interfaces are very much non-standard for LaTeX: as such, any code from the team is never likely to work the same way as TikZ
• Whilst pgf and l3draw do have a similar API, the dimension calculations in l3draw are done by expansion, whereas in pgf they are non-expandable and set the (documented) return dim registers \pgf@x and \pgf@y. TikZ is implemented not strictly using just the pgf documented macro interfaces but also using those registers and other lower-level code. As such, one cannot 'drop in' l3draw functions to replace pgf ones.
• l3draw does not (yet) cover all of pgf's functionality. There are some areas awaiting the outcomes of work on PDF structures (such as support for masks). There are also pgf-level ideas that one can argue do not directly need kernel-level expl3 support, most notably nodes.

As such, l3draw is best seen as a way for package authors to build functionality using a code-level interface in packages already using expl3. At some stage we may load l3draw as part of l3kernel, but there is no pressure to do that at the moment.