From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#40845: SVG rendering issues Date: Sun, 26 Apr 2020 17:38:14 +0300 Message-ID: <83y2qi5n3d.fsf@gnu.org> References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83o8rf7fc0.fsf@gnu.org> <83lfmj7dh7.fsf@gnu.org> <83eesb7833.fsf@gnu.org> <83d07v72c4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="17333"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 26 16:45:18 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 1jSiWz-0004Mr-Eg for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 26 Apr 2020 16:45:17 +0200 Original-Received: from localhost ([::1]:60818 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSiWy-00046v-3S for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 26 Apr 2020 10:45:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59448) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSiQx-0001Ll-PQ for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2020 10:39:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSiQw-00028L-81 for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2020 10:39:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50574) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSiQv-00028G-S2 for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2020 10:39:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jSiQv-0007ec-Mf for bug-gnu-emacs@gnu.org; Sun, 26 Apr 2020 10:39:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Apr 2020 14:39: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.158791191129384 (code B ref 40845); Sun, 26 Apr 2020 14:39:01 +0000 Original-Received: (at 40845) by debbugs.gnu.org; 26 Apr 2020 14:38:31 +0000 Original-Received: from localhost ([127.0.0.1]:33887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSiQR-0007ds-1r for submit@debbugs.gnu.org; Sun, 26 Apr 2020 10:38:31 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56408) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSiQP-0007df-KE for 40845@debbugs.gnu.org; Sun, 26 Apr 2020 10:38:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43964) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSiQK-0001Pp-7g; Sun, 26 Apr 2020 10:38:24 -0400 Original-Received: from [176.228.60.248] (port=1725 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSiQJ-0000s9-AU; Sun, 26 Apr 2020 10:38:24 -0400 In-Reply-To: (message from Pip Cet on Sun, 26 Apr 2020 10:15:39 +0000) 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:179070 Archived-At: > 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. 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. > 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? If so, which one of them can do the stuff Clément reported missing? > 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. Or at least I don't see a reason why it couldn't be. > > I don't > > really understand how you can make images "slant" or "bold" (unless > > they were like that to begin with), or why would we want to, but maybe > > there's some way of interpreting that as well. > > Because we want the glyph to blend in with surrounding text. Like a > character. Not really, not in the use case discussed here. > 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. 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. > "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. > I'm talking about displaying character-like glyphs. And I'm not. This bug report is about a different use case. > > 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'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. Maybe if you explained when such use cases arise, I will agree with you. But in any case, it's a different use case.