labeled images in cardsort problems

[David Austin]

As part of the Proteus project, the ULA team authored two #cardsort problems with #prefigure diagrams included in a #response.  Generated images, like #prefigure, #latex-image, and so forth, require a @label attribute, which becomes the filename of the image.  Including a generated image in a cardsort response or premise, however, generates a duplicate-label error in spite of the author including a unique label.  This seems likely to be an issue in other problem types, such as Parsons problems.  Following some discussion in https://github.com/PreTeXtBook/pretext/issues/2927, I'm writing here to start a broader discussion.

Two points from that discussion:

-- The duplicated elements are formed in the assembly process, which includes the labeled images twice.  This triggers the error though the resulting behavior is what we want:  the image is created once with two references to it.  So a reasonable solution is to simply move the check on duplicate labels earlier in the assembly process.

-- One copy of the #image is included inside a #tabular, which violates the schema.  If we want to support this feature, we need another element to support the layout in static builds, perhaps an sbsgroup.

David

[Rob Beezer]

Thanks, David, for moving the discussion here. Bigger than just the original
symptom.

On 7/27/26 04:49, David Austin wrote:
> -- The duplicated elements are formed in the assembly process, which includes
> the labeled images twice.  This triggers the error though the resulting behavior
> is what we want:  the image is created once with two references to it.  So a
> reasonable solution is to simply move the check on duplicate labels earlier in
> the assembly process.

I have this on a branch from yesterday that still needs more work - I was going
to go after some stuff in -assembly anyway, so this is just part of that bigger
package.

Rob

[Rob Beezer]

On 7/27/26 04:49, David Austin wrote:

> -- The duplicated elements are formed in the assembly process, which includes
> the labeled images twice.  This triggers the error though the resulting behavior
> is what we want:  the image is created once with two references to it.  So a
> reasonable solution is to simply move the check on duplicate labels earlier in
> the assembly process.

The duplicate check has been resolved by moving the check earlier in the
assembly process, so it only reflects *authored* source material.

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

[David Austin]

Thanks for your work on this, Rob.

--
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/MTAwMDAyd3BjWWlHYmQ.1785181624%40pnsh.

[Mitch Keller]

Bumping this discussion because one of our grad students is running into issues with prefigure images inside a cardsort, and I think that it's potentially related to the fix that was put in place here. (This is with CLI 2.49.1, and she was not running into errors before upgrading the CLI.) We have a cardsort with four match elements, each containing a single premise/response pair. Each premise contains image/prefigure[@label] and each response is an m. The prefigure generation reports 

bug: * PTX:BUG:   An object (cell) lacks a serial number, search output for "[NUM]"
bug: * PTX:BUG:   An object (cell) lacks a structure number, search output for "[STRUCT]"

(repeated four times)

followed by 

bug: * PTX:BUG:   An object (premise) lacks a serial number, search output for "[NUM]"
bug: * PTX:BUG:   An object (premise) lacks a structure number, search output for "[STRUCT]"

(repeated four times)

In the generated-assets/prefigure directory, we get eight SVG files, despite there being only four prefigure elements. The ones that are used in the HTML that is produced have filenames of the form 16-1-2a-sol.svg, but then we also get a 16-1-2a-sol-11.svg, etc.

Also, in some testing, we have found that when one puts the m in the premise and the image in the response, you have to be really careful about where to drop what you pick up. If you drop on top of the image, then it doesn't actually get dropped. If you drop into the gray zone around the image, then it's fine. Would it be possible for the Javascript that's detecting dropping to accept the full card area as a drop zone even if there's an image? 

Thanks!

[Rob Beezer]

> An object (cell)

Is a #tabular involved?

On 8/24/26 14:57, Mitch Keller wrote:
> Bumping this discussion because one of our grad students is running into issues
> with prefigure images inside a cardsort, and I think that it's potentially
> related to the fix that was put in place here. (This is with CLI 2.49.1, and she
> was not running into errors before upgrading the CLI.) We have a cardsort with
> four match elements, each containing a single premise/response pair. Each
> premise contains image/prefigure[@label] and each response is an m. The
> prefigure generation reports
>
> bug: * PTX:BUG:   An object (cell) lacks a serial number, search output for "[NUM]"
> bug: * PTX:BUG:   An object (cell) lacks a structure number, search output for
> "[STRUCT]"
>
> (repeated four times)
>
> followed by
>
> bug: * PTX:BUG:   An object (premise) lacks a serial number, search output for
> "[NUM]"
> bug: * PTX:BUG:   An object (premise) lacks a structure number, search output
> for "[STRUCT]"
>
> (repeated four times)
>

