Katex: support \setlength and measurement constants

[kevinbarabash]

Add a dictionary that tracks the values of

• thinmuskip
• medmuskip
• thickmuskip
• jot
• arraystretch
• baselinestretch
• arraycolsep

[edemaine]

Would be also nice to support \arraystretch (see buildHTML.js) and \arraycolsep (in the same buildHTML function, though more spread out).

Note that \arraystretch is special, as it needs to be modified via \def or \renewcommand.

[edemaine]

Some fun examples of playing with muskip. Though that's mainly relevant to plus and minus settings which we don't currently support, we'll need to keep in mind that we really ought to support things like \setlength\arraycolsep{0.5\arraycolsep} (something I do a lot), and possibly \addtolength\arraycolsep{-0.5em}.

There's also a question of whether we'd want to support TeX-style \arraycolsep=0.5\arraycolsep and especially \global\arraycolsep=0.5\arraycolsep. If we support global and local setting, we might need another data structure.

But even focusing on support for local lengths, I'm not quite sure where this ought to go. Perhaps it could go in the options dictionary in buildHTML, e.g. as a lengths dictionary within? We'll need to parse \setlength as defining an implicit group, so that e.g. the following works:

\setlength\arraycolsep{1em} \begin{array} ... \end{array}
\setlength\arraycolsep{2em} \begin{array} ... \end{array}

[kevinbarabash]

options.length = {
   thinmuskip: '',
   medmuskip: '',
   thickmuskip: '',
   arraycolsep: '',
   jot: '',
   ...,
}

Is the implicit group really necessary? Since the commands listed above are all siblings, they're processed serially. The \setlength commands should update options, but not return a group. Is that what you meant by an "implicit group"?

[edemaine]

Ah, I see. So you imagine a setlength parse node that specifies that a length change in (the options for) the parent group. Then all following items in the group will use the new length, until/unless the length gets overridden later. This is a little tricky, I guess, because the processing of setlength nodes needs to happen at the parent level... (By contrast, what I was imagining was that the modified items in the group would become children of the setlength node...) Not sure what's best.

[kevinbarabash]

Does the effect of setlength terminate at the end of the group in which the setlength occurs? Why does the processing of setlength have to happen at the parent level?

[edemaine]

Yes, ending a group restores all lengths. In the example below, the first and last arrays use \arraycolsep=1em while only the middle one uses \arraycolsep=2em.

\setlength\arraycolsep{1em}
\begin{array} ... \end{array}
{\setlength\arraycolsep{2em} \begin{array} ... \end{array}}
\begin{array} ... \end{array}

The point is that the \setlength changes all following items within the same group. I guess the setlength parse node could modify options in-place instead of our usual copy-and-modify (newOptions = options.with...), but then many group-like things would need to carefully keep a copy of the original options to properly restore... This is why I was thinking an implicit group would be better: it's behaving just like e.g. \large.

[kevinbarabash]

1070 is a pre-requisite for this. With it, all spaces will be inserted programmatically which means that we'll be able to change their values if \thinmuskip et al are ever changed.

[kevinbarabash]

Now that we have Namespace.js we could start on this. I think the tricky part will be tracking down all of those places where we should be using a particular length for something.

[step135]

\setlength\arraycolsep{1em} still not working. Are you going to add this support? I need it to get closer horizontal lines to names of row vectors in array.

[kevinbarabash]

This is something that we'd like to add but since this is a volunteer project and people are busy with their own things it probably won't happen until someone who's really passionate about this feature decides to implement it. The good thing is that all of the building blocks are in place so nothing's blocking this work.