The `b64` Extension Doesn't Work in a Simple Use Case

[RoyiAvital]

I have this simple user case for b64:

---
    # Meta Data
    Title: Admonitions Test

    # Settings
    settings:
        enable_uml: true
        markdown_extensions:
          - markdown.extensions.footnotes
          - markdown.extensions.tables
          - markdown.extensions.admonition
          - markdown.extensions.toc:
                toc_depth: 2-4
          - pymdownx.b64
        allow_css_overrides: true
---

## Testing B64

![](./GitHub.png)

Yet the generated HTML doesn't embed the image.

Here is the MWE:

B64Test.zip

[facelessuser]

Works fine. Don't indent your YAML so much:

---
# Meta Data
Title: B64 Test

# Settings
settings:
    enable_uml: true
    markdown_extensions:
      - markdown.extensions.footnotes
      - markdown.extensions.tables
      - markdown.extensions.admonition
      - markdown.extensions.toc:
            toc_depth: 2-4
      - pymdownx.b64
    allow_css_overrides: true
---

## Testing B64

![](./GitHub.png)

@gir-bot remove S: triage

[RoyiAvital]

Hi,

This is my current YAML:

---
    # Meta Data
    Title: Wind Speed Estimation Algorithm - Prototype - Report

    # Settings
    settings:
        enable_uml: true
        markdown_extensions:
          - markdown.extensions.footnotes
          - markdown.extensions.fenced_code
          - markdown.extensions.tables
          - markdown.extensions.admonition
          - markdown.extensions.toc:
                title: Table of Contents
                toc_depth: 2-3
          - pymdownx.b64
          - pymdownx.arithmatex:
                generic: true
                smart_dollar: false
        allow_css_overrides: true
---

Everything else works but b64. I think it is better to make things coherent, or everything should not work or b64 should also work.

By the way, I copied the YAML and indention from your documentation:

By the way, what's the difference between using b64 and "image_path_conversion": "base64",? It seems they can do the same (At first thought b64 supports non local files [URL] but documentation requires local files).

Thank you for assisting me with this. This is truly a great package (I'd be happy if you had a PayPal Me link for support).

[facelessuser]

By the way, I copied the YAML and indention from your documentation:

Then it is wrong there too 🙂. I will fix the noted example there.

If de-indenting the content still causes trouble, then I would be happy to dig a bit deeper, but the example you gave me, which I downloaded and tested, didn't work until I fixed the formatting.

By the way, what's the difference between using b64 and "image_path_conversion": "base64",? It seems they can do the same (At first thought b64 supports non local files [URL] but documentation requires local files).

So, b64 is an extension available for Python Markdown (the markdown parser), but the ability to create a single HTML with images embedded is useful for all parses. The other parsers github, gitlab, etc. don't have this feature, so "image_path_conversion": "base64", is a generic way that works in all the parsers. The way the b64 extension works in Python Markdown is that it post processes the raw HTML, so we can actually just reuse it and post processes the raw HTML for other parsers, and that is exactly what we do: https://github.com/facelessuser/MarkdownPreview/blob/master/markdown_preview.py#L445.

So, in short, there is nothing different except that running b64 directly as an extension in Python Markdown is how it was intended to be used, but "image_path_conversion": "base64", exposes it for other parsers. TBH, you should never have to explicitly use the b64 extension if you are using "image_path_conversion": "base64",. Let me know if I am mistaken, it's been a while since I've confirmed 🙃.

Thank you for assisting me with this. This is truly a great package (I'd be happy if you had a PayPal Me link for support).

Yes, I do. I haven't yet enabled that info over on this repository, but I do have it available on others. I'll link you over to BracketHighlighter's docs, one of my other Sublime Text projects, that provides both links to sponsorship and direct, one-time contributions via PayPal: https://facelessuser.github.io/BracketHighlighter/about/contributing/#become-a-sponsor. I make one-time payments and sponsorship available so anyone can donate in a way they are comfortable with. Neither is required, but I'm always appreciative to anyone who feels the desire to do so 🙂.

[RoyiAvital]

I see. So I think I will stick with "image_path_conversion": "base64",. I'd love to see it supports URL links as well and not only local images.

I have sent you a contribution to show appreciation of your work and not less importantly the way you treat your users.

Thank You.

[facelessuser]

The main reason I haven't yet added support for URLs is that this extension was more born of the need to package local files in a single HTML to send along in an email etc. External URLs are always available as external URLs, but local images are not accessible to a third party.

It could certainly be added, but then I have to add timeouts, retries, etc. I just never had the need for downloading and embedding external image URLs. Something to think about.

I have sent you a contribution to show appreciation of your work and not less importantly the way you treat your users

That is very kind. Thank you! 😄

[RoyiAvital]

Hi, Any chance to re ask for supporting URL's :-)?

It would be very useful in many cases.

Thank You.

[facelessuser]

Well, you can certainly ask 🙂.

This change would need to get added in the upstream library, and MarkdownPreview is still waiting for Sublime Text's Package Control to add support for Python 3.8. I've been holding off on upgrading Markdown dependencies as I'd have to backport everything yet again to Python 3.3 and continue backporting changes back to Python 3.3 on future releases. Supposedly, Package Control is working towards Python 3.8, but it is still yet to be released.

Package Control really needs to update to 3.8 Python before I make any big changes related to dependency libs. Most Python Packages do not maintain compatibility with such an old version of Pythoon 3.3, and it is always a pain backporting everything. Assuming that happens sometime soon, we could potentially revisit the possibility. I currently maintain the Markdown dependency and the pymdown-extensions dependency (which includes the B64 extension), both of which would need to get updated.

I view adding remote URL support as a potential nicety but far from a necessity. That doesn't discount the usefulness that some may find in it, but it is above and beyond the original vision for B64. It also adds a lot of overhead for the live previews as now we would be relying on these remote operations to finish on every save for things like live previews. I will not currently rule it out, but before we even seriously consider it, I would like to move the libs over to Python 3.8. My interest in continuing to backport libs has become exhausting.