Hi Aiko & Team Emacs! Thanks for working on this.
On Tue, Oct 13, 2020 at 4:33 PM Aiko Kyle <aikokyle@gmail.com>
wrote:
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.
This sounds wonderful fwiw.
> 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.
I wanted to offer a sample of a few things my pet project[0][1]
has
been able to do with SVG updates. While I won't get into our
aims*,
at least for now, we are finding the updates following the mouse
sufficient that I'm continuing in this direction. Nothing
attempted
with drag nor using alpha transparency thus far but this seems
like an
experient I'd be in a position to conduct if that may be
interesting.
We're fairly happy with a multi click interface so far, probably
given
the snap-to-point effect.
Here is a direct link to a recent animated GIF. While the
sources
here are very, very ugly in my estimation a clean implementation
is
clearly possible. Moreover, it would be of keen interest if
such
things are available from core by the time our game works :)
_Interactive Drawing Demo_
https://bru.st/i/hUfqzqy48w.gif
Perhaps less to topic and more as bonus bread-crumbs for someone
willfully curious, our project is aiming to store all user data,
including game sources (monsters, maps, characters, ...), in
org-mode
documents. So far this is working well; however, that design is
both
extraneous and too tightly coupled with respect to a more
serious
effort to replicate (or extricate) the interactive drawing
functionality here for more general purposes. It was somewhat
in this
vein, in fact, that I recently began extracting the "draw"
functionality from dm-map.el into dm-draw.el, which also omits
some
"predicate" logic used to decide which parts to render out "on
the
fly". Finally in this vein, our demos do their own scaling
(and
incur the associated performance cost), relating to our use-case
of
sending unscaled "spoiler" free SVG data from the host to the
player
clients.
> 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.
Again fwiw, this is a nice fit in terms of direction for
dungeon-mode
- we are already rendering SVG, involving manufacturing DOM
nodes,
which seems to make for efficient processing and may also mesh
nicely
with unrelated work such as around an ebook reader feature iiuc.
We took a hard-parts first mentality and success creating a
progressively rendering interface to display game maps has led
us to
try creating an interactive, visual editor for the maps. I've
submitted some talks related to the project; if some of these
are
accepted, and if there are any questions from this group, I
would be
happy to try working in responses to them, so that more
show-and-tell
experience is possible and recorded for whatever use it could be
down
the road.
Corwin
[0] dungeon-mode, overview:
https://directory.fsf.org/wiki/dungeon-mode
[1] dungeon-mode, src, etc:
https://git.savannah.nongnu.org/cgit/dungeon.git/
[3] "dm-sketch", Monday, 2020-10-11 @ oops-its-the-am:
https://bru.st/i/hUfqzqy48w.gif