Possible to encode images in a way that other markdown previewers' can decode them?

[rjbergerud]

I currently use atom + markdown-preview-plus for working in markdown, and it would be nice to switch back and forth between using that and notekit for editing markdown. As it stands, other markdown previewers can't seem to decode the base64 images.

I've tried appending data:image/*;base64, to the beginning of the data, but doesn't change the output.

Is this package using a different way to encode images base64?

[blackhole89]

Do you mean the drawings? Those are in a proprietary format more or less out of necessity (if we stored them as bitmaps, it would not be possible to erase whole strokes, or to implement other vector-graphics features that are planned, such as resizing parts of drawings; SVGs on the other hand would be too big and are inefficient for storing variable-thickness strokes). You can trigger an irreversible conversion to image/png by copypasting a block or full file from the editor, and I'm planning to make something like "export this note" an explicit option invokable by menu.

[rjbergerud]

I see what you mean. I was just thinking what if you could have both, and give the proprietary images their own markup that could be picked up from within a comment like <!-- !notekit()[] -->, and beside them have bitmaps updated on save (but have something identifying about them so notekit doesn't render image twice).

I guess the downside is base64 make editing the file with other markdown editors no fun, and so it would be a lot of extra work for nothing :man_shrugging: However, keeping two versions of a markdown file (notekit and publishable one) will also be no fun.

[blackhole89]

Another problem is that I've received reports (#38) that some/many Markdown viewers don't even play nice with data: URIs. To cover for those, you'd therefore really need to maintain a dedicated subfolder with rendered images to link to, and keeping that in sync with the documents would be annoying (you could probably only really identify each image by a hash of the abstract representation, and then you'd need to constantly check that there are no orphaned files piling up in that folder whenever any drawings are changed or deleted...).

[blackhole89]

If there is no requirement to have edits to the "published" version reflected back in the original file, it might be reasonable to implement a "publishable carbon copy" of sorts: user can designate a directory \neq base_path that the notes tree is mirrored in, but with all drawings rendered. Whenever a note is saved, its rendered shadow copy is also updated.

(Another thing that is causing me some concern: rendering all images to PNG is actually a somewhat costly operation. I wouldn't want switching notes to become an operation associated with (more) nontrivial lag; even the way complex drawings take time to render on load annoys me, and I'm sort of hoping to offload it into a worker thread eventually.)

[rjbergerud]

I think "publishable carbon copy" feature would be useful. Maybe it's a feature I could trying helping out with when I have time over the holidays (haven't worked with gtk/C++ much before, so there would be a learning curve).