Feature Request: paste images

[gcoimbra]

Anyway to copy+paste images on notekit?

[blackhole89]

You mean to embed images (png, bmp, whatever) into the document? Not at the moment. It's planned; I just need to figure out a good way of storing them (should they be forced inline with long data: URI blobs, or should notekit create a separate subfolder to store embedded images in?).

You should be able to copy and paste your own drawings without issue.

[gcoimbra]

Yes, I meant that.
I think it would be better if they're inlined. This way if you can continue treating the .md files like a single entity. Containing all data.
Just like word, .doc documents.

[blackhole89]

Yeah, but if a big image is included, the resulting markdown file will become basically unusable in any plain text editor (like, you'd have a single line with hundreds of thousands of characters of alphanumeric garbage). #38 also suggests that some other markdown-processing tools don't play nice with them...

[gcoimbra]

@blackhole89 I think you're right. Most Markdown software support images with web or local links, I think we should change to it too. The way things are now, we can't copy/paste easily the images (we get the base64 encoded image). The only way I think to get the drawings out of notekit is by screen printing them, which is really hard.

I think we can't do it like word with .doc documents without sacrificing simplicity and interoperability with other markdown editors.

I've changed my mind. The only way I see it, is to create a separate subbfolder, like you said.

[blackhole89]

As of commit 4829902, we now render images given by ![alt text](local path) markdown. Consider this a (very simple) first step to support this.

[sp1ritCS]

As of commit 4829902, we now render images given by ![alt text](local path) markdown. Consider this a (very simple) first step to support this.

Cool I've been waiting for this. Obviously, this is a very early implementation and major things (like resizing) are missing, but its a first step. Something I've noticed is that it doesn't work with spaces in the file path, that's a bit annoying because gnome shell saves screenshot names with a few spaces.

[blackhole89]

resizing

How'd you even handle resizing? You'd have to store the size info in the document, but does Markdown have any standardised way of representing the size of an embedded image?

spaces

Does the Markdown spec allow those? (I took the parser from GtkSourceView's language definition, so whether it's legit is anyone's guess.) I could imagine that the image location is considered a "URL", so in particular has to be URL-encoded (representing spaces as + or %20)... (not that I'd be particularly bothered to deviate from the spec here and support spaces if it does; it seems like the parse would still be unambiguous)

By the way, the commit above might serve as a good piece of (loud scare quotes) "documentation" insofar as it represents a more or less minimal diff to add a new piece of syntax that is rendered to a widget when the cursor is not near it.

[sp1ritCS]

How'd you even handle resizing?
Well, that's a though one. I came up with these two:

1. Abusing the alt tag, as (as far as I can tell) NoteKit isn't doing anything with it.
2. Add some kind of block-comment infront of the image (but afaik notekit is just rendering comments currently)

[blackhole89]

Implemented in master now.