Can Images in a Local Markdown File Be Converted into Internal Items During Import?

A screencast of what you’re describing could be useful.

Hmm. I’ll think about it.

A document format close to Markdown which allows to embed images is TextBundle. – Very unfortunately this format hasn’t gotten the traction it truly deserves… :unamused:

Thanks for confirming my point. Enjoy. :grinning:

Actually, that is technically inaccurate. The assets are linked, not embedded. The document and its assets are just stored in a package file, similar to how RTFD works.


Well, the resulting *.textpack file (here an example from the site) is then one file where the original Markdown file and the images are embedded/contained.

I think TexBundle/TexPack this would be a fantastic format to write text with images, but as mentioned before, it is not widely used. (Note to myself: In technology often not the best solution succeeds, but something which becomes for other arbitrary reasons popular…")

In fact, I think TextBundle is too good to be popular. It makes migrating notes between different software very easy, which is not an advantage for commercial purpose.

1 Like

That’s not very convincing an argument, imo. PDF, for example, is certainly a “good format” (at least it contains all the images), and it’s widely available. OTOH, Word is perhaps not such a “good format”, but is still widely available. And what about (La)TeX? Is it “too good to be popular” or is it simply very good, but also not very popular because it has a steep learning curve?

Interestingly, most of the apps supporting TextBundle are macOS/iOS only. There’s only very little support for Windows and Linux. Perhaps because developers stopped reading the specification after the paragraph stating that TextBundle uses Apple’s Package as its container format – the next paragraph explains that ZIP is also possible.

IMO, TextBundle offers little to no advantages over a DT group with a subgroup assets storing all the images etc. You can save that group as a ZIP archive and have basically a TextBundle. Minus the JSON file, but that has nothing to do with the assets. But I guess a simple script could provide for that, too. So, what’s the point in supporting a format explicitly that is already supported implicitly?


Interesting way to look at it. (I have all my images in a database-wide assets folder, but maybe I should rethink that…)

Still having a format which goes beyond DEVONthink would be beneficial: Imagine everyone, not only DEVONthink people would use simply editable TextPack files instead of docx files…

And one often touted by @BLUEFROG before.

You might want to take a look at Script: Convert Markdown to TextBundle with images included. The script builds a TextBundle from an MD file, grabbing all images referenced in the MD. Instead of doing this, it could be modified to create a group and a subgroup assets, moving the MD file to the former and the images to the latter (or copying if moving is too intrusive). The changes should be minimal.


Cool script. Thanks. Will have a look at it.

1 Like

I think times have changed. The formats you mentioned, such as PDF, Word, and LaTeX, are all adapted to the computer era. However, can their results be viewed effectively on phones and pads? I think not, especially in the case of LaTeX. Lately, I have been using chatgpt to translate papers from arXiv, and it can translate LaTeX into Chinese and compile it into a beautiful PDF. But when I try to compile it into a format suitable for an 8.3-inch device, I find that it’s not very simple.

You mentioned the lack of support for TB on Windows and Linux, and that is totally correct. However, those platforms also don’t have excellent software like DevonThink, do they? As another example, I believe the concept behind Hookmark is a great initiative, but currently, there are no signs of Windows and Linux platforms keeping up with it. I think this is a problem with their ecosystem not being strong enough.

Overall, my personal needs are for a simple editor that doesn’t require worrying about formats, facilitates easy migration, and works seamlessly across different platforms and screen sizes. I believe these needs are quite common. However, the current handling of md files has issues. For example, if you delete MD files in bulk, can you simultaneously clean up the corresponding images? If MD files imported in different ways have inconsistent image storage locations, can you organize them effectively? And suppose I need to export MD files from DevonThink to another system, such as Obsidian or DokuWiki. In that case, the current system seems rather complex. All of this makes me feel uneasy.


Word files and PDF’s, as does Apple Pages (for text and graphics) work extremely well on my Apple iPhone and iPad, mainly this works well because there are pretty good tools and standards to do so. PDF defined by an ANSI standard.

LaTeX is not a document standard, but a tool for creating documents, AFAIK in my experience. If a LaTeX does not doesn’t compile to your expectations, isn’t that another matter?

Don’t really want to debate this, but for other readers who may be uncertain about rendering PDF and Word on iOS devices, wanted just to make this comment.

1 Like

I’m a bit confused. For example, how is a font that is suitable for an A4-size PDF document applicable to iPhone?

Don’t know the algorithms the viewer software uses. Just works. Magic. Try it.

The main difference between print (PDF) and screen is not size but the concept of “fixed canvas”: a PDF (as well as Word etc) is made up of pages of a fixed size, a screen can show potentially infinitely long documents in arbitrary zoom factors.
But since PDF is a vector format, you can scale it without losing quality (within bounds when downscaling). That works also for the fonts, of course.

I don’t see any essential differences between the ‘computer era’ and the present. What I do see is an evolution of screen sizes and to a lesser extent input methods and capabilities. TeX on an iPhone is an interesting story. Shortly after the iPhone was released I saw an iPhone running LaTeX. This was written by Jonathan Kew, who also developed XeTeX – a fully Unicode-embracing variation of TeX. It was very fast: if you rotated the phone from vertical to horizontal, the entire file was reparsed in a second or two. Go back to vertical and it is processed again. This never was commercialized, probably for lack of demand. Potential customers probably didn’t see a need to load a TeX file on the phone and then process it, when it was no more work to process the file on the desktop and load the resultant PDF.

BTW, you can change the layout of a LaTeX file by adding one line that loads the geometry package. The dimensions of the PDF output are parameters of the call to load the package. See []

All the problems you mention in your last paragraph, except for one, disappear if you change your mindset to thinking of your document as directory filled with stuff rather than as a text file with pointers (which are invisible until you open the text file) pointing to scattered files.

If you keep MD files and their graphics in a single directory or directory tree, they are easy to move, there’s no way for the graphics to get separated from the text, deleting a document (i.e, the directory holding the parts) always deletes the referenced graphics and only those graphics. Moving to another system such as Obsidian is no problem. The only problem that this method doesn’t address is the case where one graphic file is referenced in two or more documents – shared references. Depending on the size of the shared graphics, you might be better off duplicating the graphics so that each file is referenced by only one text file. Otherwise, you have the same problems you mentioned. (There is a reason that PDF files contains both Objects and XObjects. They are included or referenced in that order.)

There is a slight cognitive load in recognizing that your document is really several file. Perhaps this is the reason the Microsoft Word has Docfiles, TextBundles were invented, Apple invented bundles, Scientific Word used the extension .sci instead of .zip, and why PDF files are hiding the image files unchanged within the structure, after possible compression.

If you have, say, an Obsidian vault, and you want to convert to putting graphics files in a directory shared with their MD partners, and you have kept all the graphics in a single directory, you will have to do some work sorting them out. Finding the backlinks will help. In any case, this is the same amount of work as deciding which graphic files need to be deleted when you delete an MD file, except that you need to do it only once.

I think it is a mistake for each product to have its own solution to problem of aggregating the parts of a document. If they all used zip files, there would be one less roadblock for moving work from one program to another.


A PDF file that includes a non-vector graphic can’t convert that graphic to a vector format. But it is still the best that can be done with what it has.


True, of course. I was writing in the context of “a font suitable for A4 PDF” vs. iPhone. Hopefully, bitmap fonts are out of fashion now :wink: