MyOpenMath & SVG

[Mark Fitch]

Tomorrow I will try to discuss this at the dropin. This is early notice.

Currently MOM converts any image from its plot/image routines to PNG
using an internal routine. This is great if the image is a plot or
simple SVG created using the asciisvg commands. However, it is also
possible, and sometimes easier, to simply create the svg xml directly.
This allows randomization in the image (text labels, and
lengths/positions, basically anything). At the moment MOM deletes this
before passing the rest to PreTeXt. MOM could pass the SVG string
through. On the PreTeXt side it would need to be saved to a file, placed
in an appropriate directory with some auto-generated name, and <image>
created to reference it.

I'm not sure how easy/not this would be.

Dr. Mark A. Fitch
Professor of Mathematics

maf...@alaska.edu
907-786-1656
SSB 154
University of Alaska Anchorage
3211 Providence Drive, Anchorage, AK 99508

[Steven Clontz]

In principle, it seems like PreTeXt could accept `<image><svg/></image>` just as it accepts `<image><latex-image/></image>`, and Python routines can treat it just like any other generated asset (even if the "generation" is copy-paste for outputs that understand SVG).

[Rob Beezer]

Sounds like MOM is simply sending

<svg/>

in-between paragraphs (but Mark has sent me a test example, that I will get to
soon). But yes, there will be a generation step in the Python, much as you
describe. We had a good discussion on strategy at Drop-In.

And we need to replace the SVG image with a PreTeXt #image so that static
formats will do the right thing. Strikes me just now that perhaps this could be
a job for the pre-processor, though if the Python is there anyway...

Rob

> 907-786-1656 <tel:(907)%20786-1656>

> SSB 154
> University of Alaska Anchorage
> 3211 Providence Drive, Anchorage, AK 99508
>

> --
> 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...@googlegroups.com>.
> To view this discussion visit
> https://groups.google.com/d/msgid/pretext-dev/b4516691-c251-4f56-b4c4-620af33ef26en%40googlegroups.com <https://groups.google.com/d/msgid/pretext-dev/b4516691-c251-4f56-b4c4-620af33ef26en%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Rob Beezer]

Dear Mark,

Bringing this back to the forum, after some discussion at Drop-In.

I nned, at a minimum, a complete file that looks like exactly what will be given
up by the MOM server, if it were to be sending back SVG versions of image.

In other words, I need to see, in concrete form, exactly what

> MOM could pass the SVG string through.

looks like. (Will look like?)

You sent me a repo of a sample document with two MOM problems. Looks like they
should have images, but I don't see anything at all. Just a #p holding some
numbers (dimensions?). This is with the URL, before our script touches it. For
example:

https://www.myopenmath.com/util/mbx.php?id=901736

The best of all worlds would be if MOM built a soon-tob-released endpoint
("ptx.php"?) that sent back the SVGs and I could just test with that. Otherwise
I need a sample reply and I'll have to work to divert the pretext/pretext
script to work on it.

I'd like to make this happen, but I can't proceed on speculation.

Thanks,
Rob

[Mark Fitch]

I will work with David Lippman to see what we can do. He has to make
some changes to make this happen, and I don't know if he has a dev
server we could use in a test. Expect updates.

[Mark Fitch]

The git repository MOMtest now has the generated-assets folder. This has
the xml from the two MOM problems modified to look like what David
Lippman is updating the MOM code to produce (no ETA on that change at
the moment). For tests pretext needs to be stopped from re-generating
and thus overwriting my modified examples (pretext build print -q for cli).

On 11/15/2024 2:26 PM, 'Rob Beezer' via PreTeXt development wrote:

[Rob Beezer]

On 11/16/24 11:10, 'Mark Fitch' via PreTeXt development wrote:
> The git repository MOMtest now has the generated-assets folder. This has the xml
> from the two MOM problems modified to look like what David Lippman is updating
> the MOM code to produce (no ETA on that change at the moment).

Thanks, looks good (and about as expected). I'll need to hack that into the
workflow for testing, but that is do-able.

> For tests pretext
> needs to be stopped from re-generating and thus overwriting my modified examples
> (pretext build print -q for cli).

No danger there. For exactly this sort of reason, I stick with lower level
tools. And here's for your git-fu - if I did overwrite those, it is an easy
matter with git to resurrect the originals. ;-) That's one of the reasons to
use git - you can often recover gracefully from "stupid" mistakes.

