HTML ids in SVGs from math
13 views
Skip to first unread message
Rob Beezer
Dec 26, 2025, 3:29:39 PM12/26/25
to prete...@googlegroups.com
"Austin, we've had a problem here."
Or something like that. My problem, but I think it affects David A. and I think
I could use his counsel from Mission Control.
Make an #exercise. Put some math in one of its SOLUTION-LIKE. Now, also
single-out that SOLUTION-LIKE as part of a #solutions that appears on the same
HTML page as the #exercise, when chunked.
When making offline math for EPUB (say), we strip out all the math, send to a
local node version of MathJax and get back SVG images for the math. These have
embedded glyphs with ids, and then these glyphs get #svg:use'd in the right
places via the ids (like an include).
Now in creating the #solutions, we process the SOLUTION-LIKE into output *based
on the original source instance* and we pick up the same SVG for any math. If
it is on the same page, the ids are all duplicated and the EPUB validator goes
nuts. (There does not seem to be any harm in rendering the duplicate.) There
are some PreTeXt ids that are also duplicated. I suspect a PreFigure diagram in
a SOLUTION-LIKE may meet the same fate.
What to do?
1. Rewrite the SVG and follow the svg:use to just make repeated copies of the
glyphs and be inefficient about copies laying about within a math-image.
Removes the offending duplicate id.
2. Rewrite the SVG and prefix the ids (and their employment in #svg:use) so
they are more unique. Maybe this prefix needs to come from a @label on the
#solutions (there is no other logical parent to consult), and so will need to
burrow down through the solutions generator apparatus to when the math gets
rendered.
3. Form a #solutions in the pre-processor by duplicating original versions of
SOLUTION-LIKE so that the same math actually gets built by MathJax as if
distinct, and PreTeXt ids are distinct, etc.
#1 and #2 might require the same approach for PreFigure diagrams, and who knows
what else might show up as identical SVGs (other images?). #1 might make
bloated SVGs, #2 seems a bit fraught.
#3 scares me a bit, mostly since we try to duplicate headings, and not make
headings holding empty content. A #solutions might cover multiple divisions,
or divisions which have nested divisions down several levels. And the
#solutions might be placed in a division several levels deep already. So there
is some elaborate code to make headings to mirror the organization of the
exercises, but also fit in where placed. But it does feel like the right
long-term solution.
Partly thinking our loud, partly alerting David A, partly looking for approach
#4 that might be more palatable.
Making copies of content is always a dangerous idea...
Rob
Or something like that. My problem, but I think it affects David A. and I think
I could use his counsel from Mission Control.
Make an #exercise. Put some math in one of its SOLUTION-LIKE. Now, also
single-out that SOLUTION-LIKE as part of a #solutions that appears on the same
HTML page as the #exercise, when chunked.
When making offline math for EPUB (say), we strip out all the math, send to a
local node version of MathJax and get back SVG images for the math. These have
embedded glyphs with ids, and then these glyphs get #svg:use'd in the right
places via the ids (like an include).
Now in creating the #solutions, we process the SOLUTION-LIKE into output *based
on the original source instance* and we pick up the same SVG for any math. If
it is on the same page, the ids are all duplicated and the EPUB validator goes
nuts. (There does not seem to be any harm in rendering the duplicate.) There
are some PreTeXt ids that are also duplicated. I suspect a PreFigure diagram in
a SOLUTION-LIKE may meet the same fate.
What to do?
1. Rewrite the SVG and follow the svg:use to just make repeated copies of the
glyphs and be inefficient about copies laying about within a math-image.
Removes the offending duplicate id.
2. Rewrite the SVG and prefix the ids (and their employment in #svg:use) so
they are more unique. Maybe this prefix needs to come from a @label on the
#solutions (there is no other logical parent to consult), and so will need to
burrow down through the solutions generator apparatus to when the math gets
rendered.
3. Form a #solutions in the pre-processor by duplicating original versions of
SOLUTION-LIKE so that the same math actually gets built by MathJax as if
distinct, and PreTeXt ids are distinct, etc.
#1 and #2 might require the same approach for PreFigure diagrams, and who knows
what else might show up as identical SVGs (other images?). #1 might make
bloated SVGs, #2 seems a bit fraught.
#3 scares me a bit, mostly since we try to duplicate headings, and not make
headings holding empty content. A #solutions might cover multiple divisions,
or divisions which have nested divisions down several levels. And the
#solutions might be placed in a division several levels deep already. So there
is some elaborate code to make headings to mirror the organization of the
exercises, but also fit in where placed. But it does feel like the right
long-term solution.
Partly thinking our loud, partly alerting David A, partly looking for approach
#4 that might be more palatable.
Making copies of content is always a dangerous idea...
Rob
David Austin
Dec 27, 2025, 9:19:51 AM12/27/25
to prete...@googlegroups.com
You just had to stir the O2 tanks, didn't you?
PreFigure is immune from this bit of pleasantry since the generated SVGs are kept in separate files and included in an XHTML document with the @src attribute of an #img. The restriction on duplicate ids only applies within an XHTML file. Which leads to
4. Put the #solutions division into its own XHTML file(s) and update the spine and manifest appropriately.
My reading of the EPUB documentation is that this will not change the document's appearance or flow, but the duplicate ids will no longer trigger the validator.
--
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/MTAwMDAwNy5iZWV6ZXI.1766780975%40pnsh.
David Austin
Dec 27, 2025, 10:59:21 AM12/27/25
to prete...@googlegroups.com
Well, maybe I didn't read carefully enough. I tried a small test case but EPUB puts a page break between content in different XHTML files.
Rob Beezer
Dec 27, 2025, 2:50:15 PM12/27/25
to prete...@googlegroups.com
On 12/27/25 07:59, David Austin wrote:
> Well, maybe I didn't read carefully enough.
I was going to compliment you for a full understanding of my (brief)
> Well, maybe I didn't read carefully enough.
explanation. (And for continuing the Apollo 13 story line.)
> I tried a small test case but EPUB
> puts a page break between content in different XHTML files.
#4 is a great idea, but we do not have such control over chunking. For a #book
(without #part), I am chunking at level 2 (#section and peers). This is fixed
in the conversion. And there are still problems because we are missing
#introduction for #chapter, and similar, from the HTML chunking. So I already
have a big problem there.
Futhermore, #solution can go anywhere any other division might go. Like say, a
child of a #subsection. And HTML lacks a notion of "include"-ing a file, absent
Javascript or PHP or an iframe. All impossible or bad ideas.
The typical use of a #backmatter #solutions will be fine (distinct page from
original instance), which partly explains why we have not seen this until now.
I'll need to review the code for #solutions, before assuming moving it into
-assembly is a minefield.
More good ideas welcome!
Rob
> dev%2Bunsu...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-
> dev/MTAwMDAwNy5iZWV6ZXI.1766780975%40pnsh <https://groups.google.com/d/
> msgid/pretext-dev/MTAwMDAwNy5iZWV6ZXI.1766780975%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-
> --
> 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
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CANXmVMADKbt4B8V0LkgCWxXf5kenRkJo5KRzXTmNKVGY2ep27g%40mail.gmail.com <https://
> groups.google.com/d/msgid/pretext-dev/
> CANXmVMADKbt4B8V0LkgCWxXf5kenRkJo5KRzXTmNKVGY2ep27g%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
Alex Jordan
Dec 27, 2025, 3:10:17 PM12/27/25
to prete...@googlegroups.com
Idly thinking about this, and I wonder how reasonable is it that an author wants to reveal a solution-like locally (immediately following the exercise) and also wants to reveal it gathered up in a solutions somewhere else. Especially on the same HTML page. I feel like I'd always want one or the other.
In the spirit of brainstorming, one idea is to suppress the local solution-like. A crude way to do this could be that presence of even one solutions/@answers could override the global publisher variable for showing local answers. Etc. This wouldn't solve all the issues and probably someone somewhere does want both at the same time. Maybe it's another square peg for a round hole.
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/MTAwMDAxMC5iZWV6ZXI.1766865013%40pnsh.
Rob Beezer
Dec 27, 2025, 3:49:36 PM12/27/25
to prete...@googlegroups.com
Thanks, Alex.
Suppose a #chapter contains several #section, along with an #exercises at the
end of each #section. Then you want one grand #solutions at the end of the
#chapter - which will have the headings of the relevant #section.
I don't think it is too far-fetched to allow a SOLUTION-LIKE to appear where an
#exercise is authored and again in the #solutions. Maybe ill-advised? Now say
you chunk by chapters, and then the two instances of the SOLUTION-LIKE will both
be on the same page.
Anyway, there is far too much flexibility in placing a #solutios, and what it
will produce. Trying to determine when we do, or don't, respect those decisions
in an author's source will be another minefield. And only to feed the EPUB
validator (though an eventual solution should improve our HTML output as well).
Rob
On 12/27/25 12:10, Alex Jordan wrote:
> Idly thinking about this, and I wonder how reasonable is it that an author wants
> to reveal a solution-like locally (immediately following the exercise) and also
> wants to reveal it gathered up in a solutions somewhere else. Especially on the
> same HTML page. I feel like I'd always want one or the other.
>
> In the spirit of brainstorming, one idea is to suppress the local solution-like.
> A crude way to do this could be that presence of even one solutions/@answers
> could override the global publisher variable for showing local answers. Etc.
> This wouldn't solve all the issues and probably someone somewhere does want both
> at the same time. Maybe it's another square peg for a round hole.
>
> <mailto:pretext-dev%2Bunsu...@googlegroups.com> <mailto:pretext-
> <mailto:pretext->
> > dev%2Bunsu...@googlegroups.com
> <mailto:dev%252Buns...@googlegroups.com>>.
> > dev/MTAwMDAwNy5iZWV6ZXI.1766780975%40pnsh <https://
> groups.google.com/d/ <https://groups.google.com/d/>
> > dev+uns...@googlegroups.com
> <mailto:dev%2Bunsu...@googlegroups.com>>.
> > CANXmVMADKbt4B8V0LkgCWxXf5kenRkJo5KRzXTmNKVGY2ep27g%40mail.gmail.com
> <http://40mail.gmail.com> <https://
> > groups.google.com/d/msgid/pretext-dev/ <http://groups.google.com/d/msgid/
> pretext-dev/>
> > CANXmVMADKbt4B8V0LkgCWxXf5kenRkJo5KRzXTmNKVGY2ep27g%40mail.gmail.com
> <http://40mail.gmail.com>?
> pretext-dev/MTAwMDAxMC5iZWV6ZXI.1766865013%40pnsh>.
> <https://groups.google.com/d/msgid/pretext-dev/CA%2BR-
> jrd%3DbY3wTu%2BFPZNsK9StOzwh3RcqU0iyKp%2BuefGTqfVQkw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
Suppose a #chapter contains several #section, along with an #exercises at the
end of each #section. Then you want one grand #solutions at the end of the
#chapter - which will have the headings of the relevant #section.
I don't think it is too far-fetched to allow a SOLUTION-LIKE to appear where an
#exercise is authored and again in the #solutions. Maybe ill-advised? Now say
you chunk by chapters, and then the two instances of the SOLUTION-LIKE will both
be on the same page.
Anyway, there is far too much flexibility in placing a #solutios, and what it
will produce. Trying to determine when we do, or don't, respect those decisions
in an author's source will be another minefield. And only to feed the EPUB
validator (though an eventual solution should improve our HTML output as well).
Rob
On 12/27/25 12:10, Alex Jordan wrote:
> Idly thinking about this, and I wonder how reasonable is it that an author wants
> to reveal a solution-like locally (immediately following the exercise) and also
> wants to reveal it gathered up in a solutions somewhere else. Especially on the
> same HTML page. I feel like I'd always want one or the other.
>
> In the spirit of brainstorming, one idea is to suppress the local solution-like.
> A crude way to do this could be that presence of even one solutions/@answers
> could override the global publisher variable for showing local answers. Etc.
> This wouldn't solve all the issues and probably someone somewhere does want both
> at the same time. Maybe it's another square peg for a round hole.
>
> > <mailto:david.a...@gmail.com <mailto:david.a...@gmail.com>>> wrote:
> >
> > You just had to stir the O2 tanks, didn't you?
> >
> > PreFigure is immune from this bit of pleasantry since the generated
> SVGs are
> > kept in separate files and included in an XHTML document with the @src
> > attribute of an #img. The restriction on duplicate ids only applies
> within
> > an XHTML file. Which leads to
> >
> > 4. Put the #solutions division into its own XHTML file(s) and update the
> > spine and manifest appropriately.
> >
> > My reading of the EPUB documentation is that this will not change the
> > document's appearance or flow, but the duplicate ids will no longer
> trigger
> > the validator.
> >
> > On Fri, Dec 26, 2025 at 3:29 PM 'Rob Beezer' via PreTeXt development
> > <prete...@googlegroups.com <mailto:prete...@googlegroups.com>
> <mailto:prete...@googlegroups.com <mailto:prete...@googlegroups.com>>>
> >
> > You just had to stir the O2 tanks, didn't you?
> >
> > PreFigure is immune from this bit of pleasantry since the generated
> SVGs are
> > kept in separate files and included in an XHTML document with the @src
> > attribute of an #img. The restriction on duplicate ids only applies
> within
> > an XHTML file. Which leads to
> >
> > 4. Put the #solutions division into its own XHTML file(s) and update the
> > spine and manifest appropriately.
> >
> > My reading of the EPUB documentation is that this will not change the
> > document's appearance or flow, but the duplicate ids will no longer
> trigger
> > the validator.
> >
> > On Fri, Dec 26, 2025 at 3:29 PM 'Rob Beezer' via PreTeXt development
> > <prete...@googlegroups.com <mailto:prete...@googlegroups.com>
> <mailto:pretext->
> > dev%2Bunsu...@googlegroups.com
> <mailto:dev%252Buns...@googlegroups.com>>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> pretext- <https://groups.google.com/d/msgid/pretext->
> > dev/MTAwMDAwNy5iZWV6ZXI.1766780975%40pnsh <https://
> groups.google.com/d/ <https://groups.google.com/d/>
> > msgid/pretext-dev/MTAwMDAwNy5iZWV6ZXI.1766780975%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%2Bunsu...@googlegroups.com> <mailto:pretext- <mailto:pretext->
> >
> > --
> > 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
> > to pretext-dev...@googlegroups.com <mailto:pretext-
> > dev+uns...@googlegroups.com
> <mailto:dev%2Bunsu...@googlegroups.com>>.
> > To view this discussion visit https://groups.google.com/d/msgid/pretext-
> dev/ <https://groups.google.com/d/msgid/pretext-dev/>
> > CANXmVMADKbt4B8V0LkgCWxXf5kenRkJo5KRzXTmNKVGY2ep27g%40mail.gmail.com
> <http://40mail.gmail.com> <https://
> > groups.google.com/d/msgid/pretext-dev/ <http://groups.google.com/d/msgid/
> pretext-dev/>
> > CANXmVMADKbt4B8V0LkgCWxXf5kenRkJo5KRzXTmNKVGY2ep27g%40mail.gmail.com
> <http://40mail.gmail.com>?
> > 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
>
> --
> 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%2Bunsu...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> MTAwMDAxMC5iZWV6ZXI.1766865013%40pnsh <https://groups.google.com/d/msgid/
> dev%2Bunsu...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> pretext-dev/MTAwMDAxMC5iZWV6ZXI.1766865013%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/
> CA%2BR-jrd%3DbY3wTu%2BFPZNsK9StOzwh3RcqU0iyKp%2BuefGTqfVQkw%40mail.gmail.com
> --
> 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/
> <https://groups.google.com/d/msgid/pretext-dev/CA%2BR-
> jrd%3DbY3wTu%2BFPZNsK9StOzwh3RcqU0iyKp%2BuefGTqfVQkw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
David Austin
Dec 28, 2025, 8:53:11 AM12/28/25
to prete...@googlegroups.com
Fixing the ids in MathJax SVGs could be relatively straightforward with proposed solution #2. Perhaps we don't really need to look for a label on a parent element and instead just prepend something like "sol-" in front of the existing id. The elements that get ids appear predictable (#title, #desc and things inside of #defs) as are things that refer to them.
I'm unsure how MathJax creates ids for the glyphs, but it appears that a duplicated math expression creates glyphs having different ids (will that be the same in MJ4?). To be safe, there could be a counter for each id we've seen in the #solutions division and instead of prepending "sol-", we append the current value of the counter for that id. So "MJX-2-TEX-I-1D465-0".
I'm also not sure what kind of other ids PreTeXt could potentially create inside a #solutions. This morning I tried experimenting by adding elements hoping to get more ids. A #description leads to an id, but otherwise I didn't find anything else, probably due to a lack of imagination though.
David
Mission Control Specialist
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/MTAwMDAxMS5iZWV6ZXI.1766868574%40pnsh.
Reply all
Reply to author
Forward
0 new messages