From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#40845: SVG rendering issues Date: Sun, 26 Apr 2020 19:00:36 +0000 Message-ID: References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83o8rf7fc0.fsf@gnu.org> <83lfmj7dh7.fsf@gnu.org> <83eesb7833.fsf@gnu.org> <83d07v72c4.fsf@gnu.org> <83y2qi5n3d.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="45465"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 26 21:02:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jSmXa-000BhC-TX for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 26 Apr 2020 21:02:11 +0200 Original-Received: from localhost ([::1]:42908 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSmXZ-0007cD-NS for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 26 Apr 2020 15:02:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43538) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSmXT-0007bp-0a for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2020 15:02:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSmXS-00051k-BG for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2020 15:02:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51617) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSmXR-00051e-UA for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2020 15:02:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jSmXR-0002W1-Ph for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2020 15:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 19:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40845 X-GNU-PR-Package: emacs Original-Received: via spool by 40845-submit@debbugs.gnu.org id=B40845.15879276809615 (code B ref 40845); Sun, 26 Apr 2020 19:02:01 +0000 Original-Received: (at 40845) by debbugs.gnu.org; 26 Apr 2020 19:01:20 +0000 Original-Received: from localhost ([127.0.0.1]:34930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSmWl-0002V0-W9 for submit@debbugs.gnu.org; Sun, 26 Apr 2020 15:01:20 -0400 Original-Received: from mail-ot1-f51.google.com ([209.85.210.51]:46705) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSmWk-0002Ul-39 for 40845@debbugs.gnu.org; Sun, 26 Apr 2020 15:01:18 -0400 Original-Received: by mail-ot1-f51.google.com with SMTP id z25so22339867otq.13 for <40845@debbugs.gnu.org>; Sun, 26 Apr 2020 12:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1OHwzJF1k/qVbyJ5r0vPtJlgYRxtFwDwORgyYdvWuJU=; b=aJD1xwaKpDndosGtjuF+I2dkyX5vh5bm6wAFaIN9VoxaGrjHVXM8fljn/3lP+8EXio 5zg4/yTiGhFk/Eap+AhkDkZPvZd0jbmX748tPDdp35UtboISAbEm9QvJzusHkBeBksz6 qocuKnmGiFz0Mh9fqHKc5zdoZDdIzNojWugB8Dq8hmxXzjF/WCEac4VzESxJ+aOB8UJi 5HhhYOwGq/FFJX2M7VBJH69hHG+YFf33fnacwaKx+MLl8+FlRJzpylWVPoH2dSsZ32F7 uBYq5ulm3ADDYjZjc/9L1ibCGxesj6le/lsnWGQ/QUd0S373T9eRNSXvJOStTZSpDgBf HvFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1OHwzJF1k/qVbyJ5r0vPtJlgYRxtFwDwORgyYdvWuJU=; b=Nk20VEBMTOGqMQFLT7JDCZrJdSp3bdPwZsG1Ku79OWSOig+yDif0siMGxB/bdqw9rx DYxfVtHLUe/8ut1BHPLjuKzbrJ4RF2JsP6X3bnd45e3xctNEHEIY1xRyFjZODLTNQeMX JXSjh7sjmG6XxjzmPpfGcx/5/+Mw5RMDLxDWP4bSl2uhKwwVMQlx9rNuEf6jsBTOD65r zJiOEtrNG32bAqjU1cho9OG3hf1FVsDk2KKyS5tmOylrgGUjQJLB8mefKyG+pFmIjYRL 5JEC6Dca9Q5kLQZMA8uy/aaoe9YL795J7MsP0Qn29NmaNzvZ0XPbsW54lgOsTSq3Ktj0 kvJg== X-Gm-Message-State: AGi0PuaYfCOkqSyvyEXSvLc6PpnNZ1sEGDvEwqcma239vbAe30ZszJUG Zv9EVi6ZNZg2OkZn7IDAH+N7jXjyxwo8QRlc18U= X-Google-Smtp-Source: APiQypKNL13WjgeBLAx/dnphh9qBQnSo2cABvL2V06KUyqeZqIpvr/MlCI1FBuhYXww/16pU4pKTVphXkCx6A+lgbw4= X-Received: by 2002:a9d:23a6:: with SMTP id t35mr17103659otb.154.1587927672312; Sun, 26 Apr 2020 12:01:12 -0700 (PDT) In-Reply-To: <83y2qi5n3d.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:179106 Archived-At: On Sun, Apr 26, 2020 at 2:38 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Sun, 26 Apr 2020 10:15:39 +0000 > > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org > > > > > If we want to display an image, the logical way would be to use an > > > image spec, which is already supported, enhancing it as needed. > > > > I want to display a glyph that looks different depending on its > > textual context. That means it's not "an image", in the traditional > > sense. > > Then I guess we are talking about two different use cases. A more general one, and a more limited and specific one. As it happens, the fix for the more general one is simpler. > This bug > report was filed in the context of this discussion: > > https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg01386.html > > where I said that I think such UI effects should be implemented by > using images, not special characters and special fonts. Indeed. You're right about that. We should use dynamically-generated image specs for them. That's what my patch allows for. > > and enhancing image specs to handle such context-dependent > > glyphs is wrong, because it moves code into the image backend that > > applies to all image backends. > > "Image backend" in this context is the image libraries, like librsvg > and libpng, is that right? Yes. > If so, which one of them can do the stuff > Cl=C3=A9ment reported missing? Err, who said they could? I'm saying they _shouldn't_. It's not the image backend's job to alter and adapt an image, just to read a compressed version of a bitmap and uncompress it, interpreting whatever method of compression (say, vectorization) was chosen. > > The enhancement I propose is a layer of indirection, allowing the > > image spec itself to be adjusted to face/font properties. > > The kind of adjustments that we need for the use case which prompted > this discussion can be done inside the display engine. As opposed to doing them when the spec is evaluated? > > And, no, there's no way for an image backend to interpret that. We > > have to use different image specs. > > A Lisp program that prepares such display can prepare the spec > accordingly, if needed. That's what I'm proposing: call a Lisp program to prepare a spec whenever we display the glyph. Not more often, which is wasteful. Except you're currently wrong: a Lisp program cannot prepare "the spec" accordingly, because there might be several required specs in effect at the same time, for example. > Any effects that cannot be explicitly > produced by Lisp and we'd need the display code to produce can be > communicated using the image spec keywords, like we always do. For > example, if we want the image to scale with the surrounding face, we > can have a special value of the :scale attribute. And similarly with > other attributes; we can also invent new keywords for attributes > currently not supported. Yes, that describes what I'm doing, except for the important point that the spec is generated per occurence of the glyph rather than once globally. > > "you want images, not character-like glyphs" isn't an argument, it's > > simply a statement that you don't want my use case to be supported. > > It just means your use case is different from what is being discussed > here, and serves purposes other than those which prompted this bug > report. I don't think we should mix them. It's strict containment: my use case is more general. > > > Within the context of what these icons are supposed to be used for, I > > > envision the images coming with bright, catchy colors that should be > > > left alone, not enhanced by color and contrast tweaking of whatever > > > happens to be the face colors the user wants. > > > > I'm not sure which icons you're thinking about, but I certainly don't > > want my symbols to have "bright, catchy colors that should be left > > alone". > > I suggest to read the above discussion, and also look at the UI > look-and-feel that is being sought. You will see many examples there > of the kind of images that people would like to see. I think their > vivid colors is one of the main aspects that attract users to such UI. I did read the discussion, and the main thing mentioned about their colors is that they shouldn't be fixed, i.e. not "left alone". > > I'm still not sure whether you're suggesting anything that would > > handle my use case even remotely, or simply saying it's not a use case > > that Emacs should be extensible to. > > I guess I'm saying the latter. My impression is you're treating extensibility itself as something to be avoided, not as something on the benefit side of a cost-benefit analysis (cost: 5 lines of actual code. benefit: solves both the more specific use case sought here and the more general use case I need). > Maybe if you explained when such use > cases arise, I will agree with you. But in any case, it's a different > use case. A more general one. As to how they arise: mathematicians, for example, have a long-standing tradition of making up symbols. Those new symbols aren't (and shouldn't be) in Unicode, and there are many other symbols that, for example, cannot be in Unicode for legal or ethical reasons. Users should be able to display such symbols in an Emacs buffer and have them be as close to character glyphs (or different from them) as they are willing to make them. I remain convinced that I'm not smart enough to figure out in advance the precise set of use cases I want a feature for. You shouldn't limit generality to handle only those cases you're convinced are useful.