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: Sat, 25 Apr 2020 23:11:23 +0300 Message-ID: <83d07v72c4.fsf@gnu.org> References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83o8rf7fc0.fsf@gnu.org> <83lfmj7dh7.fsf@gnu.org> <83eesb7833.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="10891"; 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 Sat Apr 25 22:12: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 1jSR9n-0002hQ-OQ for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Apr 2020 22:12:11 +0200 Original-Received: from localhost ([::1]:46812 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSR9m-00025I-Cy for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Apr 2020 16:12:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39758) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSR9f-000250-Ic for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 16:12:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSR9f-0006Df-2g for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 16:12:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48864) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSR9e-0006DT-Md for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 16:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jSR9e-0005wH-G4 for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 16:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Apr 2020 20:12:02 +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.158784550222804 (code B ref 40845); Sat, 25 Apr 2020 20:12:02 +0000 Original-Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 20:11:42 +0000 Original-Received: from localhost ([127.0.0.1]:60410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSR9K-0005vk-7T for submit@debbugs.gnu.org; Sat, 25 Apr 2020 16:11:42 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSR9J-0005vX-2C for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 16:11:41 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60600) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSR9D-0005EA-O3; Sat, 25 Apr 2020 16:11:35 -0400 Original-Received: from [176.228.60.248] (port=2333 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSR9C-0008NS-Qu; Sat, 25 Apr 2020 16:11:35 -0400 In-Reply-To: (message from Pip Cet on Sat, 25 Apr 2020 19:41:31 +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:179031 Archived-At: > From: Pip Cet > Date: Sat, 25 Apr 2020 19:41:31 +0000 > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org > > My use case is to include a glyph which is supposed to look like a > character, but doesn't actually have a unicode codepoint. (I'm sorry > if this differs from the use cases you're exclusively concerned with, > but it appeared to be relevant enough to Clément's problem that I > assumed he was having a similar issue). > > That means that we want to use an image spec, not a character in a > font; but that image spec depends on face/font properties, because we > want to blend in with surrounding text. The most obvious ones are > foreground and background color and size, but slant and weight would > also affect properly-rendered character-like images. 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 don't see anything in the above attributes that would be hard to have within the existing framework of how we display images. 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. None of this requires a new spec or calling Lisp. All of the metrics of the current face's font are known by the display code, and there are many that cannot be obtained from Lisp, like the current line height. Doing these calculations in Lisp is IMO the worst possible way of using Lisp callouts from the display engine: this has all the disadvantages of calling Lisp, and none of the advantages. > It seems fairly obvious to me that it's a bad idea to do all the work > in the display engine or in C code: sub-pixel rendering and > anti-aliasing are hard to get right. Aren't we talking about displaying existing images, which someone already prepared while using all those techniques? Why would the display engine want or need to modify the image using them? > A character-like glyph might need a third color which provides > sufficient contrast to the foreground and background colors, and > that color space calculation is complicated enough to be moved to > Lisp. 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. Those who design such icons do a much better job than any Lisp program. > But all these limitations are fixable. They wouldn't have existed if you used the code which displays images. So I still don't understand the motivation for this approach. (Read: I think it's wrong.)