Base primitive improvements #2369
Conversation
…et Digested arg, \fam should change fonts, more robust \eqno
…pands \the-like; use it for \write, \special; improve test case
…w TeXDelimiter parameter type; Delimiter data is now keyed to the unicode; tends to more consistently preserve the various token attributes (name, stretchy, etc)
lib/LaTeXML/Core/Document.pm
Outdated
| @@ -250,6 +250,7 @@ sub canAutoClose { | |||
| || (($t == XML_ELEMENT_NODE) # otherwise must be element | |||
| && !$node->getAttribute('_noautoclose') # without _noautoclose | |||
| && ($node->getAttribute('_autoclose') # and either with _autoclose | |||
| || $node->getAttribute('_autoopened') # or was autoopened | |||
There was a problem hiding this comment.
Does this mean that the implied "default" now is for any Tag() marked as autoOpen => 1, it will also lead to autoClose => 1 ?
I see we have a special attribute _noautoclose that prevents autoclose, but it makes me wonder if we should also respect an explicit autoClose => 0 from Tag(). Or document that we won't, or...
There was a problem hiding this comment.
When you put it like that, it does seems too much, although it's probably correct most/all of the time? The problem element in this case was the ltx:text opened for font switches, so better to explicitly mark them as auto-closable, as well. patched...
| $DELIMITER_MAP{ $$entry{char} } = $entry; } | ||
| # The \lx@left, \lx@right versions are like \left,\right but without any extra grouping | ||
| DefConstructor('\lx@left TeXDelimiter', | ||
| "?#hint(<ltx:XMHint/>)(#1)", |
There was a problem hiding this comment.
What is the idea behind the empty XMHint elements? I see they are used in a few definitions here. I wonder if they should carry more information to be useful - or are they already useful when empty?
I see the code adds them when the \left/\right is applied to a dot, which indeed has no visible trace in rendering. Maybe an attribute on XMHint could indicate some of that?
There was a problem hiding this comment.
I inherited the hint from the previous code, but I doubt the hint is ever actually used. Probably put there either so there's at least 1 element, or "just in case".
t/parse/parens.xml
Outdated
| @@ -537,21 +537,21 @@ | |||
| </Math> | |||
| </equation> | |||
| <equation xml:id="S5.Ex21"> | |||
| <Math mode="display" tex="\left|{a\over b}\right|" text="absolute-value@(a / b)" xml:id="S5.Ex21.m1"> | |||
| <Math mode="display" tex="\left{\delimiter 69632778}{a\over b}\right{\delimiter 86414091}" text="delimited-⟨⟩@(a / b)" xml:id="S5.Ex21.m1"> | |||
There was a problem hiding this comment.
Hm, we may want to avoid the { and } entirely when reverting delimiters. The tex attribute on the Math above encounters an error in pdftex. What succeeded was the plainer form from parens.tex:
$\left\delimiter 69632778 {a\over b}\right \delimiter 86414091$
\byeSince we have recently fixed a report about tex attribute reuse with TeX, I thought I would bring this up.
There was a problem hiding this comment.
Yeah, good catch. patched..
Fixes various little fidelity problems that turned up while playing with
plain.tex.\nonscript, '\fam`,\writeexpand in the special\thestyle ('XGeneralText` parameter type)\left,\rightprocessing to digest args while still grouping between them.