From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: Drawing in images? Date: Thu, 27 Aug 2009 21:05:17 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1251400157 21936 80.91.229.12 (27 Aug 2009 19:09:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Aug 2009 19:09:17 +0000 (UTC) Cc: Daniel_Hackney@brown.edu, Miles Bader , emacs-devel@gnu.org To: MON KEY Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 27 21:09:09 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 1MgkLL-0007Sj-J9 for ged-emacs-devel@m.gmane.org; Thu, 27 Aug 2009 21:09:07 +0200 Original-Received: from localhost ([127.0.0.1]:41607 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgkLK-0008Oa-U3 for ged-emacs-devel@m.gmane.org; Thu, 27 Aug 2009 15:09:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgkLD-0008OB-Fi for emacs-devel@gnu.org; Thu, 27 Aug 2009 15:08:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgkL7-0008L2-4Q for emacs-devel@gnu.org; Thu, 27 Aug 2009 15:08:57 -0400 Original-Received: from [199.232.76.173] (port=49404 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgkL6-0008Kz-TA for emacs-devel@gnu.org; Thu, 27 Aug 2009 15:08:52 -0400 Original-Received: from proxy3.bredband.net ([195.54.101.73]:37490) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MgkHm-00022r-Mv; Thu, 27 Aug 2009 15:05:26 -0400 Original-Received: from iph2.telenor.se (195.54.127.133) by proxy3.bredband.net (7.3.140.3) id 49F597CD0315D535; Thu, 27 Aug 2009 21:05:21 +0200 X-SMTPAUTH-B2: joakvero X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApJnAH91lkpT44qWPGdsb2JhbACKC5B9AQEBATe+EIQZBQ X-IronPort-AV: E=Sophos;i="4.44,287,1249250400"; d="scan'208";a="38862298" Original-Received: from ua-83-227-138-150.cust.bredbandsbolaget.se (HELO exodia) ([83.227.138.150]) by iph2.telenor.se with ESMTP; 27 Aug 2009 21:05:20 +0200 Original-Received: from localhost.localdomain (DIR-655.lan [192.168.200.113]) (authenticated bits=0) by exodia (8.14.3/8.14.3) with ESMTP id n7RJ5Hf3024600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 27 Aug 2009 21:05:18 +0200 In-Reply-To: (MON KEY's message of "Thu, 27 Aug 2009 14:07:57 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:114698 Archived-At: MON KEY writes: > On Thu, Aug 27, 2009 at 2:31 AM, wrote: >> MON KEY 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