Display remote images inline

[alensiljak]

More specific than #22, this request is only for displaying the remote images inline. Local images and attachments are cumbersome due to different ways of accessing the files by different platforms and applications. Hence, some images may be stored online and referenced from within a note. The images don't change as often as text, so this is one way of solving a big part of the problem. The option should have a toggle switch in the preferences. The displayed images should scale so that they fit the screen. Large images may need to be opened by tapping on them.

By remote, I mean the HTTP(S) URLs. The supported extensions should be recognised automatically. Png, jpg, svg, gif, webp would be my preference.

[amake]

This is actually the thing I was planning to do next.

The main hurdle as I see it is that this feature requires local caching, so that means building or finding a cache managing component and also adding controls to clear the cache

[amake]

Actually if this works well then it could be 90% of the solution: https://pub.dev/packages/cached_network_image

The other things to think about:

• iOS doesn't have a way to manually clear caches, so I might want to add an in-app control
• If allowing tapping an image to expand it, the UI details of that need to be nailed down (maybe a new page containing just InteractiveViewer)

[alensiljak]

There is currently a WIP pull request in GitJournal for practically the same feature. The demo in the screenshot looks pretty good. I think it might be using the same component.

[amake]

I now realize that images in org-mode are expressed merely as links to files that happen to be images, and only local files are supported out of the box.

So displaying remote images is actually making Orgro's display less faithful to the real thing. Having the feature off by default makes sense then.

Then to make it discoverable I am thinking about having a MaterialBanner show when appropriate:

This document contains remote images. Would you like to load them?

[Never] [Always] [Just once]

The displayed images should scale so that they fit the screen.

I assume this means scale down. Scaling small images up to the full width of the document would prevent actual inline use.

[alensiljak]

So displaying remote images is actually making Orgro's display less faithful to the real thing. Having the feature off by default makes sense then.

True. On one hand, that's because we're trying to solve another problem here. To be true to OrgMode, the content would have to be file-based. On another hand, it's a pretty cool feature and I hope OrgMode introduces the same in the future. That's the whole point of the Web. Especially with the upcoming Web 3.0, but that's another topic.

The displayed images should scale so that they fit the screen.

I assume this means scale down. Scaling small images up to the full width of the document would prevent actual inline use.

Correct. However, I'm not sure how large the small images will actually be. And I also do not have a valid reference to point to, so this is something we'll have to mold with trial and error approach, I guess.

We could list some use cases that should be satisfied and brainstorm on them. I.e.

• Previewing photos. This is probably not the main purpose of storing images in a text file.
• References. For this, the standard link to a photo, which opens in a separate view or app, is perfectly valid.
• Inline information. This is the case I have right now. Scan of a portion of a book page or the list of rules for a foreign language. I don't want to write everything down and just adding images works well. OrgMode's collapsing model makes it perfect to keep these.

Anything else?

For everything else there's Mastercard. No, I mean Emoji.

[alensiljak]

We are not that far off: https://orgmode.org/manual/External-Links.html

External images are inlined in the exported HTML. Since Orgro is a Viewer, it makes sense to display the images inline by default. At the very least in the reader mode. Although, I'm not quite sure what exactly that mode represents.

[amake]

Since Orgro is a Viewer, it makes sense to display the images inline by default.

I agree, for local images (which I do want to support eventually).

For remote images I think it's a bit different because

• Showing them may take time
• Showing them may cost money
• Users probably don't expect remote images to be shown because they basically can't be shown in real org-mode

So I think asking for confirmation the first time is a good idea even in reader mode.

At the very least in the reader mode. Although, I'm not quite sure what exactly that mode represents.

That's a fair criticism: the mode is not clearly communicated, and right now it's a jumble of things.

Reader mode started as the spiritual equivalent of a toggle for org-hide-emphasis-markers. But then I added some other subtle things that I thought might make "reading" more comfortable:

• Meta lines (starting with #+) are faded out to be less prominent; I stopped short of removing them entirely for mostly technical reasons
• Block header lines no longer wrap
• I forget what else

I would consider in the future reversing the feature: instead of Reader Mode, have the Reader Mode features on by default, and instead introduce Verbatim Mode where all markup is shown (including e.g. LaTeX markup instead of rendering).

[alensiljak]

I agree, for local images (which I do want to support eventually).

Yes, these are valid points. I would also prefer to have local images for the important stuff and not depend on the network connection and the availability of the source.

I would consider in the future reversing the feature: instead of Reader Mode, have the Reader Mode features on by default, and instead introduce Verbatim Mode where all markup is shown (including e.g. LaTeX markup instead of rendering).

That's a very good idea. Focusing on the reading experience should probably be a priority. However, I have mixed feelings about the inability to collapse sections. In that case some ToC would be useful. But this is what the outline is for, in the first place. The good thing is that all these ideas can be toggled with a simple switch and tried out on a real corpus of .org documents.

[amake]

I have this mostly implemented. It will be in the release after 1.16.0.

[amake]

v1.17.0 will be available for testing pending review:

• Android
• iOS

[amake]

v1.17.0 has been released on all platforms.