tikz in WeBWorK: what path to take for PreTeXt?
64 views
Skip to first unread message
Alex Jordan
Apr 19, 2021, 8:55:21 PM4/19/21
to prete...@googlegroups.com
It's now possible for a WeBWorK problem to have tikz code and make
nice pictures. (This is a WW feature, not yet fully integrated with
PreTeXt.)
The WW tikz code can generate PNG or SVG output. But at least for
right now, it's pick one, not both. So for PTX output from WW, I would
have it make the PNG so that it's an image which will work in print as
well as HTML.
With a little work, I could instead make the PTX output just be the
tikz code, wrapped in a `latex-mage`. Then PreTeXt could make various
image formats for static output. (As a reminder, live WW HTML output
would use whatever that WW server would normally do for HTML output,
which could be PNG or SVG.)
Then after you make your WW representations, you would have to do
image building.
What is the better path to pursue? (1) just grab PNG image files and
store them like we already do or (2) grab the tikz code and publishers
must take an additional step to build images (SVG, most likely)?
There could be (3), where both happen. As in make a latex-image
element, but also there is some fallback to the harvested PNG if an
SVG has not been built.
nice pictures. (This is a WW feature, not yet fully integrated with
PreTeXt.)
The WW tikz code can generate PNG or SVG output. But at least for
right now, it's pick one, not both. So for PTX output from WW, I would
have it make the PNG so that it's an image which will work in print as
well as HTML.
With a little work, I could instead make the PTX output just be the
tikz code, wrapped in a `latex-mage`. Then PreTeXt could make various
image formats for static output. (As a reminder, live WW HTML output
would use whatever that WW server would normally do for HTML output,
which could be PNG or SVG.)
Then after you make your WW representations, you would have to do
image building.
What is the better path to pursue? (1) just grab PNG image files and
store them like we already do or (2) grab the tikz code and publishers
must take an additional step to build images (SVG, most likely)?
There could be (3), where both happen. As in make a latex-image
element, but also there is some fallback to the harvested PNG if an
SVG has not been built.
Steven Clontz
Apr 21, 2021, 11:10:13 AM4/21/21
to PreTeXt development
Shipping PNG to authors seems to require them to have less dependencies installed, which is always my preference.
This feels like a specific case of a more general issue, that it seems that there's no great way to ship low-footprint vector image source code that Just Works in all the domains PreTeXt lives in, particularly both HTML and LaTeX. If you ship Tikz source, you have to build it locally before it can be used in the browser (modulo https://tikzjax.com/ which I'm unsure the stability of). If you ship SVG, there apparently is a TeX package to handle it, but it relies on some other dependencies that are (hopefully) installed on the user's machine.
What I wish existed is a simple image preproessor language: the [PreTeXt/WebWorK/CheckIt] author writes e.g. `<circle radius="2" center-x="1" center-y="3"/>`, which can be transpiled (either locally or in the browser) to low-footprint TikZ and SVG source. Basically, a language that is for images as PreTeXt is for documents: just like PreTeXt can't produce arbitrary LaTeX, this language shouldn't be able to describe all possible images, but enough images that are sufficient for most use-cases (and could be also expressed in an accessible manner too)...
David Farmer
Apr 21, 2021, 11:22:28 AM4/21/21
to PreTeXt development
I keep waiting for a critical mass of people to have the energy
to start thinking about this. I had hoped it would start at the
AIM Braille workshop last August, but the work on images there
(and in the ongoing followup) has focused on the current pipeline
that starts with TikZ.
> 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 on the web visithttps://groups.google.com/d/msgid/pretext-dev/bcb38796-a941-46db-ab87-3988c13723e2n%40googlegro
> ups.com.
>
>
Alex Jordan
Apr 21, 2021, 12:54:16 PM4/21/21
to prete...@googlegroups.com
That sounds interesting and I think that should maybe be discussed on
a new thread. But to clarify, my question is (chiefly) about WeBWorK
source getting converted to something PreTeXt will use. WeBWorK source
is not XML, and it seems to me unlikely that a new image building
engine will come into use in WeBWorK any time soon.
So from the perspective of starting with a WeBWorK problem (say from
the OPL) that has tikz code built into it, I'd like to know what would
be best for handling that.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/alpine.LRH.2.21.2104211117550.7954%40li375-150.members.linode.com.
a new thread. But to clarify, my question is (chiefly) about WeBWorK
source getting converted to something PreTeXt will use. WeBWorK source
is not XML, and it seems to me unlikely that a new image building
engine will come into use in WeBWorK any time soon.
So from the perspective of starting with a WeBWorK problem (say from
the OPL) that has tikz code built into it, I'd like to know what would
be best for handling that.
Sean Fitzpatrick
Apr 21, 2021, 12:54:30 PM4/21/21
to prete...@googlegroups.com
I wonder if Michael would have any thoughts about doing this with Asymptote?
Doesn't help the original WeBWorK issue, and doesn't quite help the
dependency issue (since a relatively recent version of the asy binary is
needed), but:
- we could make a sensible default style file that can be adjusted as needed
- direct output into almost every conceivable format is supported natively
- it could help with the initial "geez, Asymptote seems complicated"
hurdle for authors
Doesn't help the original WeBWorK issue, and doesn't quite help the
dependency issue (since a relatively recent version of the asy binary is
needed), but:
- we could make a sensible default style file that can be adjusted as needed
- direct output into almost every conceivable format is supported natively
- it could help with the initial "geez, Asymptote seems complicated"
hurdle for authors
Sean Fitzpatrick
Apr 21, 2021, 12:57:28 PM4/21/21
to prete...@googlegroups.com
How hard would it be to add a webwork-tikz-extraction phase in the
pretext script?
I think PNG is fine since it's portable (pun intended) but vector
graphics would be better.
If we can build it into the script (even if it's one extra step in the
build process/makefile) I think publishers might prefer to have access
to the SVG.
pretext script?
I think PNG is fine since it's portable (pun intended) but vector
graphics would be better.
If we can build it into the script (even if it's one extra step in the
build process/makefile) I think publishers might prefer to have access
to the SVG.
Michael Doob
Apr 21, 2021, 1:21:05 PM4/21/21
to PreTeXt development
I would think something like the following would work:
1. Embed the tikz code in:
\documentclass{standalone}
\usepackage{tikz}
\begin{document}
...
\end{document}
2. Run LaTeX to get a dvi file.
3. Run something like:
dvisvgm --font-format=woff --exact --zoom=-1
on the dvi file to get the desired svg file.
I'm a bit up to my ears in something else right now, and this is a bit off the
top of my head, but I think something this should
work ok (I'm assuming that the tikz is a single figure on one page).
Alex Jordan
Apr 21, 2021, 1:52:11 PM4/21/21
to prete...@googlegroups.com
> I think PNG is fine since it's portable (pun intended) but vector
graphics would be better.
The immediate issue would be using the graphics in PTX PDF output.
graphics would be better.
Either having a PNG is necessary (between the two options under
discussion) or having the actual tikz code is necessary.
> How hard would it be to add a webwork-tikz-extraction phase in the
pretext script?
source where you might have a "webwork" element and it might have a
"latex-image" inside of it. I think that may be where you are thinking
if you are thinking about a webwork-tikz-extraction phase. That's an
important thing to work on at a later stage.
I would like input on when I have a PG problem that was born in the
WeBWorK world somewhere. It was not born out of PreTeXt. Someone coded
a tikz-based image into it, which is a new WW feature to be able to
do.
Now a PTX book might call this problem from the host server. What is
returned is a "webwork-reps" element that has a "static" child, and
inside that "static" it is XML that very closely resembles what a
human might have written into a PTX "exercise", with "statement" etc.
There are no "var" elements for example. When there is an image to
load, it will be an "image" element inside the "static".
The question is basically should that "image" have a "src" attribute
that refers to a PNG file that WW generated? Otr should that "image"
element have a "latex-image" child with some tikz code? In the latter
case, no tikz is extracted from a "webwork". It would be extracted
from an "exercise" in the assembled source, after the content of the
"static" has replaced the "webwork" in that source.
Or option 3 is somehow both. An "image" with a "latex-image" but also
the "image" uses an attribute to point to that PNG file as a fallback
if the tikz has not been processed locally yet.
Rob Beezer
Apr 21, 2021, 1:58:36 PM4/21/21
to prete...@googlegroups.com
Putting this thread back onto Alex's initial questions(s).
On 4/19/21 5:55 PM, Alex Jordan wrote:
> It's now possible for a WeBWorK problem to have tikz code and make
> nice pictures. (This is a WW feature, not yet fully integrated with
> PreTeXt.)
>
> The WW tikz code can generate PNG or SVG output. But at least for
> right now, it's pick one, not both. So for PTX output from WW, I would
> have it make the PNG so that it's an image which will work in print as
> well as HTML.
Yes, I think PNG back from a WW server makes sense. At a minimum, we need to
accomodate an OPL problem that might use this new feature. So we need to handle
the case where we don't have as much control. SVG in HTML is best, but other
formats (Kindle) will require PNG.
> With a little work, I could instead make the PTX output just be the
> tikz code, wrapped in a `latex-mage`. Then PreTeXt could make various
> image formats for static output. (As a reminder, live WW HTML output
> would use whatever that WW server would normally do for HTML output,
> which could be PNG or SVG.)
>
> Then after you make your WW representations, you would have to do
> image building.
I think this makes sense for the static representation. With the
pretext/pretext script we can examine various stages of processing for the
necessity of performing certain steps. Which means it would not be an extra
step. For example, we can see
$webwork-representations//static/latex-image
(or not), and react accordingly. Then we get the "right" format(s) for the
outputs at hand. Do you imagine raw TikZ landing in the LaTeX/PDF output? With
all the right libraries and setup that WW presumes or author provides?
> What is the better path to pursue? (1) just grab PNG image files and
> store them like we already do or (2) grab the tikz code and publishers
> must take an additional step to build images (SVG, most likely)?
> There could be (3), where both happen. As in make a latex-image
> element, but also there is some fallback to the harvested PNG if an
> SVG has not been built.
Rob
On 4/19/21 5:55 PM, Alex Jordan wrote:
> It's now possible for a WeBWorK problem to have tikz code and make
> nice pictures. (This is a WW feature, not yet fully integrated with
> PreTeXt.)
>
> The WW tikz code can generate PNG or SVG output. But at least for
> right now, it's pick one, not both. So for PTX output from WW, I would
> have it make the PNG so that it's an image which will work in print as
> well as HTML.
accomodate an OPL problem that might use this new feature. So we need to handle
the case where we don't have as much control. SVG in HTML is best, but other
formats (Kindle) will require PNG.
> With a little work, I could instead make the PTX output just be the
> tikz code, wrapped in a `latex-mage`. Then PreTeXt could make various
> image formats for static output. (As a reminder, live WW HTML output
> would use whatever that WW server would normally do for HTML output,
> which could be PNG or SVG.)
>
> Then after you make your WW representations, you would have to do
> image building.
pretext/pretext script we can examine various stages of processing for the
necessity of performing certain steps. Which means it would not be an extra
step. For example, we can see
$webwork-representations//static/latex-image
(or not), and react accordingly. Then we get the "right" format(s) for the
outputs at hand. Do you imagine raw TikZ landing in the LaTeX/PDF output? With
all the right libraries and setup that WW presumes or author provides?
> What is the better path to pursue? (1) just grab PNG image files and
> store them like we already do or (2) grab the tikz code and publishers
> must take an additional step to build images (SVG, most likely)?
> There could be (3), where both happen. As in make a latex-image
> element, but also there is some fallback to the harvested PNG if an
> SVG has not been built.
Rob Beezer
Apr 21, 2021, 2:14:57 PM4/21/21
to prete...@googlegroups.com
On 4/21/21 9:54 AM, Alex Jordan wrote:
> That sounds interesting and I think that should maybe be discussed on
> a new thread.
Exactly. When the OP asks to release his thread from the hijackers, please
> That sounds interesting and I think that should maybe be discussed on
> a new thread.
think about doing so. ;-)
Now on a thread titled "Graphics languages".
Alex Jordan
Apr 27, 2021, 12:57:16 PM4/27/21
to prete...@googlegroups.com
I have something working now in a webwork2 branch. For these tikz
pictures, for static PTX output from WeBWorK, the output has like:
<image source="url/to/foo.tgz"/>
And foo.tgz contains the .tex, .pdf, .svg, and .png. (I could give it
more if helpful, like .gif and .eps or whatever ImageMagick can make.)
This much is working on a branch.
The pretext script would download the tgz file, unpack it, rename the
image files (like webwork-image-42.png, etc.) Build static content in
a way that uses the image formats wisely. Etc. So the actual
webwork-representations file will not have `<image
source="url/to/foo.tgz"/>`, rather it will have things like `<image
source="images/foo"/>` (although Rob may need to help me understand if
"images/" is a good folder name for these things.)
Also when I say it has .tex, I mean it will have a complete .tex file
from \documentclass to \end{document}, not just the tikz snippet. So
it's not the appropriate thing to drop into a "latex-image". That's
the one thing this will not have, and I think that is OK.
Thoughts? Is it weird to have a .tgz as image source? It's just
temporary during WW harvest time.
pictures, for static PTX output from WeBWorK, the output has like:
<image source="url/to/foo.tgz"/>
And foo.tgz contains the .tex, .pdf, .svg, and .png. (I could give it
more if helpful, like .gif and .eps or whatever ImageMagick can make.)
This much is working on a branch.
The pretext script would download the tgz file, unpack it, rename the
image files (like webwork-image-42.png, etc.) Build static content in
a way that uses the image formats wisely. Etc. So the actual
webwork-representations file will not have `<image
source="url/to/foo.tgz"/>`, rather it will have things like `<image
source="images/foo"/>` (although Rob may need to help me understand if
"images/" is a good folder name for these things.)
Also when I say it has .tex, I mean it will have a complete .tex file
from \documentclass to \end{document}, not just the tikz snippet. So
it's not the appropriate thing to drop into a "latex-image". That's
the one thing this will not have, and I think that is OK.
Thoughts? Is it weird to have a .tgz as image source? It's just
temporary during WW harvest time.
> --
> 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 on the web visit https://groups.google.com/d/msgid/pretext-dev/d3b88e48-b11b-526c-0b4f-a57cf8c87aee%40ups.edu.
> 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.
Rob Beezer
Apr 27, 2021, 1:28:21 PM4/27/21
to prete...@googlegroups.com
Dear Alex,
Yes, it is weird. ;-)
I think I understand; this is PTX coming back from a WW server, what I like to
call "webwork representations". Then a PTX conversion, like pretext-latex.xsl
is eventually going to do something with it. Or maybe even sooner,
pretext/pretext is going to do something with it. In any event, no publisher
will see it, no author will write it.
If that's all close to right, then image/@source will likely just complicate
things. Since it is only distinguishable by the suffix on the filename?
So use an internal element name?
<webwork-image-bundle filename="foo.tgz"/>
But perhaps start to use a "pretext-internal" namespace (alias "pi") which
believe is a good practice and I have started doing (in pre-processing mostly,
iirc). Holler if grep does not find you any examples.
I hope to work on image management today, and hope to have something to show for
it. So best to be very flexible on directories where these image materialize
and migrate. Ping me if push-comes-to-shove on that in the next few days.
Rob
Yes, it is weird. ;-)
I think I understand; this is PTX coming back from a WW server, what I like to
call "webwork representations". Then a PTX conversion, like pretext-latex.xsl
is eventually going to do something with it. Or maybe even sooner,
pretext/pretext is going to do something with it. In any event, no publisher
will see it, no author will write it.
If that's all close to right, then image/@source will likely just complicate
things. Since it is only distinguishable by the suffix on the filename?
So use an internal element name?
<webwork-image-bundle filename="foo.tgz"/>
But perhaps start to use a "pretext-internal" namespace (alias "pi") which
believe is a good practice and I have started doing (in pre-processing mostly,
iirc). Holler if grep does not find you any examples.
I hope to work on image management today, and hope to have something to show for
it. So best to be very flexible on directories where these image materialize
and migrate. Ping me if push-comes-to-shove on that in the next few days.
Rob
Alex Jordan
Apr 27, 2021, 3:29:21 PM4/27/21
to prete...@googlegroups.com
> If that's all close to right, then image/@source will likely just complicate
> things. Since it is only distinguishable by the suffix on the filename?
> So use an internal element name?
> <webwork-image-bundle filename="foo.tgz"/>
You are right on all counts. It will only be distinguishable based on
> things. Since it is only distinguishable by the suffix on the filename?
> So use an internal element name?
> <webwork-image-bundle filename="foo.tgz"/>
the file's extension. I should say that this is also the case on the
WeBWorK end though. The mechanism that drops the "image" into the
problem statement is the same as the mechanism for other kinds of
images. The part of that mechanism that handles PTX output could "see"
the ".tgz" and react to change the output to use
"webwork-image-bundle" instead of "image".
I lean against doing it that way, but I could be persuaded. It would
mean more PTX-specific code in webwork2, which makes me uneasy. The
more specific PTX code exists in WW, the more the possibility that in
the year 2025, someone is using WW version X and PreTeXt is at commit
Y, and they don't work best together because WW version X is a little
outdated, but it's out of that person's hands to upgrade it. But if WW
version X still has minimal PTX-specific code, then PreTeXt commit Y
can more easily be adapted to handle that kind of issue.
Rob Beezer
Apr 27, 2021, 3:52:28 PM4/27/21
to prete...@googlegroups.com
Do you plan to intercept, or filter on "*.tgz", in the pretext/pretext script,
or later with XSL?
If *.tgz appears from a WW server and is dealt with via Python before any XSL
touches it, that's fine, I guess. But I don't want XSL all over the place to
have to recognize image/@source as something *very* different based on the
extension of a filename.
We've already (at least implicity) decided that PTX from a WW server needs work
before being useful?
Rob
or later with XSL?
If *.tgz appears from a WW server and is dealt with via Python before any XSL
touches it, that's fine, I guess. But I don't want XSL all over the place to
have to recognize image/@source as something *very* different based on the
extension of a filename.
We've already (at least implicity) decided that PTX from a WW server needs work
before being useful?
Rob
Alex Jordan
Apr 27, 2021, 3:58:19 PM4/27/21
to prete...@googlegroups.com
> Do you plan to intercept, or filter on "*.tgz", in the pretext/pretext script,
Yes. So there is a step right now where the pretext script has to turn
something like:
a2aa2aa4-6ab6-34b7-8b0f-1bdeeded1f59___8a21c543-d103-388e-8266-97466c56d640.png
into
webwork-image-42.png
So that same place in the pretext script would see
a2aa2aa4-6ab6-34b7-8b0f-1bdeeded1f59___8a21c543-d103-388e-8266-97466c56d640.tgz
and do things from there.
webwork-representations would end up with:
<image source="images/webwork-image-42"/>
(If I understand right, leaving off an extension would make HTML look
for SVG, PDF look for PNG, etc.) So XSL would not see anything new.
Rob Beezer
Apr 27, 2021, 4:44:20 PM4/27/21
to prete...@googlegroups.com
Sounds good.
@source, with no extension, is PDF for LaTeX, SVG for HTML, and may be/become
PNG for EPUB.
Rob
@source, with no extension, is PDF for LaTeX, SVG for HTML, and may be/become
PNG for EPUB.
Rob
Reply all
Reply to author
Forward
0 new messages