Files imported from .enex don’t contain any styling.
I’ve just ignored it in plenty notes, fixed it manually in others, but I still have a few notebooks where neither of those options is feasible.
How it looks in EN:
And Joplin:
I guess I could try getting raw HTML from Evernote and hacking on that, but I really don’t want to, if there’s any other way.
(Update: I don’t care about stuff like the silly gray text; but the bold/italics and the paragraphs are important.)
Could you send the ENEX data?
Looks like the styling has been set in the attributes for this note, which unfortunately is not currently supported.
Verdammt. Okay, thanks for looking at it.
Hi Laurent,
I have this issue with almost all of my ENEX files. Is there any plans on your roadmap to implement this in the near future? I really would like to help, the problem only is that I am a quite decent Python coder but just starting out with JavaScript and React Native, so more or less bloody beginner 
Anyway, maybe you could point me in the right direction where the import code is happening?
Well now I am not sure if this is exactely my issue, but I already described it here: https://github.com/laurent22/joplin/issues/767
Hi @laurent,
I found it myself. Here span tags are ignored
I will try to quick and dirty fix it for my needs, so it handles the most important formattings evenote produces with span tags.
If you are on this already and it’s finished soon, please tell me!
Probably the most challenging thing for me will be to get the electron client to build because I don’t have any experience wit electron/react app builds. I have a little experience with building react native apps already and I assume the process for react will be very similar.
Is there a step by step guide or other resource on how to build the joplin electron client or do I have to figure this out myself?
Thanks in advance!
Jojo
Here you go
You can also important with the CLI, no need to build the electron app
Hello, thank you for a wonderful open source project! Discovering Joplin recently was the highlight of my month.
Would you be open to a PR for an additional Evernote-with-styles import that doesn’t strip the ENEX down to the bare markdown? Use case: I have years of notes with styles that are necessary to understand the page (especially those clipped with Evernote Web Clipper!) and the current ENEX importer strips all those styles away. From the preceding conversation, it sounds like there are others with this use case, too.
I’ve implemented a small spike it in my local version of Joplin, and it works pretty well. Here’s how an imported ENEX looks on Joplin Mac desktop [left] and iOS app [right] with my with-styles importer spike:
I’m envisioning it’d go here as another import option, or possibly as an option you’d check upon selecting the ENEX – Evernote Export File import that already exists. Eager to hear what you think!
P.S. This is my first time as a non-lurker in Joplin, so please do let me know if you have any feedback for this comment/request. I did my best to following the contribution guide, but it’s possible I missed a previous issue or conversation on this topic while searching through the history.
Hi and welcome on the forums! How would this feature works exactly? From the look of it, it seems it’s the raw ENEX document that’s been imported. Are the images and other file attachments imported too?
For info, I’m also experimenting with importing notes as HTML with the Web Clipper. For this I’ll introduce the concept of a note format, which can be either Markdown or HTML. This is because quite often clipped notes are never modified, so we may as well keep it as HTML to preserve styling.
I guess if we were to support the feature you mentioned, these note formats should be set to “html” too.
Also I believe it’s possible to know if an Evernote note comes from the clipper originally. So we could have regular notes converted to Markdown, like now, and clipper notes imported as HTML. Just some ideas at this point anyway as this note format thing is not implemented yet. If you have some ideas feel free to share them.
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:
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:
I'd love your input on the above. Open to other ideas as well!
This was actually recently fixed there: Importing enex breaks audio links · Issue #1723 · laurent22/joplin · GitHub
That sounds good. Evernote's HTML format is good enough as it is and includes all the styling in the tags. The key part is indeed how to import resources and how to make sure they are linked properly from the HTML (for example image tags will have to be replaced to point to Joplin's created resource). Ideally the existing code from the Enex import should be re-used but it's a bit of a mess so it might have to be refactored a bit first.
As a first step I'd prefer your first solution of having two menu items, though I'd named them differently. Maybe just as ENEX – Evernote Export File (as HTML) and ENEX – Evernote Export File (as Markdown) (or maybe "to HTML" / "to Markdown". I think simplified/raw might be a bit confusing as it's not clear what would be happening.
This would be amazing, especially if we could have the option to import from Evernote directly as HTML or converted to markdown. I love MD and am happy to switch for my new notes, but currently there is so much contextual information lost in the conversion of my notes from html -> MD that I am hesitant to completely switch from Evernote.
Thanks for all your hard work - I look forward to each new verions!
The HTML mode will indeed have the advantage of keeping clipped or Evernote notes in a format very close to the original. However the drawback is that these notes will be difficult to edit. It will essentially be a big blob of HTML and style and, unlike Markdown, will not make much sense when not rendered.
As I mentioned it's a little experimental at this point and will be marked as "beta" on the clipper. The main purpose is indeed to be able to clip a web page and keep it exactly as-is. It's not really meant to be edited (although it can be done).
For my use case, that would be fine - most of the previous “historic” notes from the last decade of using Evernote are never going to be edited, and I would be happy with them being read-only…
Do you also plan to preserve the option of having it simplified to markdown?
While I admit i'd sometimes like the formatting preserved, most often I just want the simplified version. I mostly want clean content I can highlight or shorten and I definitely don't want different fonts, font sizes, alignments or other such nonsense.
Yes definitely, importing Enex notes as HTML or clipping as HTML will be a separate option. I also think in many cases converting to a simplified Markdown version is better.
The option to convert any html note to a simplified MD note within the app would be great. Then I could imagine importing all of my notes from EN - those “old” notes I will never edit can stay as html and preserve formatting (the conversion to MD is never perfect, and sometimes results in some odd things). Then I could click to convert/unlock notes that I need to edit…
That makes sense and would give more flexibility to manage these HTML notes. It would probably create a new copy of the note in MD format, that way if the conversion is not acceptable, the user can still go back to the original HTML version.
Perfect! Now I'm getting excited about finally being able to jump ship properly 
