Replace B64 with a general purpose image inline extension

[facelessuser]

Will do everything that B64 does now, but will provide an syntax to force inlining, and optionally a mode to inline all images as B64 does now. Will handle PNG, GIF, JPEG, and additionally SVG.

Ref squidfunk/mkdocs-material#1475

[matoszz]

Stumbled across this as I've been searching for a good solution to have SVG's with functional links embedded into a mkdocs material setup...your docs note support for PNG, JPEG, and GIF but looking at the b64.py it seems like it could work by simply adding an additional file extension? Before I went down the rabbit hole I was curious if SVG's presented more nuance than I understand or why you may have not supported it initially

[facelessuser]

SVG isn't traditionally base 64 encoded.

[jmdye]

Can this also be made to work with reference style image links? I am have created a markdown file continaing reference-style image links that resolve to my inline icons, then I'm using snippets to inject it at the end of a markdown file. I wanted to use b64 so that I didn't have to distribute the icons themselves in the built site, but it appears to not work with reference style image links.

[facelessuser]

@jmdye, I'd need you to provide an example of what you mean. I'm not sure I am following.

[jmdye]

@jmdye, I'd need you to provide an example of what you mean. I'm not sure I am following.

sorry. I'm just dumb. Bad syntax on my part and I jumped the gun. it works fine with reference style images. SVG support will be sweet, looking forward to that.

Example fwiw:

my-doc.md

Lorem ipsum dolor sit amet, ![icon][icon-one] consectetur adipiscing elit.

--8<-- "icons.md"

icons.md

[icon-one]: icons/inline/icon1.png
[icon-two]: icons/inline/icon2.png
[icon-three]: icons/inline/icon3.png

Also, I know its called b64 for a reason, but data URIs for SVG would probably work just fine as well.

[facelessuser]

sorry. I'm just dumb. Bad syntax on my part and I jumped the gun. it works fine with reference style images.

Yeah, currently it doesn't care about the syntax, it is more looking for images in the HTML tree after that part of the parsing is done.

Also, I know it's called b64 for a reason, but data URIs for SVG would probably work just fine as well.

Whenever I get around to it, I'll probably rename it when I add in SVG support. While you can B64 encode SVG, it is not the best way to do it. I mean, we can certainly allow it though, but I may give options for SVG. I'll see when I get into it though. If I were to only do B64 encoding, then I'd leave the name alone.

[jmdye]

No rush on my end. Super thankful for this and the rest of the extensions. I use quite a few of them.

One other thing I noted that is just slightly irritating with B64 is that the console throws warnings indicating that referenced images in the doc are not present in the site build directory - durr, because they were B64 encoded. It'd be nice to have an option in the yml to suppress those warnings.

[facelessuser]

One other thing I noted that is just slightly irritating with B64 is that the console throws warnings indicating that referenced images in the doc are not present in the site build directory - durr, because they were B64 encoded. It'd be nice to have an option in the yml to suppress those warnings.

You are talking about MkDocs, which is a different thing entirely. We can't control anything there, we simply augment the Markdown parsing and output, not the document indexing. What you are seeing also has nothing to do with B64, but is related to Snippets. Your snippets files are included indirectly into other Markdown files, but never directly included themselves. That is why MkDocs gives you the warning, it doesn't know they've been included in a non-conventional way.

An easy solution is to rename the extension for snippet files. MkDocs scans for .md files, so I name mine with .txt so it ignores them. You could call them .snippet or anything really 🤷.