Amscd #2449
Amscd #2449
Conversation
…m width; general code cleanup
…d extra munder/mover)
lib/LaTeXML/Package/amscd.sty.ltxml
Outdated
| role => 'ARROW', stretchy => 'true', meaning => 'leftrightarrow', width => Dimension('30pt')); }); | ||
| DefPrimitive('\lx@amscd@equals', sub { | ||
| Box("=", undef, undef, T_OTHER('='), | ||
| role => 'ARROW', stretchy => 'true', meaning => 'equals', width => Dimension('30pt')); }); |
There was a problem hiding this comment.
As a clarifying question:
What is the intended meaning of an XMTok that has a set positive width (30pt here), with stretchy="true" at the same time?
Does the XMath width act as min-width in this circumstance?
There was a problem hiding this comment.
Ha! Good question! So, the way it gets converted to MathML (wrapped in an mover with a wide mspace, in this PR) allows for the expectation that other table cells might be wider and cause the arrow to stretch even further, so that it would act as a min-width. However, the current MathML-Core apparently only does horizontal stretch within mover/munder, so it would never see those other cells' widths. So, in practice (currently) it would act as the width.
| # First, special case hack for stretchy arrows, with specified width | ||
| # Stretchiness (currently) only has effect within munder/mover!!!!! | ||
| if ($width && (($role || '') eq 'ARROW') && !$unstretchy) { # SPECIAL CASE HACK | ||
| $result = ['m:mover', {}, $result, ['m:mspace', { width => $width }]]; } |
There was a problem hiding this comment.
I wonder if a well-named class attribute for this special case won't be useful in the future. Would make it a little clearer for people inspecting the markup, and easy to check when it gets refactored as MathML Core improves.
Maybe <mover class="ltx_math_stretched"> ?
There was a problem hiding this comment.
The $unstretchy check may not be booleany enough. If we go with strecthy="true" by default, and when explicit, then everything else is false (including invalid values), then:
my $stretchy_attr = $node->getAttribute('stretchy') || ($parent && $parent->getAttribute('stretchy')) || "true";
my $unstretchy = $strechy_attr neq "true";There was a problem hiding this comment.
Somehow I knew you'd suggest that, so why didn't I just head you off by implementing it? But actually, something like \ltx_horizontally_stretched might be even better; I was a little concerned about the code doing something weird with vertically stretching cases. (Alas, no visible distinction in MathML)
There was a problem hiding this comment.
Actually, if a class is going to be used to detect the "special case", then we can drop the test of stretchy completely.
| </XMCell> | ||
| <XMCell/> | ||
| <XMCell align="center"> | ||
| <XMTok fontsize="160%" name="uparrow" role="ARROW">↑</XMTok> | ||
| <XMTok fontsize="160%" name="||" role="VERTBAR">∥</XMTok> |
There was a problem hiding this comment.
The name="||" got me curious, so I checked the DefMath, which indeed uses that name for \|.
DefMathI('\|', undef, "\x{2225}", role => 'VERTBAR', name => '||');In the TeXbook, I see its definition marked with "vertical line" in Appendix E, p. 420:
\def\|{\leavevmode\hbox{\tt\char‘\|}} % vertical line
Would vertical-lines be a better name in this case?
There was a problem hiding this comment.
It might be, but name is a bit of an orphan: it's somewhere between the content, reversion and meaning; it probably shouldn't even exist at all, but it does get used for various checks.
At some point in the not too distant future, a scan of all uses needs to be analyzed and figure out where to go with it. Perhaps it should end up being part of intent infrastructure? So: Hold onto that thought!
|
OK, I added |
This PR fixes the
amscdpackage to make the horizontal connectors (typically arrows) stretch. Since MathML (currently?) only stretches horizontally the participants inmover/munder(see w3c/mathml-core#270) some extra support (hack) is needed in the MathML postprocessing. But the end result now looks like it should.