> In the generated-assets/prefigure directory, we get *eight* SVG files, despite

> https://github.com/PreTeXtBook/pretext/pull/3080 <https://github.com/
> PreTeXtBook/pretext/pull/3080>

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

> a962aca3-8b84-4484-8d4c-3ececb5de6c0n%40googlegroups.com <https://
> groups.google.com/d/msgid/pretext-dev/
> a962aca3-8b84-4484-8d4c-3ececb5de6c0n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[Mitch Keller]

Nope. Not a tabular in sight in the authored source.
--
Mitch Keller

> On Aug 24, 2026, at 17:06, 'Rob Beezer' via PreTeXt development <prete...@googlegroups.com> wrote:
>
> > An object (cell)

> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAweDFpaFdoTzQ.1787609188%40pnsh.

[Rob Beezer]

For static, we put information into #tabular, that is where the #cell comes
from. You say this is prefigure generation, whereas a #cell ancestor (see
subsequent) might be part of building a PDF (not HTML). Might need some
clarification/experimentation around that.

And so, images are not in the schema for parts of a matching problem. Since
they cannot go into a #tabular, for openers.

Then, there is some numbering in captions as part of extracting the PreFigure
source, that is getting fooled by numberless objects, i.e. #cell.

Analysis from Claude next.

[Rob Beezer]

(Claude Opus 5, acting as a review assistant for Rob Beezer)

Mitch, thanks, and yes, a tabular is involved, but it isn't one you wrote. I've
been able to reproduce your errors here with a small cardsort of my own, so here
is what's going on.

When PreTeXt makes the static version of a cardsort, the one that print and
other non-interactive output need, it lays the cards out in a table it builds
for the occasion, and then lists them a second time to form the solution. So
each of your diagrams ends up appearing twice more than you authored it.

Separately, PreTeXt attaches a note to every PreFigure diagram saying where in
the document that diagram lives. It works that out by looking upward from the
image for the nearest thing that carries a number, a figure or an exercise or
the like. In an ordinary document it finds one almost immediately. In a cardsort
it doesn't: the copies now sit inside a table cell and inside a premise, and
neither of those is something PreTeXt numbers. It stops there and reports what
it couldn't find, which is exactly the "lacks a serial number" and "lacks a
structure number" messages you are seeing, once per copy. Four diagrams would
produce a lot of them.

The good news is that for HTML and PDF this is noise rather than damage, since
the location note isn't used in those and the diagrams themselves come out fine.
Where it would matter is a tactile version, because that note gets printed on
the embossed diagram, and it would come out as placeholder text instead of a
location.

The eight files are the part I can't yet account for. On current development
code the two copies of a diagram keep your label, so they write to the same
filename, and four diagrams give four files rather than eight. Something in your
build is losing the label on one of the copies and falling back to an automatic
name, which is what 16-1-2a-sol-11.svg looks like. Could you check whether your
log also contains a line encouraging you to put a label attribute on every
prefigure? If it does, that confirms it, and it would be worth trying a newer
CLI to see whether this has already been dealt with since 2.49.1.

Worth saying as well, since it explains why none of this was built to work:
officially a premise and a response hold text only, so images in them aren't
something the schema allows. Cardsort is still an experimental construct, so
this is the sort of thing we should decide deliberately rather than patch
around, meaning whether images in cards are to be supported at all, and if so
what the static and tactile versions of such a card should look like.

The dragging behaviour you describe, where the cards only accept a drop in the
gray area rather than on the image, is a separate matter on the Runestone side
and I don't have anything useful on it yet.

[David Austin]

Sorry, Rob's Claude response was tl;dr at some point.  Mitch, what happens if you wrap the #image inside a #figure.  PreTeXt wants to attach a numbered element to the PreFigure diagram, which would be needed in, say, the braille conversion.  That message looks like what I see when it can't find something numbered, which is what I think Claude is saying very verbosely.

Building PreFigure SVGs in a PreTeXt environment can make several different SVGs.  For example, if there are no annotations, we'll build a standard SVG foo.svg, which is what goes on the web page, and a separate SVG1.1 compliant file, foo-11.svg for inclusion in the pdf-fo build.  That's why your four #prefigure elements make eight SVGs.  If there are annotations, we make yet another foo-diagcess.svg for serving to the diagcess library.  Triple your money's worth!

David

--
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/MTAwMDAxdW56QTFPeVg.1787611438%40pnsh.

[Rob Beezer]

On 8/24/26 16:12, David Austin wrote:
> Sorry, Rob's Claude response was tl;dr at some point.

I don't think so.

