Re: [docutils:feature-requests] #40 Option to embed images as data uri in rst2html

On Sun, 26 Nov 2023 16:04:10 -0000
"Günter Milde" via Docutils-develop
<[email protected]> wrote:

> * Embed SVG images directly, not as data URI .
>    +1 Allows interactive SVG images (cf. [feature-requests:#100]).
>    +1 Smaller image size.

I don't understand "Smaller image size".  Embedding SVG directly
into HTML5 pages makes each page larger, and because the SVG
is not referenced as a URI the browser cannot share the
same SVG between different pages so more RAM is used
and more network bandwidth is consumed re-transferring the same
image, if the image appears on multiple pages.

(FWIW, I poked about trying to get python to wrap the
content of an SVG file's svg element and put the element's
content into a SVG group ("g" tag -- with a unique id attribute),
thereby allowing an SVG "image" tag to reference the re-written
SVG file's content.  This to allow embedded SVG in the HTML5
that uses "image" to reference a URI, thereby avoiding the 
above mentioned issues.   Per feature request #100.

I tried using the DOM parts of the stdlib to get the
xml declaration and the dtd declaration, and then
the xml.etree.ElementTree stdlib, all with a parser that
returns elements "as it goes" to avoid putting the entire
SVG file in RAM.  The idea being to re-write the xml declaration
and whatever DTD exists, then the "svg" element tag and
attributes, then construct a "enclosing group", and write
the closing "svg" tag.  But I never got the DOM part of the
parsing to work.

At this point, a dirt simple xml parser -- the complicated
part being understanding XML comments could be used to
find the point in the file where the first "svg" tag is,
might be the simplest approach.  Pluck the whole "head"
of the SVG file.  And parse backwards from the bottom to
find the closing "svg" tag.  (Even though I'd guess that
in the general case XML won't "parse backwards", how many
SVG files are going to have "unparseable" XML comments or other
"unparseable" trailing stuff that's going to prevent finding
the closing "svg" tag.)  Then write the whole middle of the
SVG to the new file, append the "bottom" part of the original
file, and you're done.

If the above kluge fails, somebody who knows the XML stdlibs
can always step in and do it right.  

Or..., just use xml.etree.ElementTree
with a regular parser, write your own XML declaration,
and be done with it.  Even loading entire SVG files into
RAM can't be that much of a big deal.  All of the above
is (premature?) optimization, undertaken because the response I got
to re-writing the SVG file so the content could be shared
via URI between pages was that the rewrite process would be "too
expensive".  (I forget the exact phrasing.  I'm unclear in 
what sense.  And it only has to be done once, unless the
timestamp on the source SVG changes.)

See also: defusedxml https://pypi.org/project/defusedxml/
)

Regards,

Karl <[email protected]>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein


_______________________________________________
Docutils-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Please use "Reply All" to reply to the list.