It would be nice if rst2html had an option to embed images as base64 data uris in html files. Then you could make a single file html document that could be e.g. easily mailed as an attachment.
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.)
Embed SVG images directly, not as data URI .
+1 Allows interactive SVG images (cf. [feature-requests:#100]).
+1 Smaller image size.
an option for the "image" directive overriding the configuration setting for individual images.
+1 allows fine grained control (exclude large images, include just one image, ...).
Similar to the configuration setting, the directive option could also care for the
"lazy loading" feature (cf. [feature-requests:#78]).
+1 fine grained control of lazy/eager image loading (eager loading of the images "above the fold", lazy lading of large images only, ...)
-1 While embedding/refering may become configurable for the XML and ODT writers some day, HTML5 is the only output format supporting "lazy loading". (OTOH, HTML5 is by far the most used output format...)
Implemented in r8581. Thank you for the suggestion.
Fixed in Docutils 0.17.
Thank you for the suggestion.
On Sun, 26 Nov 2023 16:04:10 -0000
"Günter Milde" via Docutils-develop
docutils-develop@lists.sourceforge.net wrote:
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 kop@karlpinc.com
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Related
Feature Requests:
#100I wrote: "Embed SVG images directly, not as data URI ."
Encoding an SVG with Base64 usually makes it larger.
There is room for improvement:
+1 Allows interactive SVG images (cf. [feature-requests:#100]).
+1 Smaller image size.
+1 allows fine grained control (exclude large images, include just one image, ...).
Similar to the configuration setting, the directive option could also care for the
"lazy loading" feature (cf. [feature-requests:#78]).
+1 fine grained control of lazy/eager image loading (eager loading of the images "above the fold", lazy lading of large images only, ...)
-1 While embedding/refering may become configurable for the XML and ODT writers some day, HTML5 is the only output format supporting "lazy loading". (OTOH, HTML5 is by far the most used output format...)
Related
Feature Requests:
#100Feature Requests:
#78The ODT writer may interpret "lazy loading" as "link in the flat XML format, embed in binary (zipped) ODT".
The "image" directive now has a :loading: option. [r9496]
Related
Commit: [r9496]
A patch for direct SVG embedding on top of [r9503].
Related
Commit: [r9503]
Direct SVG embedding is implemented in [r9597].