[Mitch Keller]

On Aug 24, 2026, at 18:12, David Austin <david.a...@gmail.com> wrote:

Sorry, Rob's Claude response was tl;dr at some point. 

Well, given that Claude dr the part in my original report where I said that I’m using CLI 2.49.1 and asked me to check what happens with CLI 2.49.1, I found being asked to read Claude’s report insulting.

Mitch, what happens if you wrap the #image inside a #figure.  PreTeXt wants to attach a numbered element to the PreFigure diagram, which would be needed in, say, the braille conversion.  That message looks like what I see when it can't find something numbered, which is what I think Claude is saying very verbosely.

When the same #image is wrapped in a #figure, there is no error if I move it outside the #cardsort. Inside the #cardsort, I unsurprisingly get yet another error. Well, two actually:

warning: * PTX:WARNING: could not translate string with id "cell" into language for code "en-US”

warning: * PTX:WARNING: could not translate string with id "premise" into language for code "en-US”

The #image is inside an #exercise, so it feels like something numbered should be there to latch onto. I had hoped that despite premise/image and response/image not being in schema, David’s report of using it for PROTEUS ULA would indicate that it is something that should get to be supported.

To Claude’s claim of this being innocuous, it’s a major problem for unattended builds like we use in deployment at UW: the CLI treats this as a fatal error and our continuous integration reports a build failure.

Building PreFigure SVGs in a PreTeXt environment can make several different SVGs.  For example, if there are no annotations, we'll build a standard SVG foo.svg, which is what goes on the web page, and a separate SVG1.1 compliant file, foo-11.svg for inclusion in the pdf-fo build.  That's why your four #prefigure elements make eight SVGs.  If there are annotations, we make yet another foo-diagcess.svg for serving to the diagcess library.  Triple your money's worth!

Thanks for resolving the mystery of the -11 files, David. I likely have just not been noticing these when produced for other projects.

pdf-fo (and I suspect EPUB) are two formats that make me think that it’s bad to use #tabular to encode the static version of a #cardsort. This is then outputting a table used for layout into those formats, which is a serious accessibility violation. It seems like the static version should be relying on #sbsgroup as its PreTeXt structure.

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CANXmVMA0X%3DDCEVfryHhAYevCHo_CqQHNwpNOBeRYmv-ukY8_tg%40mail.gmail.com.

-- 
Mitch Keller
mi...@rellek.net

http://www.rellek.net/

[Andrew Scholer]

What do you want those images to do when a screen reader hits a card with them?

Presumably most images worth using will have some non-trivial alt text. Using them inside a card means that we presumably need to read that every time a card is announced (selected, moved, etc...) That is going to be unwieldy.

If the PreFigure has annotations, it is going to get VERY messy very fast trying to make those at all usable while the user is trying to place the card containing them.

From a usability point of view, it might be much better to construct a list of images in the statement, then refer to those by number/letter/whatever in the interactive. That way, the user can carefully review once the images (and return to do so again if they need to), but then does not have to listen to the image description while trying to match "Image A" with "Quadratic" or whatever the matching is asking them to do.

--
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/MTAwMDAybU1GTjguVFM.1787613624%40pnsh.

[Rob Beezer]

On 8/24/26 16:51, Andrew Scholer wrote:
> much better to construct a list of
> images in the statement, then refer to those by number/letter/whatever in the
> interactive.

I like that idea a lot. The reference could be an #xref - though as a knowl, who
knows how that might behave when dragged around.

-Rob

[David Austin]

I agree that having an annotated PreFigure diagram in a cardsort would be a mess and should not be allowed.

The ULA Proteus team spent a lot of time thinking about the differences between problem types and students' experiences interacting with them.  For instance, most cardsort problems could functionally be turned into a series of multiple choice problems so when is a cardsort better than a multiple choice.  I understand the suggestion to place the diagrams in the statement with some type of label that stands in for the diagram in the cardsort, but I think that alters the student experience with an extra layer that increases the cognitive load.  Also, in conversations with students here, there's a novelty to the cardsort problems that is engaging to them.  Maybe I'm putting words in their mouths, but I think dragging something onto a diagram is more engaging than dragging something onto a label.

So if I ran the world, my preference would be to allow diagrams in a cardsort but not annotated diagrams.  I'm happy to discuss at dropin today.

Mitch:  I rebuilt the Proteus version of ULA this morning with 2.49.1 and didn't have any issues.  Here's the source for a cardsort with PreFigure included.

David

--
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/MTAwMDA0SjBobTc2RWs.1787620897%40pnsh.

[Rob Beezer]

