LaTeX: redefine \fillin

[Alex-Jordan]

This redefines fillin.

First, now both the underline and box style use the same macro definition. Which is based on a length that is set by the stringparam.

But the purpose of this commit was to make it so LaTeX will at most reduce width to 80%, preventing fillin width from getting so small it is unusable.

One consequence is from time to time, LaTeX will prefer to let these fillins overflow into the margin rather than line break early and leave too much white space. But that is the trade off for not allowing them to shrink too much.

[rbeezer]

Looking good. But a few nits:

• See Exercise 11.2.8 of sample article. In math, subscript on a "y" has moved pretty far down.
• I think blank and bottom of box is now about 50% further below baseline? A matter of preference, I guess, but I liked it a bit higher up where it was before (perhaps related to earlier bullet?). Your call.
• Do you know where \real{} comes from? Un-Google-able for me. (Tangential - truly necessary, or a convenience?) If from the calc package, then we get that from mtools which we get from extpfeil which I would make optional someday, not built-in (perhaps?). I'd just add a code comment near loading extpfeil speculating on what would break. A <fillin/> in the minimal sample behaved, so this is not a problem, just anticipating future problems.

Thanks for the work on this one - we'll be getting more fill-ins from Runestone problems soon.

[Alex-Jordan]

Thanks for looking harder at the actual output in sample article. I spent more time with a mockup .tex file.

See Exercise 11.2.8 of sample article. In math, subscript on a "y" has moved pretty far down.

That is not a good thing? When I look at the current: https://pretextbook.org/examples/sample-article/derivatives.pdf#page=62 I would not perceive that underline to be underlining a subscript (as opposed to regular baseline fillin).

Before it was dropped -1.2pt. Now it is is -0.2baselineskip, which I admit is not good for subscript/superscript. In need some kind of shift that is sensitive in math to the current font (sensitive to whatever math mode scriptstyle is when in a subscript, etc.) I'll play around.

I think blank and bottom of box is now about 50% further below baseline? A matter of preference, I guess, but I liked it a bit higher up where it was before (perhaps related to earlier bullet?). Your call.

Underline change described above. With the box, it is actually higher now. Used to be -0.3baselineskip, now it would be -0.2baselineskip.

Do you know where \real{} comes from? Un-Google-able for me. (Tangential - truly necessary, or a convenience?)

I think necessary, or else use something equally as unfamiliar, like \dimexpr 0.2*#1em. Or maybe I didn't find a "simple" way. Certainly, 0.2 #1em or 0.2*#1em do not work.

If from the calc package,...

Because of tcolorbox, we have \usetikzlibrary{calc} which is always being loaded. I think I was getting calc tools from that. Is that also something that one day may be optional?

I was thinking yesterday I should design this LaTeX macro differently anyway, for reasons you may or may not agree with. I was thinking that it should have an optional argument (options "underline", "box", "blank", "shade" ...). And that in the same document, more than one variant could appear in the body. For starters, maybe a publisher could specify \fillin[underline] for fillins in text, but use \fillin[box] for when they are in math. Also I think I am in favor of PTX source overriding individual fillin styles. For example maybe you mostly want underlines, but there is this one place (a subscript, perhaps?) where you want it to be a box.

If I define the macro this way now, at least it opens the possibility to easily do those other things later. Or consider doing them.

I'll rewire the macro after some more experiments.

[rbeezer]

I would not perceive that underline to be underlining a subscript (as opposed to regular baseline fillin).

In existing, it is below the bottom of the descender of the "y", so I see it as well below the bottom of the baseline. I see that before I think about what I know about typography to explain why. New looks totally disassociated to me. And I bet it is going to wreak havoc on a following line.

some kind of shift

Why not use an "ex"? It is the font that matters, I think, not the line spacing.

\usetikzlibrary{calc}

I saw it, but did not investigate if it was a thin wrapper on regular calc or something different. Yes, comments suggest we always load it. So fine there if that is where \real is coming from. (Comment out extpfiel stuff to see?) I'd still comment the (hidden) dependency (and I can do that as a follow-on commit).

I was thinking that it should have an optional argument

