pretext
pretext copied to clipboard
PreTeXtBook
Display math in a Parson's block doesn't render
I was just at the Runestone drop-in, and digging around in the HTML source for a Parson's problem with display math.
If I view the HTML source, things look OK. But if I use the Inspect tool, problems become apparent.
Outside of a Parson's block, HTML for display math looks like (for example):
<div class="displaymath process-math" data-contains-math-knowls="">
\begin{equation*}
\operatorname{rank} T = \dim \im T\text{,}
\end{equation*}
</div>
(using the inspector, the contents of the div become a mjx-container.)
Here is HTML for one Parson's block with display math:
<p id="p-672">Since <span class="process-math">\(T\)</span> is linear,</p>
<div class="displaymath process-math" data-contains-math-knowls="">
\begin{equation*}
\zer = c_1T(\vv_1)+\cdots + c_nT(\vv_n)=T(c_1\vv_1+ \ldots + c_n\vv_n)\text{.}
\end{equation*}
</div>
This seems like it's the same, and should be treated as such. But the inspector sees it differently:
<div id="parsons-1-block-2" class="block" tabindex="-1" style="width: 278px; left: 0px; top: 141.969px; z-index: 2; touch-action: none; user-select: none; -webkit-user-drag: none; -webkit-tap-highlight-color: rgba(0, 0, 0, 0);">
<div class="lines">
<p id="parsons-1-line-2" data-editable="99" tabindex="-1">
<p id="p-672" data-editable="99" tabindex="-1">
Since <span class="process-math">(redacted MathJax clutter)</span> is linear,
</p>
<div class="displaymath process-math" data-contains-math-knowls=""></div>
</p>
<p id="parsons-1-line-3" data-editable="99" tabindex="-1">
\begin{equation*}
</p>
<p id="parsons-1-line-4" data-editable="99" tabindex="-1">
\zer = c_1T(\vv_1)+\cdots + c_nT(\vv_n)=T(c_1\vv_1+ \ldots + c_n\vv_n)\text{.}
</p>
<p id="parsons-1-line-5" data-editable="99" tabindex="-1">
\end{equation*}
</p>
<p id="parsons-1-line-6" data-editable="99" tabindex="-1"></p>
</div>
</div>
Note how the div with class="displaymath process-math" is closed immediately,
and the content that should be there is collected in the paragraphs that follow.
(I've added some indentation to make things more readable.)
The first paragraph also isn't closed, but appears to contain the paragraph following it, and the div that should contain the display math.
At first I thought the problem was with the HTML, but it seems that most of what I'm seeing in the inspector is not in the HTML source, so maybe this is coming from how the HTML is interpreted the Runestone Javascript?
Thanks Sean, could you also add the PreTeXt source for this example? I want to see how the blocks look for this.
Yes! Here is the source for that example:
<exercise xml:id="ex-injective-independent" label="ex-parsons-kernel">
<statement>
<p>
Rearrange the blocks below to produce a valid proof of the following statement:
</p>
<p>
If <m>T:V\to W</m> is injective and
<m>\{\vv_1,\vv_2,\ldots, \vv_n\}</m> is linearly independent in <m>V</m>,
then <m>\{T(\vv_1),T(\vv_2),\ldots, T(\vv_n)\}</m> is linearly independent in <m>W</m>.
</p>
</statement>
<blocks>
<block order="3">
<p>
Suppose <m>T:V\to W</m> is injective and <m>\{\vv_1,\ldots, \vv_n\}\subseteq V</m> is independent.
</p>
</block>
<block order="6">
<p>
Assume that <m>c_1T(\vv_1)+\cdots + c_nT(\vv_n)=\zer</m>,
for some scalars <m>c_1,c_2,\ldots, c_n</m>.
</p>
</block>
<block order="1">
<p>
Since <m>T</m> is linear,
<me>
\zer = c_1T(\vv_1)+\cdots + c_nT(\vv_n)=T(c_1\vv_1+ \ldots + c_n\vv_n)
</me>.
</p>
</block>
<block order="4">
<p>
Therefore, <m>c_1\vv_1+\cdots + c_n\vv_n\in \ker T</m>.
</p>
</block>
<block order="7">
<p>
Since <m>T</m> is injective, <m>\ker T = \{\zer\}</m>.
</p>
</block>
<block order="2">
<p>
Therefore, <m>c_1\vv_1+\cdots + c_n\vv_n=\zer</m>.
</p>
</block>
<block order="5">
<p>
Since <m>\{\vv_1,\ldots, \vv_n\}</m> is independent, we must have
<m>c_1=0,\ldots, c_n=0</m>.
</p>
</block>
<block order="8">
<p>
It follows that <m>\{T(\vv_1),\ldots, T(\vv_n)\}</m> is linearly independent.
</p>
</block>
</blocks>
<hint>
<p>
Remember that your goal is to show that <m>\{T(\vv_1),\ldots, T(\vv_n)\}</m>
is linearly independent, so after you assume your hypotheses,
you should begin by setting a linear combination of these vectors equal to zero.
</p>
</hint>
</exercise>
The source for the full section is on GitHub. (\vv is a macro for \mathbf{v}.)
We are going to need some reliable indicator that a block contains display math so I don't do the usual parsing of that block.
Is looking for \begin{equation reliable enough?
I think that should be, yes. And the div will have class=displaymath.
By the way, I'm noticing that math is failing to render in matching problems again, such as in this exercise
If I refresh the page a couple of times it will usually work, but it doesn't reliably render on the first try. Current HTML was built using PreTeXt (not the CLI), current as of 8 or 9 days ago.
I just built the sample book using CLI 1.0.1 and everything renders every time. Not exactly sure what version of the core you are using but the preamble for MathJax looked outdated from my latest bug fixes.
OK, I'll try rebuilding. I wasn't using the CLI temporarily because the necessary changes weren't in there, as far as I knew.
Also: I just realized that you also need to look for \begin{align, since this is what is used for multi-line display math.
I figured that out when I looked at Rob's example in the sample book.
Meanwhile.... I have a solution working. -- It will take a new release from me and some coordination with Rob when he returns later this week to get it live.
I think there also are other cases.
Isn't it better to look for the wrapping div?
On Mon, 15 Aug 2022, Sean Fitzpatrick wrote:
OK, I'll try rebuilding. I wasn't using the CLI temporarily because the necessary changes weren't in there, as far as I knew.
Also: I just realized that you also need to look for \begin{align, since this is what is used for multi-line display math.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to thisthread.[AABTULBTOZ37DTBHKYCW7SLVZKWIZA5CNFSM55MM24E2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOJB3 3RXI.gif] Message ID: @.***>
@davidfarmer you are right... <div class="displaymath" should be the most reliable indication.
Still needs a tiny bit of polishing... The display math throws off our initial calculation for the block height. -- which I think we talked about maybe redoing in a more flexible way anyhow. The screenshot above is after a reset.
Here's what I am seeing for a matching problem, built using CLI 1.0.1, and then pushed to GitHub Pages using pretext deploy:
Here's the link to the exercise on GitHub
But I should note a couple of things:
- I only just now changed to using
<md>instead of<m>, because the two vectors were too wide for the blocks used for the matching problem. Everything overflowed horizontally - When I was using a single line with
<m>, it rendered find using localhost on Chrome, but not on GitHub.
Yes, I plan to redo how those sizes are determined.
Right now that is pretty far down on my list....
ok, we will get there.
The fix went in for the multiple choice questions but the same treatment needs to happen for matching.
This mathjax stuff is just fraught with timing issues.
I think my latest fix -- not fully deployed for PreTeXt until Rob returns -- should do the trick across the board.
not fully deployed for PreTeXt until Rob returns
Deployed now, and seems to reliably create a rendering. So I will close this.
I'm seeing some indentation, and spacing within the block, that may need adjustment. But that should be addressed somewhere else.
