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: Mon, 27 Apr 2020 18:47:11 +0300 Message-ID: <83k1213p8g.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> <83y2qi5n3d.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="102260"; 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 Mon Apr 27 17:48:22 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 1jT5zO-000Q8W-Tv for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 Apr 2020 17:48:11 +0200 Original-Received: from localhost ([::1]:52662 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jT5zN-0005VE-Ko for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 Apr 2020 11:48:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41950) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jT5zG-0005V6-PH for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2020 11:48:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jT5zG-0003DI-7B for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2020 11:48:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54626) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jT5zF-0003DD-RW for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2020 11:48:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jT5zF-0006HB-PQ for bug-gnu-emacs@gnu.org; Mon, 27 Apr 2020 11:48: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: Mon, 27 Apr 2020 15:48: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.158800244724059 (code B ref 40845); Mon, 27 Apr 2020 15:48:01 +0000 Original-Received: (at 40845) by debbugs.gnu.org; 27 Apr 2020 15:47:27 +0000 Original-Received: from localhost ([127.0.0.1]:37939 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT5yd-0006Fw-S4 for submit@debbugs.gnu.org; Mon, 27 Apr 2020 11:47:27 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38904) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT5yb-0006Fe-Qf for 40845@debbugs.gnu.org; Mon, 27 Apr 2020 11:47:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38305) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jT5yW-0001mw-G2; Mon, 27 Apr 2020 11:47:16 -0400 Original-Received: from [176.228.60.248] (port=2275 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jT5yV-0004w3-V5; Mon, 27 Apr 2020 11:47:16 -0400 In-Reply-To: (message from Pip Cet on Sun, 26 Apr 2020 19:00:36 +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:179158 Archived-At: > From: Pip Cet > Date: Sun, 26 Apr 2020 19:00:36 +0000 > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org > > > 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. "More general" in what sense? Using Lisp does mean you could write more general programs, but it doesn't necessarily mean you will be able to solve more general problems. The display code maintains a lot of state that describes each position on the screen (see 'struct it' in dispextern.h), and your proposal seems to expose only the font and the face attributes to the Lisp function. What about the other information? are you suggesting to expose that as well? For example, some use cases may wish to know the pixel coordinates of the image being rendered, or whether it's on a continued or an R2L line, or the ascent or descent of the screen line, or the pixel distance from the window edge, etc. etc. The display code has all of that at its fingertips. > > > 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. That's what I thought. Then I don't think I understand your comment about "moving code into the image backend", since I never proposed to move anything into those libraries. We need to force those of the libraries that are capable to produce the images we want. Like force a certain background of an SVG image. That is all done outside of the backends. > > 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. I meant a Lisp program that prepared the spec before redisplay was entered. There's no need to re-evaluate it each time the corresponding part of the screen is updated or Emacs needs to calculate its layout for other purposes, such as moving the cursor N lines down on the screen. Please consider how many times this code will be executed, sometimes in contexts that are completely unrelated to showing the images. > 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. We should identify the aspects of the images we'd like to control, and enhance the image display to obey those aspects when needed. This is not complicated enough to call for a Lisp implementation, and doesn't justify the downsides of calling Lisp from the display code. > 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). I indeed prefer to avoid extending the display engine in Lisp, as explained elsewhere. I hope I convinced you, or that at least you see my point. Other extensions of the display code are much more welcome, although the resulting complexity should be carefully considered and weighed against the advantages. The display code is extremely complex and handles an almost infinite number of use cases, so much so that it sometimes takes years to find bugs in some subtle use case. We should try not to over-complicate the code without a good reason. And a theoretical "generalization" is not a good reason in my book. > 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. Could you please show examples of such symbols, and tell how they are displayed by other editors or word processors? > 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. I don't want to limit generality, I want to limit the price we pay for a use case that has yet to materialize. I think this keeps the Emacs display code from becoming completely unmanageable.