otfried
support externally linked (instead of embedded) images
This is a first step towards external image support, see also #545. I think we can copy most of the UX here from the inkscape SVG editor, which already has a very similar functionality:
- https://inkscape-manuals.readthedocs.io/en/latest/import-pictures.html
- https://wiki.inkscape.org/wiki/Image_properties_dialog_enhancements
- https://wiki.inkscape.org/wiki/Linked_bitmap_manager
- https://wiki.inkscape.org/wiki/Image_links_manager
ToDo:
- [x] read image data from external file instead of base64 data in XML when encoding is "externalPath"
- [x] check that paths are always resolved relatively to ipe file (which is not necessarily the cwd?)
- [ ] do not change cwd, but store a per-document relative base path instead
- [x] use path info instead of image data when writing XML (may need special treatment for PDF)
- [x] update paths when saving in a different directory
- [x] use replacement image buffer when image could not be loaded
- [ ] reload external images when running latex (or only do so if their timestamps changed)
- [ ] check handling of links when autosaving to different (central) directory
- [ ] UI: allow user to choose between embedding and (relative/absolute) linking when inserting images
- [ ] UI: allow converting present images between embedded and linked in right-click context menu
- [ ] UI: find way of handling / resolving external images that cannot be loaded (e.g. search again with a base path different from current working dir, allow giving absolute paths to replacements,...)
- [ ] UI: ask whether we should use embedded image data when path from just-loaded PDF cannot be resolved (same for reloading external images that suddenly no longer exist)
- [ ] allow "temporarily" storing image data externally for quicker autosaving and on ipe-web
Perhaps we should discuss if it is worth adding this complexity to Ipe before we proceed - because, strictly speaking, it does not add new functionality.
You can already store your images externally by making a text label with contents
\includegraphics{myimage}
This could be made more comfortable by having the "import image" function create the text object, and we could have a function (or perhaps an ipelet) that externalizes an image that is currently internal.
What can be done with encoding="externalPath" that cannot also be done with \includegraphics ?
You can already store your images externally by making a text label with contents
\includegraphics{myimage}
That is a very good point, as it actually also allows to include PDF pages and all the other arguments of includegraphics.
The downside is that the free-text LaTeX label is very hard to work with programatically. It is harder to catch errors due to images that have moved and much harder to automatically update all their paths, especially if a label contains some additional LaTeX code.
This could be made more comfortable by having the "import image" function create the text object, and we could have a function (or perhaps an ipelet) that externalizes an image that is currently internal.
That sounds like a very good idea!
What can be done with encoding="externalPath" that cannot also be done with \includegraphics ?
The only advantage would be that it is much easier to edit programatically, but I do see that throwing around more weirdly-encoded byte buffers is not that nice.
So maybe let's take one step back and first think about what we actually want feature- and UX-wise and then think how we want to achieve this through library C++ / ipelet lua code and a maybe updated XML data representation. I'll try to give my 5 cents on this in the linked issue some time later today.
Please change it so there is an additional attribute path on <bitmap> objects whose value is the file path. The contents of the <bitmap> element should simply be empty, and encoding should not be used.
This is more in line with how <bitmap> elements look inside PDF files, and like those, they should be saved in the short format
<bitmap id="27" path="myfigure.png" width="720" height="360" />