Open Johnnynator opened 6 months ago
Hi @Johnnynator - thanks for the bugreport. Let's check if I understand your request correctly:
rST
projects to be annotated as for embedded use; this means that each relevant image file is not included in the output build as a standalone named file, but is instead replicated (perhaps using data:
URIs, embedded XML, or other formatting as available based on the output format and image type) each time the image is referenced, from each output document that references it.loading
option flag that docutils uses for these annotations.Could I also ask what behaviour docutils
provides if-and-when writing such embedded-annotated images to a purely text-based output format?
And if possible: could you share more about the use-case(s) that you anticipate this would help with? In other words: not only the change in behaviour that you'd like, but the reasons why that could be beneficial in particular usage scenarios.
https://docutils.sourceforge.io/docs/ref/rst/directives.html#footnote-4
Yep, base64 data uri for for most things, svg directly embedded as is into the html.
Could I also ask what behaviour docutils provides if-and-when writing such embedded-annotated images to a purely text-based output format?
The loading attribute is only used for their html writer, other writers do ignore it.
My usecase is primarly taking use of how svg's get styled differently when they are embeddes in the html document compared getting linked with e.g. . Makes it easier to have a single svg that can handle both light and dark mode.
For normal images it would be beneficial to get rid of the ugly error message in the output html.
Could I also ask what behaviour docutils provides if-and-when writing such embedded-annotated images to a purely text-based output format?
The loading attribute is only used for their html writer, other writers do ignore it.
Ok, thank you.
My usecase is primarly taking use of how svg's get styled differently when they are embeddes in the html document compared getting linked with e.g. . Makes it easier to have a single svg that can handle both light and dark mode.
I'm not sure I understand this part - what's a situation where an embedded SVG is easier to style than an SVG included by using a (non-data) img
src
reference?
For normal images it would be beneficial to get rid of the ugly error message in the output html.
Could you post some build logs including the error message?
I'm not sure I understand this part - what's a situation where an embedded SVG is easier to style than an SVG included by using a (non-data) img src reference?
First of all, thanks for the screenshot: when you mentioned that the error message appeared in the output in your previous messages, I misinterpreted that as being the Sphinx build logs -- I didn't realize that the error appears within the built project content itself (output is a perfectly valid way to refer to that).
The SVG styling question seems to make some sense, but it is at-or-beyond the limits of my SVG/stylesheet experience; I'll try to learn some more about that.
The docutils
code to embed SVGs has a comment to indicate that it's provisional and subject to change, so it may be worth proceeding gradually with functionality here.
A small concern I had about adding support for embedded SVGs is that there is no implicit namespace for each SVG file embedded within an HTML document. This can cause collisions between the id
values of separate SVG images within a document. It seems that the docutils
folks are aware of this, though - it's mentioned in the relevant commit message.
heya yep agree that this should be in sphinx and is useful,
in fact I'm just dealing with a case now of moving from <img src
to embedded, to deal with theme compatibility: https://github.com/useblocks/sphinx-needs/pull/1181
Describe the bug
Sphinx refers to docutils for all
reST
behaviour (except where it extends it), so I would expect that:loading: embed
would work as documented by docutils (v0.21+).sphinx breaks
:loading: embed
in two scenarios:_images
path, so docutils can't read the image file (and not embed it) and prints an error in the outputHow to Reproduce
Environment Information
Sphinx extensions
No response
Additional context
No response