Re: Rethinking the design of xwidgets

[Aiko Kyle]

On Tue, Oct 13, 2020 at 12:36 PM, Tomas Hlavaty <tom@logand.com> 
wrote:

> some kind of canvas was discussed in
> id:87zh9hrxfj.fsf@logand.c
> and
> id:83img4aegz.fsf@gnu.org
>
> It was discussed in context of a WYSIWYG editor features, and 
> console
> based pdf viewer emacs-frabuffer and pure elisp pdf generator 
> emacs-pdf.
>
> Eli suggested:
>
>    > If you want to do layout for PDF, I think one way forward 
>    > would be
>    > to implement a pdfterm.c "terminal" for Emacs, which 
>    > produces PDF
>    > like the existing *term.c backends do for supported display 
>    > types.
>
> that might be better than some kind of xwidget

I don't immediately see the connection of this proposal to 
mine. It seems like pdfterm would be a display backend like xterm 
that renders to PDF, however this is already possible using the 
x-export-frames command which uses cairo to render the emacs frame 
to. It seems like the hard part of making Emacs a WYSIWG editor 
isn't the rendering of the display to pdf, but rather all the 
features of a WISYWIG editor such as placement of arbitrary text 
boxes on screen.

> It is not clear to me, why a dynamic module would be better.
>
> For example, emacs-framebuffer can display svg images without 
> any
> dynamic module by using external program, because emacs-nox does 
> not
> have cairo or librsvg or NS toolkit.
>
> Ideally, there would be a canvas (e.g. pdfterm) providing 
> low-level
> drawing primitives (something like html canvas API) and the rest 
> built
> on top of that in elisp.

I wasn't previously aware of emacs-framebuffer. It's an 
interesting idea but I don't think it's very relevant to my 
goal. It doesn't appear that Emacs is very "aware" of the image 
with emacs-framebuffer. In otherwords the image won't move inline 
with the rest of buffer contents will it? The line that the image 
is on won't have the height of the image?