On Saturday, April 22, 2023 at 4:51:13 PM UTC-5 Edward K. Ream wrote:
Iirc, the lack of identifying data with the 0xfffc character was why I abandoned this project years ago. It would be natural to allow body text to contain more than one image. Ordinary editing operations could change the order in which those images appear (or, as you say, delete images). You're correct, Leo could use uAs to associate images with 0xfffc characters *initially*, but I see no good (easy) way of *maintaining *those associations after *all* of Leo's editing operations. I've just reread Thomas's comment <https://github.com/leo-editor/leo-editor/issues/3256#issuecomment-1499892716> in #3256. It suggests using the @image directive. Leo already supports this directive. Instead, Leo could support a new *@embedded-image* directive. This directive would specify a path to an image file in the usual way (relative to the outline, with support for @path, etc.). This plan should work: - When loading/reloading the body pane, Leo would scan for @embedded-image directives and add the "magic byte" for Qt. - Leo's *onBodyChanged* event handler would do the same. In short, Leo could easily update the correspondence between magic bytes and images. There is no need for uAs. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/47728bba-b7e3-4ce4-8140-ef7a27163764n%40googlegroups.com.
