I think I may have found a resolution of this problem, that involves doing almost nothing. It appears that sage_docbuild oftern builds image in all three formats - svg, png and pdf. All three types get stored in the html directory and the svg is duplicated:
find local/share/doc/sage/html/en -name 'chart-12*' local/share/doc/sage/html/en/reference/manifolds/_images/chart-12.svg.gz local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.svg.gz local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.png local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.pdf The actual html code seems to only uses the svg files stored in _images. Hopefully I can just remove the others without affecting the html documentation. grep -r chart-12 local/share/doc/sage/html/en/reference/manifolds local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart.html:<img alt="../../_images/chart-12.svg" class="plot-directive" src="../../_images/chart-12.svg" /></figure> Since this seems to be a change between 10.1beta3 and 10.1beta4, I would have to guess that it might be considered a bug. So maybe I should move this back to sage-release? - Marc On Wednesday, June 28, 2023 at 1:13:20 PM UTC-5 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/2c979ad1-3d6e-450c-bf46-7963031790d0n%40googlegroups.com.
