Obsidian wikilink images ![[image.jpg]]

[0atman]

Hi @kivikakk, thanks so much for your work here.

Image nodes are emitted for the normal ![]() image tags, but not for ![[]] wikilink image tags.

✅ Markdown links

![image:width:20%](fido.jpg)

❌ wikilinks

![[fido.jpg|image:width:20%]]

I wonder if it might be a simple change to support this? Thank you!

[kivikakk]

It might be! PRs welcome; @digitalmoksha has spearheaded the wikilink feature and may be able to guide more.

[0atman]

Thank you so much! I'd be delighted to test such a feature if helpful 😁

[digitalmoksha]

@0atman 🤔 as far as I can tell, ![[]] or ![] is not a valid wikilink image tag. I see [[File:...|thumb|Caption text]] syntax over at https://en.wikipedia.org/wiki/Help:Pictures, and [[Image:Wiki.png|50px|link=MediaWiki]] over at https://www.mediawiki.org/wiki/Manual:Linked_images.

[0atman]

(Apologies, I meant ![[]] not ![], I've fixed the issue description)

[0atman]

By 'wikilink', I don't mean Mediawiki, I mean the short form of links that github supports in github wiki. To be clear, this is not standard markdown, but a widely-used extension.

Many personal wiki tools (the biggest of which is Obsidian, I believe) support this image format, and Pandoc added support in 2023 (jgm/pandoc#8853 (comment))

I wonder if it could be an option in comrak?

[digitalmoksha]

@0atman I dug into this a little more. Based on https://docs.github.com/en/communities/documenting-your-project-with-wikis/editing-wiki-content#adding-images and my own testing, GitHub uses the standard wikilink syntax, [[link|title]] for images as well. If the link is an image, then it generates an image tag. They don't seem to support a ![[image]] syntax.

In Obsidian, the ![[image]] syntax is actually an "embed" syntax. Meaning it will try to embed whatever is being linked to, such as an image, or PDF, or audio file, etc. Interestingly, it only works with local files, I assume just within the Obsidian document tree.

You're right, pandoc does support the basic Obsidian syntax. So you can do pandoc -f markdown+wikilinks_title_after_pipe --wrap=none, and ![[music.ogg]] will generate

<figure>
<audio src="music.ogg" title="wikilink" controls=""><a href="music.ogg">music.ogg</a></audio>
<figcaption aria-hidden="true">music.ogg</figcaption>
</figure>

It does support generic links out to the internet. It doesn't, as far as I can tell, do anything with sizing, etc, which seems to be possible in Obsidian.

I think if we were to add an option to support this, it would make sense for it to mirror the embed ability of pandoc, rather than just be another image syntax.

[0atman]

Ah, of course, it IS used for embedding other files too (I hardly ever do so, I forgot).

Looks like pandoc has specialist rules per file type (such as ogg in your example), perhaps the first file type comrak supports could be an image tag, given I suspect that's the most common embedded file?

[kivikakk]

I'm a little weary of having Comrak itself know how to translate certain kinds of embeds — I imagine there'll be many different requirements even for the same kind of filetype (do we embed a .jpg as a <img>? an <img> inside a <figure>? inside a <div> with a given class? what about .jpeg? .jfif? .dcm?) and a wide range of filetypes (do we want to <embed> a .pdf? nested inside an <object>? use a JS library?). Not to mention we might want to change/parse/resolve the path given, and who knows what other options!

Instead I'd rather us support parsing these embeds, but require a callback to do so, which gets given the content and can do with it as it wishes. :) Then someone could develop an Obsidian-compatible callback if they like, and publish that, and someone else could do a pandoc-compatible one if they want, whatever.

[digitalmoksha]

Are you suggesting parsing them and adding a node to the AST (like we do with images) and then use the new HTML custom formatter to handle the rendering? Maybe an option listing the extension for each type so it can be configured what is detected?

[kivikakk]

I wasn't especially suggesting that; more, a render option which is an Option<SomeCallbackType>. I don't particularly want folks to have to use the macro just to use this feature, and we'd still have to have an option to enable parsing of them in the first place (and a fallback behaviour if a custom formatter wasn't used).

[digitalmoksha]

So using the current adapter paradigm.

[kivikakk]

Sure. See also image_url_rewriter, link_url_rewriter, broken_link_callback, etc.

[digitalmoksha]

ah yeah, I've never really looked into those