I tried making this change (which would affect each ".. PLOT:" directive)
but the documentation failed to build:
diff --git a/src/sage_docbuild/conf.py b/src/sage_docbuild/conf.py
index 9b6b37480b..db33c4b1d6 100644
--- a/src/sage_docbuild/conf.py
+++ b/src/sage_docbuild/conf.py
@@ -115,7 +115,7 @@ def sphinx_plot(graphics, **kwds):
mpl.rcParams['figure.figsize'] = [8.0, 6.0]
mpl.rcParams['figure.dpi'] = 80
mpl.rcParams['savefig.dpi'] = 100
- fn = tmp_filename(ext=".png")
+ fn = tmp_filename(ext=".svg")
graphics.save(fn)
img = mpimg.imread(fn)
plt.imshow(img)
The error: ValueError: filetype .svg not supported by save()
On Wednesday, June 28, 2023 at 11:13:20 AM UTC-7 Marc Culler wrote:
> I am not proposing using gzipped svg for a normal sage build. I only want
> to do it for the Sage_macOS app, which will have a simple self-contained
> server running on the loopback interface that provides gzipped content
> (with the Content-Encoding header set to "gzip"). Of course I would be
> happy to work on incorporating the same mechanism in a standard build of
> Sage, and that would reduce the footprint of the documentation
> considerably. But in the short term, for the macOS binary, I need to be
> able to find the magic switch which makes sage_docbuild use svg instead of
> png.
>
> I don't know how much of a problem the image size will pose. There are
> some svg images already in the documentation, which seem to work, but I
> hadn't gotten to the stage of worrying about that yet.
>
> - Marc
> On Wednesday, June 28, 2023 at 12:50:31 PM UTC-5 Michael Orlitzky wrote:
>
>> On Wed, 2023-06-28 at 10:07 -0700, Marc Culler wrote:
>> >
>> > BOTTOM LINE: we get more than a 90% reduction in size simply by
>> choosing to
>> > use the .svg extension when saving the plot instead of the .png
>> extension.
>> >
>>
>> SVG is the right choice for most graphics, but there are some practical
>> problems:
>>
>> * The documentation needs to know how big to display an SVG graphic.
>> With a PNG, the default is to use the image's height/width in
>> pixels, but with SVG, there's no such obvious default.
>>
>> * gzipped SVG doesn't work over the file:/// protocol in my firefox.
>> This hasn't been a big enough problem for me yet to diagnose it,
>> so I can't say how serious a problem it is. (I'll play around later
>> today.)
>>
>> * Browser support in firefox/chrome alternatives still isn't great,
>> although I think webkit is getting a new SVG renderer "soon." This
>> is actually relevant more today than it was ten years ago, because
>> adding rust to firefox made it less portable, meaning you're
>> more likely to be stuck with one of those alternatives.
>>
>> * Somebody's got to go through and look at 100MB of images to make
>> sure they still look right if we change 'em.
>>
>>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/52dbf676-29ca-4e78-b453-a6cdfabc83dfn%40googlegroups.com.
