HTML URLs for LaTeX and other static formats

[Rob Beezer]

Really just for Andrew. But also the idly curious.

We are both trying to manufacture certain URLs that are part of the HTML output,
and make them available to static formats (during the pre-processor phase).

Just some partial sleuthing and thinking out-loud:

Modal templates for "is-intermediate", "is-chunk", and "containing-filename" are
all in pretext-common. Maybe mode="url" could move to pretext-common, with
some baggage.

Perhaps all that could be split out into a new stylesheet that is

(a) imported in pretext-common (preserving status quo)

(b) imported into pretext-assembly (as a collection of utilities)

when we do a conversion we import both pretext-common and pretext-assembly, but
I think there is not duplication, just the import precedence of the templates
that move will be higher (imported into assembly earlier than imported into
common)? And I don't think we rely on that precedence in any particular way in
that scenario.

And maybe we always import assembly before we import common, so maybe (b) is noot?

I think there are some templates like this in pretext-runestone-static.xsl that
get imorted into assembly already?

Rob

[Andrew Scholer]

Won't the chunking pub variable (and different stylesheets' treatment of it) still be a problem?

If LaTeX is currently being built with one pub file and we are trying to generate URLs for an HTML build that is controlled by a different pub file, I am not seeing how we get the right behavior.

Andrew Scholer (he/him/his)

Computer Science Instructor

Chemeketa Community College

503.589.7649 

computerscience.chemeketa.edu/people/andrew-scholer/

--
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/MTAwMDA0Ny5iZWV6ZXI.1755557755%40pnsh.

[Rob Beezer]

I guess authors would need to know that a baseurl had to be in their publication
file, along with a chunking level that was used for their HTML build. That
chunking level would have no adverse affect on their LaTeX. Or we could have
some nex settings in the #latex section to accomplish this.

The defaults for HTML would need to be recomputed, I guess.

Yes, a bit of a tar pit we have stepped into...

Rob

On 8/19/25 07:46, Andrew Scholer wrote:
> Won't the chunking pub variable (and different stylesheets' treatment of it)
> still be a problem?
>
> If LaTeX is currently being built with one pub file and we are trying to
> generate URLs for an HTML build that is controlled by a different pub file, I am
> not seeing how we get the right behavior.
>
> Andrew Scholer (he/him/his)
> Computer Science Instructor
> Chemeketa Community College
> 503.589.7649

> computerscience.chemeketa.edu/people/andrew-scholer/ <http://

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

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/

> MTAwMDA0Ny5iZWV6ZXI.1755557755%40pnsh <https://groups.google.com/d/msgid/
> pretext-dev/MTAwMDA0Ny5iZWV6ZXI.1755557755%40pnsh>.

>
> --
> 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+uns...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/

> CACm44N_kbi5RQbATQLxZNOsYbt%3DMe6EV5R6uq37nYOg%3DKyn-FQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/pretext-dev/
> CACm44N_kbi5RQbATQLxZNOsYbt%3DMe6EV5R6uq37nYOg%3DKyn-FQ%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Rob Beezer]

OK, an attempt at fresh thinking.

An interactive in static form will be a #sidebyside with a QR code and some
links. You want something similar for interative programs. So an author/CLI
needs to apply the "extract-qrcode" stylesheet to mine identifying information
("visible-id") and a URL to embed in the QR code ("static-url"). Why not have
this stylesheet also prepare a file full of other URLs (in XML format,
naturally!) to live in the "generated" directory? Then the pre-processor can
consult this file to place URLs in the static version.

I would guess we just import the "pretext-html" stylesheet into "extract-pg"
where it may do no harm and where any nonsense will be contained/obvious.

Bonus: no changes in workflow, we are just left with a poorly named stylesheet
whose capabilities have expanded.

Double bonus: we could move "static-url" to "pretext-html".

Rob

[Andrew Scholer]

Yes, that makes sense to me. 

I don't love having to pre-generate the list and then update it on any content change, but I guess it is far from unique in that regard. Everything else about it feels clean and straightforward.

Are you sure the output should not be JSON? ;)

[Rob Beezer]

On 8/22/25 08:42, Andrew Scholer wrote:
> Yes, that makes sense to me.

Good. Do you want to tackle it via this route, or should I (given it is a lot
like some other things we generate for later consumption).

> I don't love having to pre-generate the list and then update it on any content
> change, but I guess it is far from unique in that regard. Everything else about
> it feels clean and straightforward.

Well, it won't really be any more or less than right now for the QR codes.

> Are you sure the output should not be JSON? ;)

No, maybe you should use YAML. Are you *trying* to provoke a #rant? ;-)

Rob

[Andrew Scholer]

I'll take a crack at it.

Andrew

[Andrew Scholer]

New chicken/egg issue... for -assembly/-common:

I would like to generate some static text that can be localized. ("This program has an interactive version...") The content is being created in the representations pass of -assembly is where the content is created.  But localizations are in -common.

I started looking at breaking the localizations into a new file, but they depend on docinfo, which is established after the augment pass.

Any suggestions?

Andrew

[Rob Beezer]

Write the localized text into the XML file with the IDs and URLs?

Strikes me you could make one XML file per interactive, where visible id is the filename. Better than repeatedly opening and searching a master file?

[Rob Beezer]

I've tended to punt on localizing long pieces of text. It's hard for the translators, especially with grammar and word order in play. Either English or I try to find a phrase. For example, here I might just say "Interactive Program:".

Rob

[Andrew Scholer]

I had started in on writing a <localize-me>...text..</localize-me> element during representations that would get cleaned up later.  Your idea should end up cleaner. 

Thanks!