Formatting of HTML output

[Rob Beezer]

One of the great mysteries in life is why our HTML is so poorly formatted - but
for some exceptions, like lists and the ToC. And why the Runestone manifest,
output as XML, is so pretty. Well, it is one of the great mysteries in *my* life.

Not any more. If the XSL for HTML has a literal <ol> followed by some
whitespace, the HTML that is output can "see" that whitespace and clean things
up, including putting opening and closing tags on their own line. If the XSL
has <xsl:element name="ol">, there is no whitespace output and no opportunity to
manage line breaks. Thanks, Claude.

So now we have 21 instances of strategic additional newlines for block content
like #article and #section, so much of their block content is now on their own
lines, and much more readable. No indentation, it seems that simply is not
available. Things like the contents of a #p are still one long line, but that
is appropriate for mixed content (not structural, not block-level). Big payoff
fpr developers: diffs on before/after HTML should improve, especially when
dealing with the more structural aspects of the HTML output.

For more precise details, see:

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

CSS specialists should be on the lookout for any visual changes. (I'm not
seeing any.) Easy to roll back any of these which may have been too aggresive.
Or we can add more.

Rob

[Andrew Scholer]

Rob -

This is causing breakages in PTX that is rendered for Runestone. Old style fillins are broken for sure, I'm not sure if there are other spots.

The issue is extra newlines inserted into the json blob being written for the Runestone to consume:

Old output:

"feedback": "<div class=\"para\"

New output:

"feedback": "\n<div class=\"para\"

That newline's \ needs to be escaped to be valid in that spot.

Right now any book that uses old style fillins will break (or already has broken) if it is rebuild. Likely a good number of those out there in the wild as that is what the initial "turn your RST into PTX" script produced.

What do you think about rolling this back until we can figure out how to avoid the issue?

Andrew

--
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 visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAzMi5iZWV6ZXI.1775067415%40pnsh.

[Bradley Miller]

Oh no,

I updated to 2.38.1 before I rebuilt this weekend, which contains those changes.  So all deployed PreTeXt books on Runestone Academy will have broken fillins.

I think I will downgrade the CLI and rebuild with an earlier version.

Brad Miller
Professor Emeritus, Luther College
Founder, Runestone Academy LTD
Blog: http://reputablejournal.com

Set up a time to meet with me.

[Rob Beezer]

On 4/6/26 15:15, Andrew Scholer wrote:
> What do you think about rolling this back until we can figure out how to avoid
> the issue?

Reverted, merged, and pushed. Thanks for identifying this.

Those "old-style" fill-in problems are only supported as a transitional device.
Do you think we could abandon them over the summer? Do you think the
pre-processor could upgrade them?

I won't go into my thoughts about JSON... ;-)

Rob

[Andrew Scholer]

I'll defer to Brad on the retirement question.

Hopeless for the preprocessor. An old one might look like this:

<statement>
    <p>What does hexadecimal 3FC look like in binary? <var/>
    </p>
</statement>
<setup>
    <var>
        <condition string="^\s*0*11\s*1111\s*1100\s*$">
            <feedback>
                <p>Correct!</p>
            </feedback>
        </condition>
...

A new one would need an explicit answer:
        <exercise label="datarepresentation_hexadecimdaddfl2">
            <statement>
                <p>What does hexadecimal 3FC look like in binary? <fillin mode="string"
                            answer="0111111100"/>
                </p>
            </statement>
            <evaluation>
                <evaluate>
                    <test>
                        <strcmp> ^\s*0*11\s*1111\s*1100\s*$</strcmp>
                    </test>
                </evaluate>
            </evaluation>
        </exercise>


Putting answer="" means any answer will be treated as correct.
Putting the consition/@string as the answer will break the problem.

There just isn't enough information to reconstruct an answer that won't break the problem.

There are related issues with where/when the different strings are interpreted as regexes (https://github.com/PreTeXtBook/pretext/issues/2460). The @answer in the new format gets placed into a regular expression, and thus can't include regex characters lest those throw off parsing.

--
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 visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAyNS5iZWV6ZXI.1775518429%40pnsh.

[Oscar Levin]

Brad, within a few minutes, you can upgrade to 2.38.2 that will have the reverted commit and rebuild with that.