#4696 tex and lurkmathml typeset itensor output incorrectly

[Leo Butler]

In hodge.dem, the input line:

ishow(canform(hodge(%)))

produces the output (I print the Lisp sexp, because it is otherwise hard to see that %1 %2 %3 %4 is single symbol):

((MTIMES SIMP) ((RAT SIMP) 1 6) ((MEXPT SIMP) $LEVI_CIVITA #:|$%1 %2 %3 %4|) (($G ARRAY) #:|$%1 %102|) ((|$a| ARRAY) #:|$%2 %3 %4|))

It seems clear that 4 and 102 are not subscripts. But both tex and mathml treat them as such:

```
(mfuncall '$mathml '((MTIMES SIMP) ((RAT SIMP) 1 6) ((MEXPT SIMP) $LEVI_CIVITA #:|$%1 %2 %3 %4|)
(($G ARRAY) #:|$%1 %102|) ((|$a| ARRAY) #:|$%2 %3 %4|)))

$\frac{g_{{\mathrm{\%1\; \%}}_{102}}{A}_{{\mathrm{\%2\; \%3\; \%}}_4}{\mathrm{levi\_civita}}^{{\mathrm{\%1\; \%2\; \%3\; \%}}_4}}{6}$

```

and

(mfuncall '$tex (caddr +)) $${{g_{{\it \%1 \%}_{102}}\,A_{{\it \%2 \%3 \%}_{4}}\,{\it levi\_civita}^{ {\it \%1 \%2 \%3 \%}_{4}}}\over{6}}$$

We see that both the 4 and 102 are treated as subscripts, which seems wrong.

I am inclined to think that the itensor output is wrong and instead of constructing a symbol like #:|$%1 %102|, it would be better to add a space at the end to prevent subscripting.

Patch attached.

[Leo Butler]

The interaction of the tex DWIM rule for subscripts and itensor's convention causes double subscript errors in some tex.

demo(bradic);

contains such an example. The input line 48,

ishow(e([m,n],[])=canform(%*16*%pi/sqrt(-determinant(g))))$

produces a large expression that, when tex-ed, contains the following mal-formed code:

{\it ichr}_{2}_{{\it \%4 \%}_{5}}

The proposed patch would produce the valid tex:

{\it ichr}_{2}_{{\it \%4 \%5\ }}

[Viktor Toth]

Marking this as "won't fix" as the proposed fix interferes with ISHOW's primary function on ASCII displays. The real issue is how a) $TEX promotes trailing digits to subscripts (which, for itensor, is not an issue, really) and b) how ISHOW's output, then, is misprocessed with only the last of several indices being processed by $TEX in this manner (which produces the inconsistent appearance.) But it is not because ISHOW is doing anything it shouldn't (it produces correct output on ASCII terminals, which is its intended behavior) but how front-ends post-process that output.