From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: Drawing in images? Date: Fri, 28 Aug 2009 12:22:17 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1251476560 32399 80.91.229.12 (28 Aug 2009 16:22:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Aug 2009 16:22:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 28 18:22:33 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Mh4Df-0002OE-4R for ged-emacs-devel@m.gmane.org; Fri, 28 Aug 2009 18:22:31 +0200 Original-Received: from localhost ([127.0.0.1]:52440 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mh4De-0001PY-91 for ged-emacs-devel@m.gmane.org; Fri, 28 Aug 2009 12:22:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mh4DY-0001Lg-JM for emacs-devel@gnu.org; Fri, 28 Aug 2009 12:22:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mh4DU-0001Bi-18 for emacs-devel@gnu.org; Fri, 28 Aug 2009 12:22:24 -0400 Original-Received: from [199.232.76.173] (port=40782 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mh4DT-0001B1-7o for emacs-devel@gnu.org; Fri, 28 Aug 2009 12:22:19 -0400 Original-Received: from mail-gx0-f206.google.com ([209.85.217.206]:63496) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mh4DS-0002gI-K4 for emacs-devel@gnu.org; Fri, 28 Aug 2009 12:22:18 -0400 Original-Received: by gxk2 with SMTP id 2so2574398gxk.7 for ; Fri, 28 Aug 2009 09:22:17 -0700 (PDT) Original-Received: by 10.150.16.14 with SMTP id 14mr2425456ybp.246.1251476537476; Fri, 28 Aug 2009 09:22:17 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: acc5c5bef3389d6e X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114772 Archived-At: Joakim, On Thu, Aug 27, 2009 at 3:05 PM, 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