This change should produce only the .svg files:

diff --git a/src/sage_docbuild/conf.py b/src/sage_docbuild/conf.py
index 9b6b37480b..b5d6815c76 100644
--- a/src/sage_docbuild/conf.py
+++ b/src/sage_docbuild/conf.py
@@ -128,7 +128,7 @@ from sage.all_cmdline import *
 """
 
 plot_html_show_formats = False
-plot_formats = ['svg', 'pdf', 'png']
+plot_formats = ['svg']
 
 # We do *not* fully initialize intersphinx since we call it by hand
 # in find_sage_dangling_links.


(I'm not suggesting this as a general change, just for your particular 
situation.)


On Wednesday, June 28, 2023 at 12:07:46 PM UTC-7 Marc Culler wrote:

> Note: I had already compressed the .svg files, hence the .gz extension.
>
> Before compression I get:
>
> % find local/share/doc/sage/html/en -name 'chart-12*'
> local/share/doc/sage/html/en/reference/manifolds/_images/chart-12.svg
>
> local/share/doc/sage/html/en/reference/manifolds/sage/manifolds/chart-12.svg
>
> 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
>
> - Marc
>
> On Wednesday, June 28, 2023 at 2:02:47 PM UTC-5 Marc Culler wrote:
>
>> 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/d838a05a-ab87-49ca-a09b-c64d5c86e037n%40googlegroups.com.

Reply via email to