-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am a little out of my depth on the TeX details, but tried to provide a first surface review.
plain.tex
itself will certainly be the harsher arbiter here.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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$
\bye
Since 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, good catch. patched..
* Tweak fontname recognition for cmti (text italic) * Move initialization of UC/LC to State.pm * Move a couple of helpers from plain to TeX_Math * Various tweaks & new defns: \nonscript, fix \delcode, \mathbin etal get Digested arg, \fam should change fonts, more robust \eqno * Define an expanded general text parameter type (XGeneralText) that expands \the-like; use it for \write, \special; improve test case * autoopened nodes can be autoclosed * DefMath can coerce more symbols to simpler primitives (rather than constructors) * Better math char decoding * Make \mathopen, etc digest the argument (but something odd with \mathop) * Improved \left,\right handling to deal with \delimiter and others; New TeXDelimiter parameter type; Delimiter data is now keyed to the unicode; tends to more consistently preserve the various token attributes (name, stretchy, etc) * Update test cases for more consistently preserved (though dubious) name attribute * Add left/right \delimiter test * TeXDelimiter parameter type reverts w/o braces * Autoopened text nodes can autoclose, but not necessarily others
Fixes various little fidelity problems that turned up while playing with
plain.tex
.\nonscript
, '\fam`,\write
expand in the special\the
style ('XGeneralText` parameter type)\left,\right
processing to digest args while still grouping between them.