QR codes for interactive programs

[ascholerChemeketa]

This adds QR code generation for interactive programs (activecode/codelens).

Because programs already may have width issues in print, I don't want to do the link side by side with the program itself. So instead, an assemblage with a link/qr is added after the program. I think it is good to have that block visually separated as a "here is something not part of the core text". But I feel no real ownership of that layout.

I figure you will want to do your own test of generation, so no commit with the updated QR codes.

First commit fixes a breaking bug if version 8+ of qrcode is installed:
https://pypi.org/project/qrcode/
If the rest of this ends up languishing, it might be worth breaking that commit out.

[ascholerChemeketa]

BTW - I hate that the url needs to go in a p and thus gets indented. Not sure how to avoid that though.

[ascholerChemeketa]

Draft while working on:
#2682

[ascholerChemeketa]

Updated based on results of <pi:localize> work.

Content since last review:

• Individual xml sidecar files for urls
• Use pi:localize
• Dropped commit moving static-url templates from -assembly to -html (see below)

I kept the extraction-wrapper override in extract-qrcode as it is the best way to have a single decision based on $baseurl to either generates error message or do work.

I believe dataurl is the now the only thing that still relies on "static-url" templates during static build. So moving the "static-url" templates needs to wait on a solution for it.

[rbeezer]

I hate that the url needs to go in a p

Agreed. No great suggestion at the moment. Might look at a #stack full of #p. We did something about indentation, iirc. Maybe we added it. ;-) Possible it is not present on paragraph 1.

Now, I really don't like #assemblage. ;-) How about just a plain #sidebyside? A #title might be the rub. Not sure what we could put into the left panel that would have a #title and not a lot of other stuff. #paragraphs (no indentation on paragraph 1!), but I don't think it makes sense as a panel, it is more of a division

[ascholerChemeketa]

Force pushed to rebase.
Two new commits at end. One to change structure of the SBS. Once we pick a final format I will merge it into other commits. Other has hello world testing setup. It will get dropped.

Here is a:

sbs
   paragraphs
      p
         em
            title text
      p
          url

A title instead of the first paragraph would be more semantic, but looks ugly when rendered with an inline table.

I think this is going to be impossible to make pretty in assembly given the current tools.

[rbeezer]

Suppose we had p/@pi:indent="no".

Would

sidebyside
    stack
        p [title text, no #em]
        p [url here]
    image [qr-code]

be not so ugly?

[ascholerChemeketa]

Yes, not indenting those paragraphs would help. I like some kind of indication that the title text is a label/title and not plain text. But if there is @valign="middle" on the left sbsgroup then at least there is some whitespace to separate the title text from the text of the program.

[rbeezer]

What do you say to getting this in with the suggest side-by-side, and then you (EPUB CSS?) and I (LaTeX) work to get the un-indentation going after this is in?

[ascholerChemeketa]

Sounds good. Force pushed that structure with @pi:indent="no" on the <p>s.

[rbeezer]

Working on this one. I'm leery of the import of pretext-html.xsl into the focused stylesheet for extraction. And we need a more general fix, since I would like links to "in situ" versions of interactive, etc. See #2819.

I've got more to look at, so do not add anything here right now, might be a day or two...

[rbeezer]

I've spent a lot of time on this one, trying to solve the problem of doing HTML stuff (chunking) for static stuff (LaTeX), including a very long comment that I just pulled up short on.

This will be needed for making links to interactive that point into the content (not the "standalone" page), so I'd like to pause this one for now, until I can get the bigger issues settled.

[rbeezer]

Lots of new work, motivated by this PR, now over at #2826.

• Some commits there will be helpful for getting this together. Certainly the earlier ones are key, maybe 61c7cac is the most pivotal.
• Sidecar files only really needed for the "In Context" link. But others done similarly for consistency. You will need to make empty URL strings for interactive program so links are not created.
• I like entities for element lists that get used lots of places, I think it is overkill here.
• Claude suggests filtering on positive interactive, in other words explicity on @interactive being activecode or codelens.
• Claude also notes that on QR codes for interactive programs #2676 the program text is added twice in static formats. I think it makes the most sense to add it to the representations pass and remove it the other place. More consistent with other similar objects.
• p/pi:indent="no" now supported, see example uses.
• Only the QR code v8+ update got recorded with this PR, but I've tried to leave a good trail here.
• Let's open a new PR for the improved version of this.
• I'm going to discuss the "Embed" link in the groups.

What do you think of a "standalone" page for each interactive program? Sort of a distraction-free version, not in context? We'd need to think about having a third version floating around on Runestone Academy...

Thanks for your patience on this one. The whole notion of considering HTML chunking while doing static representations has been eating at me for long time. Your work here was helpful in getting that sorted out.

[ascholerChemeketa]

Roger.

Not so sure about the standalone page. It would break programs that use other elements on the page as data files of code to include. And assigned exercises already end up on an out of context page.

For purposes of the QR destination, I personally would want people to end up on the relevant book page, not in a one-off for that program. Both on principle and because the standalone pages don't currently make it easy to get back to in-context - we expect someone navigates to them from the book, not starts there.

[oscarlevin]

I believe due to this PR, the cli is throwing errors when it tries to build html that contains interactive elements.

error: processing with /home/oscar/.ptx/2.38.3/core/xsl/pretext-html.xsl has failed
critical: Cannot resolve URI /files/GitHub/dev/pretext-cli/new-pretext-project/interactive/generated-assets/qrcode/interactive-infinity-url.xml
critical: Failed to build without errors.  Exiting...

Is it true that the html build now requires QR codes to be generated? Of course the CLI builds QR codes for static formats, but until now we haven't done so for html.

Anyway, adding qrcodes to the list of assets to build for HTML seems to fix the issue. So I'm happy to add that, but wanted to make sure this was the intended behavior.

Also, do I need to check the source for .//program[@interactive] in case the source doesn't have other interactives?

[rbeezer]

The qrcode format is now also making files of URLs based on the base URL. I can't think of why we are trying to read those files for an HTML build. Must be a new exsl:document(). I might be able to investigate in a few hours. So maybe CLI should generate as a short-term measure?

[oscarlevin]

That's what I've done, so no rush on this.

[ascholerChemeketa]

I had noticed that requirement. It is not directly related to QR codes. The requirement comes from reading url's for audio|video|interactive[not(static)] from the new sidecar files that was added in
6672af7

I had meant to bring it up. It would be nice not to have HTML depend on those sidecars. If you are in a tight edit loop with something like Codechat or nodemon doing partial rebuilds and you add an audio/video/interactive, you now have to break out of your normal rebuild and go trigger a qr code extration.