On 8/24/26 16:45, Mitch Keller wrote:
> Well, given that Claude dr the part in my original report where I said that I’m
> using CLI 2.49.1 and asked me to check what happens with CLI 2.49.1, I found
> being asked to read Claude’s report insulting.

Well, you better get used to it. Its part of the workflow now.

Claude does produce nonsense sometimes. I think we can all read crtically. But
Claude got this one exactly right - the source was invalid. That should have
been part of the initial report. The route to warning messages was of interest
to me, and should have been of interest to David A.

And this was not Claude's first draft. I posted a summary of the analysis, and
then a manicured version of Claude's report for completeness (and for David A
and me).

> To Claude’s claim of this being innocuous, it’s a major problem for unattended
> builds like we use in deployment at UW: the CLI treats this as a fatal error and
> our continuous integration reports a build failure.

A build failure is exactly the right thing here - everything is working as it
should. Write valid source and you should get useful output.

Rob

[Rob Beezer]

To close out this discussion, I made an example as Andrew suggests (with help
from my disparaged assistant). Using PreFigure diagrams, but without annotations.

Exercise 5.12.8: Cardsort Problem, Graphs of Functions
https://pretextbook.org/examples/sample-book/noparts/html/matching-exercises.html#matching-graph-types

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

Note that Claude, with no prompting whatsoever, (a) added #shortdescription to
each, and (b) did not really give away the answers via the descriptions (a fear
we have had with AI automatically writing image descriptions). These
descriptions could probably be improved with some human intervention, but they
are not all bad.

There is an #xref in each #premise. They work great on page load, opening
*between* cards. After working the problem for a bit, they get a little
confused and some open in the right pane. Maybe they aere "giving away" parts
of the solution, but if so, it wasn't obvious to me right away, so perhaps not.

Rob

[David Austin]

Thanks for sharing that example.  I see what you're getting at.  For comparison, here is a cardsort problem, developed by a Proteus team member, where the responses contain #images inside #figures (I pasted in a screenshot below in case one needs a Runestone account).  This currently builds cleanly in PreTeXt and provides nearby numbered elements to caption the diagrams in a tactile conversion.

My feeling is that the Proteus cardsort provides a more immediate experience of sorting the cards since the reader doesn't need to consult a set of diagrams in a third area of the exercise.  The celebrated assistant says we need to decide whether images are allowed in cards, and I believe this example provides a reason to consider this option.

David

--
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/MTAwMDAwclN0bDZzWjI.1787776733%40pnsh.

[Mitch Keller]

I agree with David that the student experience is better with the images actually in the cards. I found it disorienting when I clicked the xref in the premise, dragged the premise to the correct response, and then the image that had been revealed was still visible in the premise column. Certainly some thought needs to be given to the experience of a screenreader user, but creating something that provides a sub-par user experience for the vast majority of students seems less than ideal and I think there has to be a better compromise. 

I find the figure numbering inside David’s example rather distracting. I understand that it’s necessary for braille, but I think there is a better approach to the static version of cardsort. As I mentioned earlier, using a tabular for the PDF-FO and EPUB versions creates an accessibility issue as the row/column location of something is not relevant. I guess an automated header row could be generated, but what would the header column be? I’m thinking that in static formats, it would probably be better to put the premises in ol[@marker=“1.”] and put the responses in ol[@marker=“A.”]. Maybe put each of those ol inside its own p and put those into a side-by-side? @David: Could PreFigure use the exercise number along with the premise/response marker for the image location to provide identification for the braille version of the image?

On Aug 26, 2026, at 8:04 PM, David Austin <david.a...@gmail.com> wrote:

Thanks for sharing that example.  I see what you're getting at.  For comparison, here is a cardsort problem, developed by a Proteus team member, where the responses contain #images inside #figures (I pasted in a screenshot below in case one needs a Runestone account).  This currently builds cleanly in PreTeXt and provides nearby numbered elements to caption the diagrams in a tactile conversion.

My feeling is that the Proteus cardsort provides a more immediate experience of sorting the cards since the reader doesn't need to consult a set of diagrams in a third area of the exercise.  The celebrated assistant says we need to decide whether images are allowed in cards, and I believe this example provides a reason to consider this option.

David

<image.png>

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CANXmVMCe-C_UGQCvNyPpixgQ_oRCcif%2Bt%3DbkP52wG4PDxsiYKg%40mail.gmail.com.

[David Austin]

@David: Could PreFigure use the exercise number along with the premise/response marker for the image location to provide identification for the braille version of the image?

PreTeXt constructs the caption based on the document structure and drops it into the PreFigure source during the braille conversion.  PreFigure can accept whatever PreTeXt provides.

 