Back into the queue.

Thanks,
Rob

[Rob Beezer]

Dear Mark,

Thanks again for the repository. As expected, I am chasing my tail trying to
modify the existing code so that I can be prepared for future changes.

Discovered an inconsistency in your examples (which is why we are doing it this
way).

One #svg is an #image, one #svg is not in an #image, and a third #svg is an
#image but the closing tag is not right.

1. Will the #svg be inside an #image, or not? I understood not.

2. Can you make corrections and changes, and push them? Rather than you and I
working through me sending you a (speculative) pull request.

Thanks,
Rob

[Mark Fitch]

On 11/18/2024 8:11 AM, 'Rob Beezer' via PreTeXt development wrote:
> Dear Mark,
>

> Thanks again for the repository.  As expected, I am chasing my tail
> trying to modify the existing code so that I can be prepared for
> future changes.
>
> Discovered an inconsistency in your examples (which is why we are
> doing it this way).
>
> One #svg is an #image, one #svg is not in an #image, and a third #svg
> is an #image but the closing tag is not right.
>
> 1.  Will the #svg be inside an #image, or not?  I understood not.

A couple people preferred this, so for now it is the expectation (David
Lippman is planning to program it this way). It does keep it uniform
with other image types. However, I see no use case for it outside MOM
packaging images this way.

>
> 2.  Can you make corrections and changes, and push them? Rather than
> you and I working through me sending you a (speculative) pull request.

Done. MOMtest updated.

[Rob Beezer]

Thanks for the update, Mark, and the explanation. I can deal with whatever, I
just need to know what that is. ;-)

Related, but independent, question.

Right now if the MOM server sends back

<image source="some-url-at-MOM"/>

then the PreTeXt Python goes and downloads that image via the URL to save in a
file for use the way PreTeXt likes it.

Do you expect this is going away as a process, and the embedded SVG will 100%
replace it? If not, I might refactor the current code to handle the XML as XML
not as text. If it goes away, I can get closer to shovel-ready code.

I've got most of the details sorted out and hacked-in on a branch, so could
likely react to the SVGs rather quickly. If the answer above is "it goes away"
then I can work it some more over the next few days to clean-up what I have
going now.

Thanks,
Rob

[Mark Fitch]

For documentation sake here are answers.

Graphics generated by MOM which include plots and its asciisvg function
will be unchanged and must be processed as currently. Images inserted by
question writers that have PNG (or other static) will need to be
processed as currently. This is the <image source="some-url-at-MOM" />.

Yes, the asciisvg will come as PNG because that is how that is processed
internally. Non-PNG files uploaded (most notably BMP) are a problem to
be dealt with by the question writer/user. Changing that image to PNG
works fine in MOM, so that is what we can advise.

The only use of <image><svg>stuff</svg></image> will be directly
inserted SVG images.

[Rob Beezer]

Thanks, Mark, for summarizing our Drop-In discussions.

Status report: I've cut over existing Python to use lxml (rather than strings
and regular expressions) to manipulate the PreteXt XML generated by a MOM
server. More Pythonic, more PreTeXt-y. And I've learned a lot about how to
make lxml do what you want with namespaces (take note, David A).

I could push, but haven't. Thinking about rearranging the code to better
anticipate the appearance of SVGs inside #image. But that should not mean
waiting on me anymore. I think I can now very quickly react to SVG coming back
from the MOM server.

As before, thanks for your help and coordination with this. I'm going to go lob
a grenade into the MOM discussion. ;-)

Rob

[Mark Fitch]

Resurrecting this thread for a status report and to document a temp feature of MOM. There is a flag available that will keep SVG graphics that are embedded in a MOM question. The result is <image><svg>...</svg></image>. HTML below includes a specific problem with embedded SVG.

I checked the current MOM image processing code, and it seems like adding SVG processing would not be hard (I might be willing to try my hand at the code with some guidance). This assumes other SVG developments don't interact too much. Thoughts?

Also some code was being held back at one point as we considered generating a fixed randomization seed for print editions. Is it still desired to deal with that first? I am working on MOM  homework in my text for the next month, so I am motivated for a while.

https://www.myopenmath.com/util/mbx.php?id=901736&preservesvg=true