On Sun, Apr 23, 2023 at 9:07 AM Thomas Passin wrote:
> Once we get embedded images working well, we can go after tables.
>
Yes.
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
Once we get embedded images working well, we can go after tables.
On Sunday, April 23, 2023 at 9:05:54 AM UTC-4 Edward K. Ream wrote:
> On Sun, Apr 23, 2023 at 7:19 AM Thomas Passin wrote:
>
>
> > uAs would avoid the need to put an image file in another directory,
> where it could get
On Sun, Apr 23, 2023 at 7:19 AM Thomas Passin wrote:
> uAs would avoid the need to put an image file in another directory, where
it could get separated from the outline. This separation (and a need for
uAs) could be avoided if we had an archive format for Leo outlines. Maybe
images could be
On Sunday, April 23, 2023 at 7:06:36 AM UTC-4 Edward K. Ream wrote:
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
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
On Saturday, April 22, 2023 at 5:51:13 PM UTC-4 Edward K. Ream wrote:
On Sat, Apr 22, 2023 at 3:26 PM Thomas Passin wrote:
I've made a little progress. That unicode character - 0xfffc - is only a
marker and does not carry any information about the image.
Iirc, the lack of identifying
On Sat, Apr 22, 2023 at 3:26 PM Thomas Passin wrote:
> I've made a little progress. That unicode character - 0xfffc - is only
> a marker and does not carry any information about the image.
Iirc, the lack of identifying data with the 0xfffc character was why I
abandoned this project years
I've made a little progress. That unicode character - 0xfffc - is only a
marker and does not carry any information about the image. But behind the
scenes, Qt keeps the image data and associates it with that marker. The
actual image bits are stored in Qt's "resources" for the page, and
In an internet search I found that saving would probably best be done by
walking through all the blocks on a page, of which the image would be one.
During restoring a body, I suppose that one would insert the blocks one by
one, though I am less clear about how to do that. It seems to me that
On Tue, Mar 28, 2023 at 5:04 PM Thomas Passin wrote:
It would be very useful if an image could be embedded into a Leo body.
> Probably no one would want to do this in a program or script, but for
> documentation it could be very helpful.
>
...
> In theory it should be possible to put an image
On Tuesday, March 28, 2023 at 8:59:01 PM UTC-4 gates...@gmail.com wrote:
Not what you’re really looking for, but Leo already supports @svg nodes.
Of course, those are just the image in a node, viewable in VR — no text
around them in the same node, to my knowledge.
Right, and VR3 has even
Not what you’re really looking for, but Leo already supports @svg nodes. Of course, those are just the image in a node, viewable in VR — no text around them in the same node, to my knowledge.I’ve done kinda-sorta similar things with one of my personal use ‘leo apps’. In that use case, I had a
It would be very useful if an image could be embedded into a Leo body.
Probably no one would want to do this in a program or script, but for
documentation it could be very helpful. You can put an image into a ReST,
MD, or Asciidoc node and view it with VR3 or by creating Sphinx output.
But
13 matches
Mail list logo
