LaTeX package requirements for \fillintext and \real

[D. Brian Walton]

In order to debug the issue posted by Grant about fillin examples failing to build to pdf

(https://groups.google.com/g/pretext-support/c/jUxiSXdDjEU/m/AAiIVW_BAAAJ), I was able to track down that there is a `calc` package that isn't being loaded. This package is required for the \real macro. This is separate from the `calc` tikz library.

I think this must be loaded by other packages in order to not have created problems before. For example, I found if I included `\usepackage{pdfpages}` or `\usepackage{calc}` in the preamble, then Grant's example compiles as needed. I don't know if there are other packages that also would have worked.

I think that the fix is to add `\usepackage{calc}` in the preamble, but I'm not familiar with this part of the system.

Separately, while looking at this example, I realized that the mark-up for feedback requires that the feedback text is enclosed in a block. If it is a raw text string, the feedback doesn't pull through. See, for example, exercise 3 on this page: https://pretextbook.org/examples/sample-book/noparts/html/fill-in-exercises.html

The feedback is always reported as an empty string because the XSL that parses the feedback calls xsl:apply-templates to the contents of #feedback. This problem was coded with raw text inside, so the template comes back empty.

Is there an efficient way in the pre-processor stage to look for #feedback with naked text and surround it? Would #p be the most natural element to enclose things in?

Brian

[Rob Beezer]

On 7/3/24 14:16, D. Brian Walton wrote:
> Separately,

I've renamed the thread for this very different topic.

> while looking at this example, I realized that the mark-up for
> feedback requires that the feedback text is enclosed in a block. If it is a raw
> text string, the feedback doesn't pull through. See, for example, exercise 3 on
> this page:
> https://pretextbook.org/examples/sample-book/noparts/html/fill-in-exercises.html
> <https://pretextbook.org/examples/sample-book/noparts/html/fill-in-exercises.html>
> The feedback is always reported as an empty string because the XSL that parses
> the feedback calls xsl:apply-templates to the contents of #feedback. This
> problem was coded with raw text inside, so the template comes back empty.

Likely it is

<xsl:apply-templates select="*"/> (elements only)

versus

<xsl:apply-templates/> (elements and text)

the latter being functionally equivalent to

<xsl:apply-templates select="*|text()"/>

> Is there an efficient way in the pre-processor stage to look for #feedback with
> naked text and surround it? Would #p be the most natural element to enclose
> things in?

Mixed-content (elements and text nodes as peers) is tough. But not relevant
here. Structured is great, which is the expectation for #feedback right now, I
believe. It would be nice to allow source to be (short) unstructured text and
have the pre-processor provide a #p as a wrapper, and the code can then assume
structure always (e.g select="*").

The problem is how to reliably identify the difference between the unstructured
and structured versions? Not as easy as you think.

<feedback>
<em>I love</em> <c>Python.</c>
</feedback>

Only cheating a bit with the period.

Read recent pull request with Andrew S to allow naked code in a #program. Easy
there, a structured version (current expectation) is it *must* have an "input".
So the structured/unstructured signal is clear.

Having said all that, we have code for structured/unstructures list items (not
in pre-processor), and I think current code makes me a bit nervous.

Rob

[Rob Beezer]

More here than meets the eye. In "pretext-latex.xsl" find code comments at
about line 1840.

Extensible arrows (extpfeil) loads "mtools" which loads "calc" which redefines
\setlength which I would think is a really dangerous idea.

See comments about trying to gracefully abandon support for these arrows due to
problems with "calc". Of course, this problem might be fixed? Have not checked.

Not sure if all this is consistent with your sometimes/sometimes-not behavior.

So..we might load "calc" conditionally on presence of a #fillin element, say. I
really try hard not to make a monster preamble (with potential for conflicts
like this) when a document is "simple" - thus the conditional additions and
limited "always-on" packages.

But maybe we back-up and find a replacment for \real. What is its purpose? Are
there alternatives? I believe Alex added these macros, so he might have input.

Rob

On 7/3/24 14:16, D. Brian Walton wrote:

> In order to debug the issue posted by Grant about fillin examples failing to
> build to pdf
> (https://groups.google.com/g/pretext-support/c/jUxiSXdDjEU/m/AAiIVW_BAAAJ

> <https://groups.google.com/g/pretext-support/c/jUxiSXdDjEU/m/AAiIVW_BAAAJ>), I

[Alex Jordan]

I can remove the use of `\real` and the reliance on `calc`. The result is a bit awkward but it works. PR coming as soon as I clean things up.

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAyMy5iZWV6ZXI.1720112957%40quikprotect.

[Rob Beezer]

For the record, this should be addressed via

https://github.com/PreTeXtBook/pretext/pull/2196

Thanks, Alex.

> <mailto:pretext-dev%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pretext-dev/MTAwMDAyMy5iZWV6ZXI.1720112957%40quikprotect <https://groups.google.com/d/msgid/pretext-dev/MTAwMDAyMy5iZWV6ZXI.1720112957%40quikprotect>.

>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com

> <mailto:pretext-dev...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pretext-dev/CA%2BR-jreFqmue3n7EU%3DDCQ-EA67yua%2B2ehXFPsQQAxJActW6Fuw%40mail.gmail.com <https://groups.google.com/d/msgid/pretext-dev/CA%2BR-jreFqmue3n7EU%3DDCQ-EA67yua%2B2ehXFPsQQAxJActW6Fuw%40mail.gmail.com?utm_medium=email&utm_source=footer>.