To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/7BA58388-2189-4A4F-B92A-39DE8A578A7D%40rellek.net.

[Rob Beezer]

Right, it sure would be nice if we could stuff an #image into a card and have it
drag-n-drop consistently, even on mobile.

But as we have all observed, not even an #xref behaves right. (I'll be removing
those from the demo.)

Strictly for technical reasons, I don't want to load up these problems with a
lot of complicated stuff. So I do not plan to expand the schema from where it
is now.

And the shortcomings of #tabular on the static side have been known for a while.

Rob

On 8/27/26 07:14, David Austin wrote:
> @David: Could PreFigure use the exercise number along with the premise/
> response marker for the image location to provide identification for the
> braille version of the image?
>
>
> PreTeXt constructs the caption based on the document structure and drops it into
> the PreFigure source during the braille conversion.  PreFigure can accept
> whatever PreTeXt provides.
>
>
>> On Aug 26, 2026, at 8:04 PM, David Austin <david.a...@gmail.com

>> <mailto:david.a...@gmail.com>> wrote:
>>
>> Thanks for sharing that example.  I see what you're getting at.  For

>> comparison, here is acardsort problem <https://author.runestone.academy/
>> ns/books/published/ula-proteus/sec-transforms-geom.html#ula-proteus-2-6-
>> identify-matrix-graphically>, developed by a Proteus team member, where

>> the responses contain #images inside #figures (I pasted in a screenshot
>> below in case one needs a Runestone account).  This currently builds
>> cleanly in PreTeXt and provides nearby numbered elements to caption the
>> diagrams in a tactile conversion.
>>
>> My feeling is that the Proteus cardsort provides a more immediate
>> experience of sorting the cards since the reader doesn't need to consult a
>> set of diagrams in a third area of the exercise.  The celebrated assistant
>> says we need to decide whether images are allowed in cards, and I believe
>> this example provides a reason to consider this option.
>>
>> David
>>
>> <image.png>
>>
>>
>> On Wed, Aug 26, 2026 at 4:38 PM 'Rob Beezer' via PreTeXt development
>> <prete...@googlegroups.com <mailto:prete...@googlegroups.com>> wrote:
>>
>> To close out this discussion, I made an example as Andrew suggests
>> (with help
>> from my disparaged assistant).  Using PreFigure diagrams, but without
>> annotations.
>>
>> Exercise 5.12.8: Cardsort Problem, Graphs of Functions
>> https://pretextbook.org/examples/sample-book/noparts/html/matching-

>> exercises.html#matching-graph-types <https://pretextbook.org/examples/
>> sample-book/noparts/html/matching-exercises.html#matching-graph-types>
>>
>> https://github.com/PreTeXtBook/pretext/pull/3181 <https://github.com/
>> PreTeXtBook/pretext/pull/3181>

>> an 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/MTAwMDAwclN0bDZzWjI.1787776733%40pnsh <https://
>> groups.google.com/d/msgid/pretext-dev/
>> MTAwMDAwclN0bDZzWjI.1787776733%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/CANXmVMCe-
>> C_UGQCvNyPpixgQ_oRCcif%2Bt%3DbkP52wG4PDxsiYKg%40mail.gmail.com <https://
>> groups.google.com/d/msgid/pretext-dev/CANXmVMCe-
>> C_UGQCvNyPpixgQ_oRCcif%2Bt%3DbkP52wG4PDxsiYKg%40mail.gmail.com?
>> utm_medium=email&utm_source=footer>.
>
> --
> Mitch Keller
> mi...@rellek.net <mailto:mi...@rellek.net>
>
> http://www.rellek.net/ <http://www.rellek.net/>

>
> --
> 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/7BA58388-2189-4A4F-B92A-39DE8A578A7D%40rellek.net <https://
> groups.google.com/d/msgid/pretext-dev/7BA58388-2189-4A4F-
> B92A-39DE8A578A7D%40rellek.net?utm_medium=email&utm_source=footer>.

>
> --
> 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/

> CANXmVMAscUPC_KHeyvENrSNDgRSUhdiFT56%2BnDgfhCFpaCVUWw%40mail.gmail.com <https://
> groups.google.com/d/msgid/pretext-dev/
> CANXmVMAscUPC_KHeyvENrSNDgRSUhdiFT56%2BnDgfhCFpaCVUWw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[David Austin]

Thanks for the clarification.  I'll talk with our group more, but we may turn that problem into a multiple choice one, which would be allowed under my reading of the development schema.

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/MTAwMDAxTG50T3JhLUI.1787853147%40pnsh.