unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: MON KEY <monkey@sandpframing.com>
To: joakim@verona.se
Cc: emacs-devel@gnu.org
Subject: Re: Drawing in images?
Date: Thu, 27 Aug 2009 14:07:57 -0400	[thread overview]
Message-ID: <d2afcfda0908271107j2a1a93a3g43849869fa44481a@mail.gmail.com> (raw)
In-Reply-To: <m3fxbddaz1.fsf@verona.se>

On Thu, Aug 27, 2009 at 2:31 AM, <joakim@verona.se> wrote:
> MON KEY <monkey@sandpframing.com> writes:
>> there are some really amazing applications for applying
>> annotations/text-properties/alist lookups on 'regions' of processed
>> text/images...
>
> This should be possible by drawing a SVG image on top of another
> image. The SVG image is XML which can be generated in a buffer within
> Emacs.
>
> One difficulty with this aproach is that there isnt really much support for
> alpha channels in Emacs. Also latency in interactive use might not be
> spectacular.
>
> One difficulty with this aproach is that there isnt really much support for
> alpha channels in Emacs.

Why worry about layering with alpha channels at all then? Obv. SVG is
lighter (from a data size perspective) than a .bmp or .jpg but its
still considerably heavier than an Emacs text/string.

Isn't it possible to use an image as an Emacs window's background (if
not can't GTK be leveraged towards that end)?

Why not just use a smallish glyph e.g. `.' (or something smaller
dedicated to the purpose) and the text based facilites from artist.el
(or bespoke equivalent).
AIUI the position of the glyphs isn't necessarily the same as the
_size_ of the glyph as rendered.

Would a layered placement of an SVG provide/allow more user accuracy
than an equivalently positioned glyph. If so, how much more? Does the
gain warrant a departure from a text oriented approach? Why reinvent
Emacs as an image editor? It seems more reasonable to reorient the
task to an arena where Emacs is best acclimated - as a _text_ editor
:)

> Also latency in interactive use might not be spectacular.

If a window could have the image as a background over which text could
be displayed then interactive latency needn't necessarily be an issue.
Scaling/rescaling the box could be made by 'setting' a new rectangle
(or other shape)... e.g. artist-select-op-rectangle.

This approach might allow for interesting `annotation' applications as
well e.g. `artist-select-op-text-see-thru'
`artist-select-op-text-overwrite'. The use of text-properties here
could be are a very valuable feature; they are native to emacs, ought
to be able to carry much of the same information as an svg->xml
string, and can already interact with other native elisp facilities
and data structures without the need for additional XML
parsing/serializing routines.

> Joakim Verona

s_P




  reply	other threads:[~2009-08-27 18:07 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-27  0:52 Drawing in images? MON KEY
2009-08-27  6:31 ` joakim
2009-08-27 18:07   ` MON KEY [this message]
2009-08-27 19:05     ` joakim
2009-08-28 16:22       ` MON KEY
2009-08-27 22:21   ` Chong Yidong
2009-08-27 23:51     ` joakim
2009-09-16 19:04     ` joakim
2009-09-17 19:13       ` MON KEY
2009-09-17 21:04         ` Lennart Borgman
2009-09-17 21:08           ` Lennart Borgman
2009-09-17 23:00           ` Jason Rumney
2009-09-17 23:09             ` Lennart Borgman
2009-09-17 21:46         ` joakim
2009-09-17 22:09           ` Lennart Borgman
2009-09-17 22:46             ` Juanma Barranquero
2009-09-17 22:56               ` Lennart Borgman
2009-09-17 22:56         ` Jason Rumney
2009-09-17 22:59           ` Lennart Borgman
  -- strict thread matches above, loose matches on Subject: below --
2009-09-29  0:31 MON KEY
2009-09-29  5:29 ` martin rudalics
2009-09-29 20:25   ` MON KEY
2009-08-25 22:57 joakim
2009-08-26  1:07 ` Stefan Monnier
2009-08-26  5:58   ` joakim
2009-08-26 14:45     ` Stefan Monnier
2009-08-26  9:05   ` Jason Rumney
2009-08-28  0:49 ` YAMAMOTO Mitsuharu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d2afcfda0908271107j2a1a93a3g43849869fa44481a@mail.gmail.com \
    --to=monkey@sandpframing.com \
    --cc=emacs-devel@gnu.org \
    --cc=joakim@verona.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).