Jimmy: A Joplin Import Tool

Hi, this converter doesn't handle colors as I'm trying to avoid any inline HTML. Unfortunately, I don't know of any tool that retains the colors. (The official Joplin importer seems to remove colors, too.)

Edit: You might try GitHub - akosbalasko/yarle: Yarle - The ultimate converter of Evernote notes to Markdown. There is an option to convert colors to Markdown highlight (convertColorsToMDHighlight). I never tried it, though.

Thanks for the quick reply and suggestion!

1 Like

Hi,
at first: Many thanks for all your effort to develop Jimmy! Your work is highly appreciated.

I'm a Linux user and used Zim as a notebook for several years now. Since I would like to have an appropriate Android app to work with my notes, I try to switch to Joplin and convert my notes to the Markdown format.
The exporter included in Zim seems export links correctly but strangely checkboxes of lists are converted to small special characters which can not be edited afterwards. For the pandoc converter it is the same, but maybe I just did not find the right settings for this powerful tool.
Thats why I tried to use Jimmy to convert to Markdown.
There the checkboxes are converted fine but links do not seem to be converted correctly.

I currently can describe some issues with link conversion by Jimmy I came across:

  1. A link in Zim in the format [[http://foo|bar]] (links to "http://foo" but display "bar", see https://zim-wiki.org/manual/Help/Wiki_Syntax.html (same for file://...)) is not converted at all which results in a link "http://foo%7Cbar" in Joplin.
    In the Zim export the link is correctly [bar](http://foo).

  2. Included images are actually a link in the format {{./image.png}}. The conversion of such a link does work. But if the image is resized in Zim the link is like {{./image.png?width=600}}. This is not detected by Jimmy and the resulting link is [image.png?width=600](image.png_width%3D600) which can not be converted since the file can not be found.
    The Zim own export is ![](./image.png){ width=600px } but this link is not correctly imported in Joplin, ones without {...} are. So maybe it is the best option to just drop this information.

  3. Links to attachments in Zim are in the format [[./Icons-list]] or [[./shell-script.sh]] (. = current folder) and are converted by Jimmy to the format [./Icons-list](Icons-list) in both cases. But for files without file extension the link is not correctly imported by Joplin, but links to files with file extension do work. But if I change the link to the format [./Icons-list](./Icons-list) before import to Joplin, the link is also correctly imported for files without file extension.

  4. Zim allows links to files relative to the home folder of the user in the format [~/.local/share/applications/mimeapps.list]. Jimmy converts this to [~/.local/share/applications/mimeapps.list](mimeapps.list) which can not be found since the link to the file is not correct. The own export of Zim gives a link of [~/.local/share/applications/mimeapps.list](file:///home/<USERNAME>/.local/share/applications/mimeapps.list) which is correctly imported and does work.

I had a quick look in to the Jimmy source code, but I do not understand the source code enough to make the adjustments myself.
So I would be very glad to get some hints from you.

Many thanks for your support.

Thanks for the detailed feedback!

I had the same experience when converting from Zim. That's why there is a custom, hacky conversion script from Zim to Markdown. (For many other formats, Pandoc is used and works fine.)

I think I can do some tests based the examples you provided and check how difficult it would be to fix them.

Update:

  1. Titles in links should be fixed.
  2. Queries in images are stripped. So this should work now, too.
  3. That's an interesting finding. On Jimmy side, this happens unintentionally, because normalizing ./ is an internal "feature" of pathlib that can't be changed easily. So I implemented a workaround to add it manually. But there seems to be another issue in Joplin: When importing a file ./bbb, it gets converted to <internal_id>.bbb. So at the end, I will leave this open for now and create a bug report.
  4. Resolving the home path and linking files is now supported.

@Fermi: You can try release v0.0.54 and feel free to report issues.

Many thanks for the fast update, which I just became aware of.
I only got an email notification about your reply but not when you edited it. My fault.

For personal reasons please give me some days for testing, but I will definitely give you feedback.

1 Like

Many thanks for the improvements and the filed bug report at Joplin. I did not realize that this is an issue with Joplin.
Except from the attachments without file extensions, the translation to Markdown and import to Joplin is much better now.

Since I ran the conversion with --stdout-log-level DEBUG I'm checking now the output for further issues (or not correctly used formatting syntax in my notes).

Three things I already found:

  1. If I understand it correctly, Jimmy tries to convert any txt files in the Zim folder. Since I also often have non-Zim text files as an attachment (e.g. a log from a software installation) the conversion fails for these files.
DEBUG    Converting note "some non-Zim text attachment"                                                 
WARNING  Failed to convert note. Enable the extended log by "--stdout-log-level DEBUG".           
DEBUG    not enough values to unpack (expected 2, got 1)                                          
         Traceback (most recent call last):                                                       
         File "common.py", line 43, in wrapper                                                  
         File "formats/zim.py", line 57, in convert_note                                        
         ValueError: not enough values to unpack (expected 2, got 1)

Does Jimmy check for the first line Content-Type: text/x-zim-wiki in Zim files before trying to convert text files?

  1. A ftp link in the form [[ftp://tug.ctan.org/pub/tex-archive/macros/latex/contrib/custom-bib/makebst.pdf|documentation]] leads to the debug output
WARNING  Resource "ftp:/tug.ctan.org/pub/tex-archive/macros/latex/contrib/custom-bib/makebst.pdf" 
         does not exist.

and [documentation](makebst.pdf) in the Markdown output, which is obviously not correct.

  1. A link to an attachment which is placed in the same directory as the Zim file (e.g. Test.txt (and not in the attachment folder Test) is linked in Zim as [[../attachment]] and is correctly working in Zim. But this leads to a warning
WARNING  Resource "/path/to/zim/notes/parentdir/Test/../attachment" does not exist.

since the Test folder does not exist.

Many thanks for your work, but I'm slowly thinking whether the conversion will fully work or if I should stick to Zim. :thinking:

The three issues should be fixed now. The first one looks scary, but actually works as intended. I added a proper log message.

Yeah, it takes some time to cover all the use cases. I can understand if its too time consuming for you. On the other side, if you want to continue, feel free to report here. I plan to continue improving the conversion from Zim to Markdown.

The latest release 0.1.0 is available here.

Hi,
I am in the process to convert from Nimbus Note to Joplin.

So far I copy&paste notes from Nimbus and create a new Note in Joplin (Evernote import was working fine) because I was not able to export more than 1 note from Nimbus (I still have the paid Nimbus account).

I still have approx 1000 old notes left (is my "project" for this year) and if there would a easier way to move my notes from Nimbus to Joplin, would be realy great ...

My question would be:

  • is there a way to export from Nimbus more than 1 note???

The Jimmy instruction say something

If you have a complete workspace backup (premium feature), feel free to share. It may lead to tag and note link support

But I do not find anything that I could make a workspace backup.

Did anybody know whether this is still possible?

Best regards,

Wow, it looks like after removing the JSON export they also removed the bulk export at all. I will mention it in the documentation. Unfortunately there is nothing I can do about it. You might ask the support of NimbusNote/FuseBase if it will be possible in future to bulk export or why they removed it.

I found this tool in a quick search, but it looks non-trivial (the developer reverse-engineered the internal API). Maybe someone else did migrate recently and can share some hints.

Hi I found the Nimbus Note Exporter too, but was not able yet to have a deeper look at it - on the 1st galnce it looks like that is running on linux only.