Re: Drawing in images?

[MON KEY]

Joakim,

On Thu, Aug 27, 2009 at 3:05 PM, <address@hidden> wrote:
>
> Maybe so, but how does one place Emacs glyphs on pixel coordinates then?
>

Presumably the same way one places an SVG.

>
> One aproach doesnt exclude the other however.
>
Which mutual exclusion are you dereferencing?
UZBL /<-> Xxidgets
or
SVG /<-> text-glyph-based

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

Most likely one can't it would have to be ``good enough''.

That said, I'm having trouble understanding how one can achieve
reasonable pixel prec. when placing an SVG non-interactively. I don't
see where this will be better than ``good-enough''.

If the precision of the SVG is to rely on the use of mouse-events in
Emacs to record Emacs posn(s) x,y and subsequent mapping of these
posn(s) to corresponding pixel positions in the source image and SVG
`overlay' there _will_ be multiple user overshoots and mis-placements.
It is difficult enough to set a dynamically scalable box with a GUI
let alone reliably setting posn(s) without the aid of an interactively
scalable box.

This is exactly the issue with setting a slice in docview (see
Stefan's comments above). In the absence of visual feedback from Emacs
it is _very_ difficult to be sure which box is getting set and by the
time you find out if you did it correctly Emacs is already well into
the process of regenerating the image cache.

What I am suggesting is that barring an entirely embedded external GUI
within an Emacs window (which is your use case) non-interactive SVG
layering will in many instances none the less remain less precise than
an inexact but interactive placement of a text base rectangle. Where
this is the case, and where an artist.el style text based rectangle
would otherwise suffice it seems more in keeping with Emacs WODT to
use a text based approach of an existing package and would allow
easier integration with emacs procedures which are not as-yet
Xembed/UZBL aware.

> Joakim Verona

s_P