I'm fine with passing current stringparam down out of the preamble and parameterizing \fillin so long as it is done in a backward-compatible way. If we make the choice local via an attribute on the "fillin" PTX source element, then HTML, braille, documentation, all come into play. An add-on so no deprecation, I think.

[Alex-Jordan]

Why not use an "ex"? It is the font that matters, I think, not the line spacing.

If you are in math mode, using ex refers to the size of an ex just outside the math mode in the regular text. So for example \(\rule{1ex}{1ex}_{\rule{1ex}{1ex}}\) makes two boxes that are the same size. The second one is not sensitive to being in subscript, and does not come out smaller.

[rbeezer]

If you are in math mode, using ex refers to the size of an ex just outside the math mode

Didn't know that. Or expect that. Another -1 for LaTeX. :-(

[Alex-Jordan]

Loading \usepackage{tcolorbox} alone does not give me tikz. So:

\usepackage{tcolorbox}
\usetikzlibrary{calc}

is an error. If I do:

\usepackage{tcolorbox}
\tcbuselibrary{skins}
\usetikzlibrary{calc}

then the error is resolved.

Does this change anything? Is the presence of skins stable?

[rbeezer]

I don't have the code in front of me, but I'm pretty sure "skins" is critical to the LaTeX styling via tcolorbox.

On May 1, 2022 11:46:07 PM PDT, Alex Jordan @.***> wrote:

Loading \usepackage{tcolorbox} alone does not give me tikz. So:

\usepackage{tcolorbox}
\usetikzlibrary{calc}

is an error. If I do:

\usepackage{tcolorbox}
\tcbuselibrary{skins}
\usetikzlibrary{calc}

then the error is resolved.

Does this change anything? Is the presence of skins stable?

[Alex-Jordan]

I've got a good thing going now for fillins in text mode. It's equipped to do underline, box, empty, and shade. For a sneak peak. Here, @characters="10" for all the blanks. You can see some have compressed a little for line fitting. One of them is compressed but still has an overflow into the margin.

For what it's worth, if I apply what I have for text mode fillins to math, it looks like this. These examples all have @characters="2".

Now that has some problems with depth, especially (imho) with subscript and display mode. So then investigating fillin in math mode has made me realize there is a larger issue. I think this scenario demonstrates it:

<me>\int <fillin characters="5"> \,dx</me>

<me><fillin characters="5"> + dx</me>

These are each in display mode. In the first, there is a tall integral sign, and I think you don't want the underline to be close to the "dx" baseline. Otherwise it suggests there is a fraction in the integrand. Or it is getting in the way of a binomial coefficient (or some tall thing) being the integrand.

But then in the second, this is display mode too. But now you do want the underline to be close to the baseline of the "dx".

Solving this issue is hard enough with LaTeX, but may be impossible with MathJax. I have several ideas I could pursue, but here is the one I'd like to discuss first. Proposal: in math, a fillin should not have @characters. Instead, it would have @width and @height. Math expressions are (in general) 2D, not 1D, and for example if the author expects users to enter a tall fraction, then can specify a good height. With values for these two dimensions (author-provided, or default) then math mode fillin can just make a box and center it. The box could only have border on bottom for underline, etc. I do not know how the author would measure the two dimensions (ex units? absolute units? etc.) but that would be the next thing to discuss.

Thoughts on this proposal? If it's bad, I can move on to other ideas.

[rbeezer]

Nice work! But I won't have much bandwidth for an expansion of features for a while, and I'd like Runestone output to look good as a pile of new authors comes onboard shortly.

Would it be possible to keep everything much as it is, and just address the "minus" portion? Just add the necessary length and then keep the two existing macros, but now each with a 20% shrinkage?

We can continue to address expansion and new attributes at our leisure on this PR, no need to switch to another.

On May 2, 2022 11:04:08 AM HST, Alex Jordan @.***> wrote:

I've got a good thing going now for fillins in text mode. It's equipped to do underline, box, empty, and shade. For a sneak peak. Here, @.***="10"` for all the blanks. You can see some have compressed a little for line fitting. One of them is compressed but still has an overflow into the margin.

For what it's worth, if I apply what I have for text mode fillins to math, it looks like this. These examples all have @.***="2"`.

Now that has some problems with depth, especially (imho) with subscript and display mode. So then investigating fillin in math mode has made me realize there is a larger issue. I think this scenario demonstrates it:

<me>\int <fillin characters="5"> \,dx</me>

<me><fillin characters="5"> + dx</me>

These are each in display mode. In the first, there is a tall integral sign, and I think you don't want the underline to be close to the "dx" baseline. Otherwise it suggests there is a fraction in the integrand. Or it is getting in the way of a binomial coefficient (or some tall thing) being the integrand.

But then in the second, this is display mode too. But now you do want the underline to be close to the baseline of the "dx".

Solving this issue is hard enough with LaTeX, but may be impossible with MathJax. I have several ideas I could pursue, but here is the one I'd like to discuss first. Proposal: in math, a fillin should not have @.`. Instead, it would have @.and ***@***.***. Math expressions are (in general) 2D, not 1D, and for example if the author expects users to enter a tall fraction, then can specify a good height. With values for these two dimensions (author-provided, or default) then math mode fillin can just make a box and center it. The box could only have border on bottom for underline, etc. I do not know how the author would measure the two dimensions (ex units? absolute units? etc.) but that would be the next thing to discuss.

Thoughts on this proposal? If it's bad, I can move on to other ideas.

[Alex-Jordan]

Without spending more time to investigate, I think I need \real to do things like #1em * \real{0.2}. That would be the smallest diff right now for that one change. That comes from calc. Can I confirm that (together with a code comment) it's fine for now to rely on calc?

[Alex-Jordan]

Discovery while trying to build the sample article for testing this. Sample article publisher file has external="media". But publisher-variables.xsl hard codes the name of the external folder as external instead of dynamically using (in this case) media. Is this how it is supposed to be? Right now pretext/pretext/pretext builds a .tex file where it expects the external images to be in external/images/... instead of media/images/.... I can either click through all the failed attempts to find an image, or I could temporarily rename media to external. But it seems like something is wrong.

[Alex-Jordan]

I copied the media folder to external so I can get through a PDF build. How is your build script handling this?

[Alex-Jordan]

Possibly what I experienced is specific to -f latex. Meaning that -f pdf handles it all OK off in some temporary folder.

[rbeezer]

That would make sense. The latex format is not meant to be immediately usable in any certain place. More for developers to test, or as the get-out-of-jail-free card.

On May 3, 2022 9:55:14 AM HST, Alex Jordan @.***> wrote:

Possibly what I experienced is specific to -f latex. Meaning that -f pdf handles it all OK off in some temporary folder.

[rbeezer]

I guess your "Hello, World" demo/test is in LaTeX? In any event, something like it could go in the sample article as PreTeXt once this push is done.

[Alex-Jordan]

Yes, for quick testing where I can tweak the macro repeatedly, it's just a small LaTeX file. Will test in PTX before all is said and done.

I'm happy with the text mode fillin, at least to the point of putting it forward for inspection. But I have the math mode fillin issues I've raised in this thread. Does it make sense for a math mode fillin to have the author (optionally) declare two dimensions?

[rbeezer]

Possibly what I experienced is specific to -f latex

See ee0f005e1564ddd41aac66a58e0e9082e26fd3c4 ;-)

[rbeezer]

I'm happy with the text mode fillin, at least to the point of putting it forward for inspection.

I'm having trouble seeing the use of "empty". Shaded is nice.

Does it make sense for a math mode fillin to have the author (optionally) declare two dimensions?

Not without understanding how those are done without absolute units.

[Alex-Jordan]

"shade" and "empty" are provisioned for in this LaTeX macro, but they'd be unusable until such time as they are provisioned for in other output modes. I think I'm just trying to convince myself that I have a robust LaTeX macro that can be extended to do more than just underline and box.

I could imagine using "empty" in the middle of a paragraph if I wanted to avoid the visual clutter of other options.

Not without understanding how those are done without absolute units.

I'd propose something like @width is an number, and it comes out as that multiplied by width of an \(x\). So like "1ex" in spirit. And similarly for @height except I'd suggest using the height of an (f). Famous last words, but there is a base macro called \mathchoice that can produce different output depending on if we are in displaymode, textmode, scriptmode, or scriptscriptmode. I think I can use this together with calc package macros \widthof{} and \heightof{} to work this out.

Assume for a moment that is technically possible. How does it sound in principle?