Re: Drawing in images?

[joakim@verona.se]

MON KEY <monkey@sandpframing.com> writes:

> 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.

True.

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

I its not currently possible, but Miles Bader has a image background
patch I think.

> 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.

Maybe so, but how does one place Emacs glyphs on pixel coordinates then?

> 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
> :)

True. However, another thing I'm working on is embedding other
applications inside Emacs windows with Xembed, a facility I named
Xwidgets. I aim to patch Inkscape so it supports xembed, so it can be
embedded inside Emacs. Then one could conveniently edit the SVG as xml
in emacs, and graphically inside an embedded Inkscape, that could
furthermore be controlled with Emacs-lisp. (Daniel Hackney is working on
something similar using the Uzbl webkit browser and the xwidget patch)

One aproach doesnt exclude the other however.

>> 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.

For my current use-case, interactively defining areas in an image, using
text would be fine, even though I'm having trouble seeing how one would
achieve pixel precision that way.

>> Joakim Verona
>
> s_P
>
-- 
Joakim Verona