That would be desirable! In the limited spike I put together, images and other file attachments like images are successfully imported but not rendered properly. Not a fundamental limitation, I just didn’t invest time into it yet since I wanted to get your thoughts before diving in.
On a slight tangent: one of the tests I did to answer your question was to try my importer spike on a note with an audio file. It did not work. It appeared to import correctly, but then when I clicked the link, it opened iTunes but did not load or play the file.
I figured this was a bug in my spike, so I tried to import the same file with the existing ENEX importer. That didn’t work either, so I believe this may be a bug with the original importer. Interestingly, I then tried dragging-and-dropping the file from Evernote to Joplin, which did work. I looked for an existing GitHub issue on this and didn’t find one. Want me to open one?
Very good to know! As I convert from Evernote to Joplin, HTML clipping is one of the key features I know I’ll miss a lot and makes it hard to switch. Also, it sounds like that new note format concept would enable what I’m suggesting here.
I envision it’d be very similar to the existing ENEX importer, with a few key differences:
It’d preserve the raw XML rather than simplifying it to Markdown. A hacky implementation would be to effectively remove this line:
ReactNativeClient/lib/import-enex.js#L230. A robust implementation would of course have to handle the images properly too, and there are probably some other edge cases I’m not thinking of.
It’d add some sort of metadata to indicate to Joplin that this should be rendered as HTML rather than Markdown. We’d then add a conditional to check which type of rendering should occur in the apps. Two hacky approaches:
- Simply add a tag called something like Render as HTML so Joplin knows how to render it.
- Clipped notes all have the URL stored in the metadata, but that can be true of other notes too (though in my practice rarely is). We could theoretically just check for that, but it’s super fragile.
Sounds like you might have a better suggestion though. Eager to hear it!
It’d add an option like ENEX – Evernote Export File (raw) to the Import menu and rename the existing importer to something like ENEX – Evernote Export File (simplified). We can improve on those names, but that’s the key idea.
At first, I envisioned this would be a separate importer (as described in the preceding bullet point), which would simply treat all notes imported in a given batch the same. In other words, it wouldn’t distinguish between notes from the Evernote Web Clipper and other notes; it would simply import them all in the raw format.
My thinking here is that I’ve personally written my past evernotes assuming I’ll always have rich text capabilities, so even my todo lists have a fair bit of styling, which would be a bummer to lose upon import. Here’s a partial screenshot of a non-clipped note I have as an example of why it’s important to me to preserve styles in all of the notes I import from Evernote:
That approach where we don’t differentiate between clipped and normal notes may not be the desired behavior for everyone, though. We could do the differentiation at the importer step as you suggested (though that’s not ideal for my use case). Another way we could do this is to keep the single ENEX importer and then pop up an additional menu where folks choose between one of:
- Import all as simplified Markdown
- Import all as raw XML
- Import clipped notes as XML and all others as Markdown
I’d love your input on the above. Open to other ideas as well!