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

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: