From unknown Thu Jun 19 14:30:14 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#40845 <40845@debbugs.gnu.org> To: bug#40845 <40845@debbugs.gnu.org> Subject: Status: SVG rendering issues Reply-To: bug#40845 <40845@debbugs.gnu.org> Date: Thu, 19 Jun 2025 21:30:14 +0000 retitle 40845 SVG rendering issues reassign 40845 emacs submitter 40845 Cl=C3=A9ment Pit-Claudel severity 40845 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 08:19:07 2020 Received: (at submit) by debbugs.gnu.org; 25 Apr 2020 12:19:07 +0000 Received: from localhost ([127.0.0.1]:58966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSJlz-0006sn-2F for submit@debbugs.gnu.org; Sat, 25 Apr 2020 08:19:07 -0400 Received: from lists.gnu.org ([209.51.188.17]:45442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSJlx-0006se-4H for submit@debbugs.gnu.org; Sat, 25 Apr 2020 08:19:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39044) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSJlw-00054f-Jc for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 08:19:04 -0400 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSJlw-0002pu-0j for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 08:19:04 -0400 Received: from mail-qk1-x730.google.com ([2607:f8b0:4864:20::730]:43884) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jSJlv-0002ji-JO for bug-gnu-emacs@gnu.org; Sat, 25 Apr 2020 08:19:03 -0400 Received: by mail-qk1-x730.google.com with SMTP id 20so13062661qkl.10 for ; Sat, 25 Apr 2020 05:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:autocrypt:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=EXyY7M8OIwPJshCO1sNAUYtcBQ1bW0LzSRehAzdcQ8M=; b=icDLS0zXfLfRrTWl0ziruretlWU26eaiAAb1xZQwt1/7LS1gRupfchILvM9bdN/0tq v8ViU8h0ZfSwB8dPVeobGEvOHKA/VjV0uzmCgMLHO5b2Wk5ACSvAKe07VjQVgg8c5UPG BCxjz5zzhuMVlzBFfF4kMKnqUbVKiqyhkLRuZyUHzDcl6JKpjbQzkuxx+uoTEkxWOiYr Ij3k9o013EndCxReGDdY6nzp1TAuAO3zU5kA8t9i4JTajjO4BLiMrcU3ge7FgAxvO/hp KAI0k95lGlk07Qgr0MJhUBK8wGlayjr78IN0+r2K3s1wtQ3Ryuhl6LSR/5YqKIjW5fEe TooA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:autocrypt:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=EXyY7M8OIwPJshCO1sNAUYtcBQ1bW0LzSRehAzdcQ8M=; b=k+v0/l27LlDDvpdnZMsdgEwrpFTVW+2rw3W/G0TEqDhYlnwWZ4wpPyyiv2lJZOZHag j/mVqzInUyN57P53ukn92Mg6/hK+//HfQBVDrhPNrwEjdNK2qKxnzZwXcOaml31Eghaz MsvPsRurpu25UgKHfUM+vz6jiTKNc1FE90y3uSt38En6G7xSdil0oxgxe8RyL//IbM4D U8EmN/PVuH49p/FPXFhwzTQpeg6m3IItAkb1RClKrAtNyECqqDs+/YvOibsERtHk40VD kVcY+VsqZ66fRl5bPcMj46Gmv4mt2jiV7sNlqiBOlkFMdiO6SQGT8jh/TUolnUWn40mc UcyQ== X-Gm-Message-State: AGi0Pua/fy95Xgs2anZ+r60RLM6rbBE63PoN/rI797I0n3B9RBOOzsEN P9h4LXVptHovtrY46ckGH7RAM2Ar X-Google-Smtp-Source: APiQypJ4UaLssyz159ZIx6HRLiWHsjvEQ/DcXqCngfloj2ijI+Deib0BlXwD5aHb+Sud2/Jp+RNZFQ== X-Received: by 2002:a05:620a:b10:: with SMTP id t16mr13676271qkg.59.1587817142347; Sat, 25 Apr 2020 05:19:02 -0700 (PDT) Received: from ?IPv6:2601:184:4180:66e7:54d6:bfeb:aa49:9d3b? ([2601:184:4180:66e7:54d6:bfeb:aa49:9d3b]) by smtp.googlemail.com with ESMTPSA id s14sm6032134qts.70.2020.04.25.05.19.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Apr 2020 05:19:01 -0700 (PDT) To: bug-gnu-emacs From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Autocrypt: addr=clement.pitclaudel@live.com; prefer-encrypt=mutual; keydata= xsFNBFStGiEBEAC8eHa+DdcrVtDSwYoIgoUtMfRAan4bdLxZuNIASy6iFytCHNsKqfPkq8zD YV2+uMtbdcnjapE038nidEMItNhO04JdZ+PJ6jvJo1gW+XI4fM8uzkGZauwR+d3hEq6goFSp rIlSlaVf2g5q4OKxI754yqwz00++EZhZQMntzoKQVV9stJ5eQ+gxTT1ANr7wQKbjn/8PM/Cg hBZvYLhh+WsS0Ko5qZuWdsvUBLpprmCWkP4FpZ234/tWpdVID65nlHpu25+6ajIcxfCIK+dN 2br0wN1szTeQFG19cfr3jXEvwHmLQbQqCg4UH+2b7JpMGR2/KWjqRWfWVvZMPVeJdOsZHx53 k6HIbEhvFBHbmqCI6FAZQjkgzGGkrSD92+jeMYiCTxRKqq2hFZ6xqQ6pJdXD1TXcIYPEs7rA MwcNMj8g4e6vuI+2CjHyQQkyMPAEi8guNPnyfBb648f1lxj7JiJu/ehRghIP5u/kLOsHNCKG QgCT04sawBZYHqEVYni8oHlGJcdWGT5/UI4B+wn70eXvYSScZEaB+S2s/bD0cdlSpHY5Od3l tpRZTva+ydswlrz4fxbYF45s6rFpqVwBMfNv3gqhBFXbuiEEctcTSGqhHxxT4R+24Yn+ZSBa EfUbrKnVTUmV20k+57rghiVw2wpj8v7sn3QXt96HJ9ImY4JvuwARAQABzTNDbMOpbWVudCBQ aXQtLUNsYXVkZWwgPGNsZW1lbnQucGl0Y2xhdWRlbEBsaXZlLmNvbT7CwXsEEwECACUCGyMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJUrRuVAhkBAAoJEPqg+cTm90wjResP/j6A9F81 5C78IKzYdYIa7dHNWi4djRdUd79iIHGeFrao6qf7NX3XZmWkpgWExeanaqS7MmJjyXYEh6La JnzojETK+LVYk2xOanKQch2QrxGZVsXFtp/h102J1yTkUKp4g3uyaVlMLDg1P4eHSJC2YHr2 GtE4HTMUW6SThZ1nJQTrSrVpxTL9hRU/O4VIycogD9++zQ3Y1KzGq5xEi+UbjmcycR0dhSSD vAqo3yU46rfgyKPT99JR0edvYAbJaw5uq35Y0y0L6/gV4Bj6c69TADeyc5iTvagPLUWfeWUv YS2M+j7EWRePRmkuBw1ZPxKlibhsfzZBtIt6jEFd+U8ES5ycm6LSqu3ryGlFuFvdrkWzO7Fp SsHo03r6jtc8nY2jnOzsuxVvakMW1JqAiIP2H57Xyv1gZWb60dJDy2k9M7SCONdFLSU6E3k1 ZjyVkWD2cDhoLV2jy11U9hxQt+OfH2M/f+1cZe5Fberz4ceQ0ssLdfOo4dcGd+MW1lixXYj/ VrZj+QmqOdpzjxyLlzd94Mj7cvNzn/bJV4af6fgY+zbGHj8POrIVrIVO0B2/lSLG2HqO+srI 38gpz8vsVuqtuA5QSPT58H3PeAn0uYetCYNammoPRbQadgQOa8z2Bns2c2HsDj4baMck8d+h PDf7MdiEAW7zE6pxQtdr0xo6EREczsFNBFStGiEBEADTKhFNyVXInTxg1rioBtixWbNr2yRt Wu+jR4ECvPW1rY2ThYQ/I2Z97irnhmFnuepIM/gGviXN2OG1+xSBGjJVN4i9chnhxTLHKc+d uqq01tD/OGItoH63MQekOPhsymUyd95Ci01nM18pTzZDghYal47Ex/j+rlM8AaBmtSbTNGN/ rTFGUMvregVqrnnrYfs/LlooxHtTAbpY19e/sZX5b9EWdsa6k074bt6ew3TQ9xm7/4grV06H vc1b0I79Rk8vPslXh9Wh6qS4+OLkvFWnwTUachInxlD4E0wdK33XaaSxarFSmnYcVrsW2Izy gPoRMYgB5oUPtmUE8F/WfhWZ0Z3P9cKXx3EP6Z25PN3UJFXr+kZpVow65bx0MFIu/N5ygbHX sQ482CQwgzg5rr3arxXB9AknHC753jSJeld1oAsy1J+hmY7iSGxjoZeL4Yoq8IINNeq1QbH0 vo9esK4hmUi2fXIg/GKoramWJ6DjiObuHOJvXkiV9QS7GVnlHq1Z2/HGN998n6nmUj7i70lk a1XiJ3LFtAcxqsnjc1hXdi2yuOnbHRhpVBIuCEsj3EKtp5zTVkAK77c5LOIIRoij9ACUaT6x D6r93jbuw5HbSHP3aW3P/jkQ3kgZXPaa6890kPe3eRqyf9iOYpcAWu71TSqQldaOZ1Nl2Ttk 1JY8UQARAQABwsFfBBgBAgAJBQJUrRohAhsMAAoJEPqg+cTm90wjqucP/3di/s4HIltDHvte Css8JYINdfkdfkt5ub75YLoBa5blPIMJ/E5HMiQ90dAnIlg0ZQ39AOJ0agyg7vNSi199Y1Kn 3TSpAAiTo5V8ry8CuyqJ+0t4czr5PUr6P+8ggFAXMSn5NbZPQHZRods3GFtO5pq/6gwWxBiO 6VcLEqeEdz+ZzusISIPtuz56biaeR5+lh3FVITvXzVHY/7mXeKKb/HKy4gwHmNnWAqrELjg1 vtTtJJnPyrTUE6vYzO1pfNs7ynfcylV5q6oloLNwChQweMfFtDHOiOv6wweLav43+28WAElD Saw618yT8fFSWYGl9tUmADoRgHfFrcHrcZ0v/27C4Gh/bbESUJqm4ik1wZPrEjIwSZJFAm5k 2wTlRMnuxT7cGZVYChG2awk5wbYqofwivGcpY1X+HSGivYXEGQmvPSdONFbgr1FUDXKgcsbw qsxaBtx407fDL8ohnWnsjqB0X6sWUjllm8Afxabwr2WCzdRut6/HIXcrFHIFjzHokIqartiO 0J0tmANHEACjmDgF6E1XlUi0SnNXDV0Us2z4843kEocj8Z6zFNQkuMy0ArQbuxVG0i5jaRaA nI6nLB+ouU4UJNUnzrVnVr2sQuruMIIb9u7DVTodwfkrEVw0aoiSW3D7CTATZcBihOo8NZjm hze1s8uad9n9PQF+gigV Subject: SVG rendering issues Message-ID: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> Date: Sat, 25 Apr 2020 08:19:01 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2607:f8b0:4864:20::730; envelope-from=cpitclaudel@gmail.com; helo=mail-qk1-x730.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2607:f8b0:4864:20::730 X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hi all, As discussed on the mailing list, a number of issues currently exist with our SVG rendering implementation. I have tried to summarize the ones I'm aware of in the following example. (with-current-buffer (get-buffer-create "*svg bugs*") (erase-buffer) (require 'face-remap) (setq text-scale-mode-amount 10) (text-scale-mode) (let ((svg (svg-create 16 16))) (svg-ellipse svg 8 8 4 4) (insert "Text: ") (print (svg-image svg :ascent 100)) (insert-image (svg-image svg :ascent 100)) (insert-image (svg-image svg :scale 5.0 :ascent 'center :foreground "red" :background "darkgreen")) (add-text-properties (point-min) (point-max) '(face (:foreground "orange" :background "purple") mouse-face '(:foreground "purple" :background "orange")))) (pop-to-buffer (current-buffer))) The issues: 1. Manually scaling an image, as is done for the second image, doesn't re-render the svg: is scales the bitmap-rendered version of it, causing blurriness. 2. The SVG images don't inherit the background of the current face; instead, they inherit the background of the default face. 3. The SVG images don't inherit the foreground of the current face; instead, they use a black foreground. 4. The :foreground keyword has no effect on svg images. 5. The images are not scaled with the text: changing text-scale-mode-amount doesn't change the size of the images. For 1, 2, 3, and 4, the expected behavior is easy to define: - For 1, the image should be scaled before being rasterized. - For 2 and 3, the image should inherit the characteristics of the current face, and be re-rendered if that face changes (e.g. when mouse-face applies, which is important for buttons) - For 4, the :foreground property should be respected For 5, it's a bit trickier. One option would be to accept a float-valued :height specification and treat that as a multiple of the current font size. A partial workaround for 2 is to add an explicit :background, but it doesn't help with face changes, such as applying a mouse-face. For 1 and 5 it can be enough to set the size in the SVG and add hooks, but that only works easily for SVGs created within emacs. For 3 and 4, I don't know of a workaround except modifying the SVG. Cheers, Clément. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 10:34:56 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 14:34:56 +0000 Received: from localhost ([127.0.0.1]:60189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSLtP-0004FN-IG for submit@debbugs.gnu.org; Sat, 25 Apr 2020 10:34:56 -0400 Received: from mail-ot1-f50.google.com ([209.85.210.50]:33031) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSLtN-0004FA-7S for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 10:34:53 -0400 Received: by mail-ot1-f50.google.com with SMTP id j26so17831219ots.0 for <40845@debbugs.gnu.org>; Sat, 25 Apr 2020 07:34:53 -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; bh=9C+GcuOlPAZVdI6pFkOhtV84qd3TemtpeuRM+QY4unU=; b=NFMn/QbVWdGEJ6NpTtncSQU7CBEImUVmDk+cCHDl22gXNt9GoDaTW16sDDh+Poj7qv URBOgkGXOXrPu3pfw+sfw/BTMuu8VX76op+0sKmlpIbi36a3X0aULqTzn516pfW2SK+X jY7g3ndk8SixuP6tgj0NDiIYxU0l+kayKmt57I726VtpdkqQPYiphpn7Pp7ZvT4iem0G LZvwlCbZwYD2do38WvE1MZGIF7M7IdcarjA0ErQXV2W4BVjlDaMKSccumyJ1k3DOMxm7 rmIhbaioj+RAoX+JNbu36mQuujeZxpOGEC/ERZVwvdWi3OiT6ug0eStFVcxuRMFebxQk W+Jw== 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; bh=9C+GcuOlPAZVdI6pFkOhtV84qd3TemtpeuRM+QY4unU=; b=a/HrEHaW/2FNWZfKaQL0QKoiAdiZy3TQToJu9mFTC5ZUX56YjD2/fjdxtA7QMahIlI zz9dh7YRpF1jTUMnX+tnAshtROtjq8vt1r6FYwKaQw+SPvDvluYQqaI+0YhxN/2xvaZf e6AhI3Qs5EvvbdD0gIFx/HaMeFb0HIe8t9ml3QfI3BvZt6KKPUFBUSIka8sIWBlFHijp RCiIqJmIiVyy1QVDWObNAA6F1WKLOjDVRNMHcpz+xGivwzeKGTwSziL6Pm7sE4uV2TmG ct3EMnaTM861VktRE88C1v7JSRTZNFFf9FA1d+UgX0xSaeeOF3gd/jg3SKsvgENBRORm 11Ww== X-Gm-Message-State: AGi0PubaPyxhOVqHgHaW9/o7/tDsBd3ROKu46hQNUt2btVnaXvx5oazl TrnmZF7KWj5AWdp0LdU2/MtwmBKn2r5lVNkdi+Y= X-Google-Smtp-Source: APiQypLZ/JsICPIPAwBSk3+5SzfXTbBHymrd2mN5gFv9S7QsTVJUvA0/s84DNuDgHmoIlFhGMklIm0XWCgmosQFvRGc= X-Received: by 2002:aca:ec87:: with SMTP id k129mr11036559oih.44.1587825287553; Sat, 25 Apr 2020 07:34:47 -0700 (PDT) MIME-Version: 1.0 References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> In-Reply-To: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> From: Pip Cet Date: Sat, 25 Apr 2020 14:34:11 +0000 Message-ID: Subject: Re: bug#40845: SVG rendering issues To: =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= Content-Type: multipart/mixed; boundary="0000000000003afedd05a41e62fe" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 Cc: 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000003afedd05a41e62fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 25, 2020 at 12:20 PM Cl=C3=A9ment Pit-Claudel wrote: > > Hi all, > > As discussed on the mailing list, a number of issues currently exist with= our SVG rendering implementation. I have tried to summarize the ones I'm = aware of in the following example. > > (with-current-buffer (get-buffer-create "*svg bugs*") > (erase-buffer) > (require 'face-remap) > (setq text-scale-mode-amount 10) > (text-scale-mode) > (let ((svg (svg-create 16 16))) > (svg-ellipse svg 8 8 4 4) > (insert "Text: ") > (print (svg-image svg :ascent 100)) > (insert-image (svg-image svg :ascent 100)) > (insert-image (svg-image svg :scale 5.0 :ascent 'center :foreground "= red" :background "darkgreen")) > (add-text-properties > (point-min) (point-max) > '(face (:foreground "orange" :background "purple") > mouse-face '(:foreground "purple" :background "orange")))) > (pop-to-buffer (current-buffer))) > > The issues: > > 1. Manually scaling an image, as is done for the second image, doesn't re= -render the svg: is scales the bitmap-rendered version of it, causing blurr= iness. > 2. The SVG images don't inherit the background of the current face; inste= ad, they inherit the background of the default face. > 3. The SVG images don't inherit the foreground of the current face; inste= ad, they use a black foreground. > 4. The :foreground keyword has no effect on svg images. > 5. The images are not scaled with the text: changing text-scale-mode-amou= nt doesn't change the size of the images. I would like to add 6. When the cursor is over an SVG image, it is displayed with a box around it rather than with inverted video as characters are. I've played around a while ago in an attempt to fix these issues, and be able to define "character-like" SVG glyphs. My approach was to add a display spec of the form (gen FN), which calls FN with the current face parameters as arguments whenever redisplaying the spec, then uses the return value (an image spec) as the actual spec to be displayed. It's probably quite slow, but (as of June last) it works, even when displaying the same buffer twice. Calling elisp from the redisplay engine is, of course, something we don't really want to have more of, but we'd do so anyway for a `when' spec (in fact, an alternative approach to get this working with old Emacsen was to abuse a `when' spec to set the image spec correctly). The attached patch, IIRC, is the main part. As you can see, it leaves most of the work to the Lisp side of things. It can fix all issues mentioned above by modifying the SVG as required. Also, IIRC, 3 is an rsvg issue. --0000000000003afedd05a41e62fe Content-Type: text/x-patch; charset="US-ASCII"; name="gen.diff" Content-Disposition: attachment; filename="gen.diff" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_k9fq3vr70 Y29tbWl0IDBhZjE4NTA0ODVmM2FkMTUxOWU1MmRlMmIxNjk0ZWZhOTIyOTE3ZjQKQXV0aG9yOiBQ aXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiAgIFNhdCBKdW4gMjIgMDc6NTM6MjggMjAx OSArMDAwMAoKICAgIHNuYXBzaG90CgpkaWZmIC0tZ2l0IGEvc3JjL2NhbGxpbnQuYyBiL3NyYy9j YWxsaW50LmMKaW5kZXggODhhM2MzNDhkMC4uNmYyZTVkNTA2NiAxMDA2NDQKLS0tIGEvc3JjL2Nh bGxpbnQuYworKysgYi9zcmMvY2FsbGludC5jCkBAIC04MjQsNiArODI0LDcgQEAgc3ltc19vZl9j YWxsaW50ICh2b2lkKQogICBERUZTWU0gKFFsZXQsICJsZXQiKTsKICAgREVGU1lNIChRaWYsICJp ZiIpOwogICBERUZTWU0gKFF3aGVuLCAid2hlbiIpOworICBERUZTWU0gKFFnZW4sICJnZW4iKTsK ICAgREVGU1lNIChRbGV0eCwgImxldCoiKTsKICAgREVGU1lNIChRc2F2ZV9leGN1cnNpb24sICJz YXZlLWV4Y3Vyc2lvbiIpOwogICBERUZTWU0gKFFwcm9nbiwgInByb2duIik7CmRpZmYgLS1naXQg YS9zcmMveGRpc3AuYyBiL3NyYy94ZGlzcC5jCmluZGV4IDU2OTlhYWM2MWIuLjcxN2ZiMzBlYzMg MTAwNjQ0Ci0tLSBhL3NyYy94ZGlzcC5jCisrKyBiL3NyYy94ZGlzcC5jCkBAIC0yNzI4LDcgKzI3 MjgsNiBAQCBzYWZlX2NhbGwyIChMaXNwX09iamVjdCBmbiwgTGlzcF9PYmplY3QgYXJnMSwgTGlz cF9PYmplY3QgYXJnMikKICAgcmV0dXJuIHNhZmVfY2FsbCAoMywgZm4sIGFyZzEsIGFyZzIpOwog fQogCi0KIAwKIC8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKgogCQkJICAgICAgRGVidWdnaW5nCkBAIC00ODkzLDYg KzQ4OTIsNyBAQCBoYW5kbGVfZGlzcGxheV9zcGVjIChzdHJ1Y3QgaXQgKml0LCBMaXNwX09iamVj dCBzcGVjLCBMaXNwX09iamVjdCBvYmplY3QsCiAjZW5kaWYKICAgICAgICYmICFFUSAoWENBUiAo c3BlYyksIFFzcGFjZSkKICAgICAgICYmICFFUSAoWENBUiAoc3BlYyksIFF3aGVuKQorICAgICAg JiYgIUVRIChYQ0FSIChzcGVjKSwgUWdlbikKICAgICAgICYmICFFUSAoWENBUiAoc3BlYyksIFFz bGljZSkKICAgICAgICYmICFFUSAoWENBUiAoc3BlYyksIFFzcGFjZV93aWR0aCkKICAgICAgICYm ICFFUSAoWENBUiAoc3BlYyksIFFoZWlnaHQpCkBAIC00OTkxLDYgKzQ5OTEsOCBAQCBkaXNwbGF5 X3Byb3BfZW5kIChzdHJ1Y3QgaXQgKml0LCBMaXNwX09iamVjdCBvYmplY3QsIHN0cnVjdCB0ZXh0 X3BvcyBzdGFydF9wb3MpCiAgICBWYWx1ZSBpcyBub24temVybyBpZiBzb21ldGhpbmcgd2FzIGZv dW5kIHdoaWNoIHJlcGxhY2VzIHRoZSBkaXNwbGF5CiAgICBvZiBidWZmZXIgb3Igc3RyaW5nIHRl eHQuICAqLwogCitleHRlcm4gTGlzcF9PYmplY3QgKmxmYWNlX2lkX3RvX25hbWU7CisKIHN0YXRp YyBpbnQKIGhhbmRsZV9zaW5nbGVfZGlzcGxheV9zcGVjIChzdHJ1Y3QgaXQgKml0LCBMaXNwX09i amVjdCBzcGVjLCBMaXNwX09iamVjdCBvYmplY3QsCiAJCQkgICAgTGlzcF9PYmplY3Qgb3Zlcmxh eSwgc3RydWN0IHRleHRfcG9zICpwb3NpdGlvbiwKQEAgLTUwMDIsNiArNTAwNCw0NiBAQCBoYW5k bGVfc2luZ2xlX2Rpc3BsYXlfc3BlYyAoc3RydWN0IGl0ICppdCwgTGlzcF9PYmplY3Qgc3BlYywg TGlzcF9PYmplY3Qgb2JqZWN0LAogICBzdHJ1Y3QgdGV4dF9wb3Mgc3RhcnRfcG9zID0gKnBvc2l0 aW9uOwogICB2b2lkICppdGRhdGEgPSBOVUxMOwogCisgIGlmIChpdCAhPSBOVUxMICYmCisgICAg ICBDT05TUCAoc3BlYykgJiYKKyAgICAgIEVRIChYQ0FSIChzcGVjKSwgUWdlbikpCisgICAgewor ICAgICAgc3BlYyA9IFhDRFIgKHNwZWMpOworICAgICAgaWYgKCFDT05TUCAoc3BlYykpCisJcmV0 dXJuIDA7CisgICAgICBMaXNwX09iamVjdCBnZW4gPSBYQ0FSIChzcGVjKTsKKyAgICAgIHN0cnVj dCBmYWNlICpmYWNlID0gRkFDRV9GUk9NX0lEIChpdC0+ZiwgaXQtPmZhY2VfaWQpOworICAgICAg TGlzcF9PYmplY3QgbGZhY2UgPSBRbmlsOworICAgICAgTGlzcF9PYmplY3QgcHJvcHNbXSA9IHsK KwlRQ3R5cGUsCisJUUNmYW1pbHksCisJUUNmb3VuZHJ5LAorCVFDd2lkdGgsCisJUUNoZWlnaHQs CisJUUN3ZWlnaHQsCisJUUNzbGFudCwKKwlRQ3VuZGVybGluZSwKKwlRQ2ludmVyc2VfdmlkZW8s CisJUUNmb3JlZ3JvdW5kLAorCVFDYmFja2dyb3VuZCwKKwlRQ3N0aXBwbGUsCisJUUNvdmVybGlu ZSwKKwlRQ3N0cmlrZV90aHJvdWdoLAorCVFDYm94LAorCVFDZm9udCwKKwlRQ2luaGVyaXQsCisJ UUNmb250c2V0LAorCVFDZGlzdGFudF9mb3JlZ3JvdW5kLAorICAgICAgfTsKKyAgICAgIGZvciAo aW50IGkgPSAwOyBpIDwgTEZBQ0VfVkVDVE9SX1NJWkU7IGkrKykKKwlsZmFjZSA9IEZjb25zIChG Y29ucyAocHJvcHNbaV0sIGZhY2UtPmxmYWNlW2ldKSwKKwkJICAgICAgIGxmYWNlKTsKKyAgICAg IExpc3BfT2JqZWN0IGZvbnQgPSBRbmlsOworICAgICAgWFNFVEZPTlQgKGZvbnQsIGZhY2UtPmZv bnQpOworICAgICAgbGZhY2UgPSBGY29ucyAoRmNvbnMgKFFDZm9udCwgZm9udCksIGxmYWNlKTsK KyAgICAgIHNwZWMgPSBzYWZlX2NhbGwxIChnZW4sIGxmYWNlKTsKKyAgICB9CisKICAgLyogSWYg U1BFQyBpcyBhIGxpc3Qgb2YgdGhlIGZvcm0gYCh3aGVuIEZPUk0gLiBWQUxVRSknLCBldmFsdWF0 ZSBGT1JNLgogICAgICBJZiB0aGUgcmVzdWx0IGlzIG5vbi1uaWwsIHVzZSBWQUxVRSBpbnN0ZWFk IG9mIFNQRUMuICAqLwogICBmb3JtID0gUXQ7CmRpZmYgLS1naXQgYS9zcmMveGZhY2VzLmMgYi9z cmMveGZhY2VzLmMKaW5kZXggMDEyY2M5NjQ3MC4uNDc0NTNjMmIzMSAxMDA2NDQKLS0tIGEvc3Jj L3hmYWNlcy5jCisrKyBiL3NyYy94ZmFjZXMuYwpAQCAtMjk0LDcgKzI5NCw3IEBAICNkZWZpbmUg RkFDRV9DQUNIRV9CVUNLRVRTX1NJWkUgMTAwMQogCiAvKiBBIHZlY3RvciBtYXBwaW5nIExpc3Ag ZmFjZSBJZCdzIHRvIGZhY2UgbmFtZXMuICAqLwogCi1zdGF0aWMgTGlzcF9PYmplY3QgKmxmYWNl X2lkX3RvX25hbWU7CitMaXNwX09iamVjdCAqbGZhY2VfaWRfdG9fbmFtZTsKIHN0YXRpYyBwdHJk aWZmX3QgbGZhY2VfaWRfdG9fbmFtZV9zaXplOwogCiAjaWZkZWYgSEFWRV9XSU5ET1dfU1lTVEVN Cgo= --0000000000003afedd05a41e62fe-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 11:31:00 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 15:31:00 +0000 Received: from localhost ([127.0.0.1]:60228 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSMlg-0005cH-KK for submit@debbugs.gnu.org; Sat, 25 Apr 2020 11:31:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSMle-0005c4-Sq for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 11:30:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56279) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSMlW-0002QG-JW; Sat, 25 Apr 2020 11:30:53 -0400 Received: from [176.228.60.248] (port=4779 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSMlV-0002Kd-C5; Sat, 25 Apr 2020 11:30:50 -0400 Date: Sat, 25 Apr 2020 18:30:39 +0300 Message-Id: <83o8rf7fc0.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Sat, 25 Apr 2020 14:34:11 +0000) Subject: Re: bug#40845: SVG rendering issues References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Pip Cet > Date: Sat, 25 Apr 2020 14:34:11 +0000 > Cc: 40845@debbugs.gnu.org > > 6. When the cursor is over an SVG image, it is displayed with a box > around it rather than with inverted video as characters are. > > I've played around a while ago in an attempt to fix these issues, and > be able to define "character-like" SVG glyphs. My approach was to add > a display spec of the form (gen FN), which calls FN with the current > face parameters as arguments whenever redisplaying the spec, then uses > the return value (an image spec) as the actual spec to be displayed. I don't think I understand why we need to call a function for this. This is about displaying an image with a specific background color, isn't it? From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 11:46:46 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 15:46:47 +0000 Received: from localhost ([127.0.0.1]:60232 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSN0v-0005y4-WC for submit@debbugs.gnu.org; Sat, 25 Apr 2020 11:46:46 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50238) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSN0g-0005xX-EB for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 11:46:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56656) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSN0b-0003ZT-1E; Sat, 25 Apr 2020 11:46:25 -0400 Received: from [176.228.60.248] (port=1769 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSN0Z-00043z-E3; Sat, 25 Apr 2020 11:46:24 -0400 Date: Sat, 25 Apr 2020 18:46:10 +0300 Message-Id: <83mu6z7em5.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Sat, 25 Apr 2020 14:34:11 +0000) Subject: Re: bug#40845: SVG rendering issues References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Pip Cet > Date: Sat, 25 Apr 2020 14:34:11 +0000 > Cc: 40845@debbugs.gnu.org > > > 3. The SVG images don't inherit the foreground of the current face; instead, they use a black foreground. > > Also, IIRC, 3 is an rsvg issue. I don't think I understand what item 3 is complaining about. If I visit etc/images/splash.svg, it gets the background color of the default face. So is the complaint that it takes the background from the default face instead of the current face? That should be easy to fix, I think, as this code in svg_load_image shows: Emacs_Color background; Lisp_Object specified_bg = image_spec_value (img->spec, QCbackground, NULL); if (!STRINGP (specified_bg) || !FRAME_TERMINAL (f)->defined_color_hook (f, SSDATA (specified_bg), &background, false, false)) FRAME_TERMINAL (f)->query_frame_background_color (f, &background); From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 11:49:23 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 15:49:23 +0000 Received: from localhost ([127.0.0.1]:60236 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSN3T-00061y-3I for submit@debbugs.gnu.org; Sat, 25 Apr 2020 11:49:23 -0400 Received: from mail-ot1-f45.google.com ([209.85.210.45]:46901) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSN3R-00061k-9L for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 11:49:21 -0400 Received: by mail-ot1-f45.google.com with SMTP id z25so18030529otq.13 for <40845@debbugs.gnu.org>; Sat, 25 Apr 2020 08:49:21 -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; bh=bJvd/DkTWCwUK5NopjZvvwUQIFLW88xKvSXqdp15f5U=; b=b5Lqzi7E9PIrO0mhvntGO7UuNg3T0DzPlUrer6au9yek+2rHz8SfFhyGpxRNi2gTl4 XdzqHci+8N4WK+lLfw/vy02Nnf8DvJY47mUiQ82BluaH7VYxEJkFccq/Tto1kIu1+PKq nBVNQ3prL2zNj+fQsEEmgGTtm68MOJUgGJltGiLa8i3OH7G+BXB5J7srevx0JQFAE/4C AodJS7LKz6+owtwKOZDCsXQxDKPwqZ5eLYx/15G9kj9hlSr56+IC/A4KzjEgf+6GyZkz 9c5nQ1O/639/GLFcS+LgBU5VaxpjBR/+v/rd3/UYGUnUGXO9tczFnUxm9qYlrSMP44B+ DW9w== 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; bh=bJvd/DkTWCwUK5NopjZvvwUQIFLW88xKvSXqdp15f5U=; b=uPNL4ZWPkVyrXBP2vGUnxuAt65MvrFt16O0TgYHUK7WxqSMCJyKkHO8vH4XsoIEIb9 8fgmbhHnugGVA2hcN1MJS6vo76B9riDBtc/NQlW6Qx81KZitgSkVqKRTViWXCxL5VIsV jFXjSb25QHwnTeFBUER8ABxS9KemJYIJ6wAjwqSDCT8GVzYXduAR70SOnxot9ZAoXfwM icfbNYcF6QYNBGgOGeDum7txCPdiIs8ub3bGh7i4AO1oeouPMENG/pE6TF/9/jQkVSmW NoJvamv6ykEK85glPmiIfCNJ8Aj6LcUEuPjdpsg/P3CN9cz+beymW/LurmvO7kfm2nZC pScA== X-Gm-Message-State: AGi0PubU6WIej9wzh96DTjsfmxEyjyRmEpDI4HG7nh0nFd5dTPrGa2pJ 3W9kCHTYNJbJboLkrnxPdcAihwHtei2cL/tw8z4= X-Google-Smtp-Source: APiQypLyccv3wg/+RiHzGXD43Ni9hWkAhAmhrSXyhj6WCj+oRSScM0UDaCtBV0aYPTgh21jRBYwWXCVAd986RHHjERs= X-Received: by 2002:a9d:5a04:: with SMTP id v4mr12845188oth.292.1587829755672; Sat, 25 Apr 2020 08:49:15 -0700 (PDT) MIME-Version: 1.0 References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83o8rf7fc0.fsf@gnu.org> In-Reply-To: <83o8rf7fc0.fsf@gnu.org> From: Pip Cet Date: Sat, 25 Apr 2020 15:48:39 +0000 Message-ID: Subject: Re: bug#40845: SVG rendering issues To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Apr 25, 2020 at 3:30 PM Eli Zaretskii wrote: > > I've played around a while ago in an attempt to fix these issues, and > > be able to define "character-like" SVG glyphs. My approach was to add > > a display spec of the form (gen FN), which calls FN with the current > > face parameters as arguments whenever redisplaying the spec, then uses > > the return value (an image spec) as the actual spec to be displayed. > > I don't think I understand why we need to call a function for this. > This is about displaying an image with a specific background color, > isn't it? Even if the problem were just the choice of background color, that would require significant and non-trivial changes for some cases: for example, an emoji might have to choose foreground colors that provide sufficient contrast to the background color, and antialiasing and sub-pixel rendering would also need to be taken into account. But, at least for me, it's not: I want to be able to define something that behaves like a character, including displaying differently in different frames and depending on different face parameters such as weight, slant, and RTL-ness. I don't really see a way of doing that satisfactorily without invoking user code outside of the display engine/image backend code. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 12:11:06 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 16:11:06 +0000 Received: from localhost ([127.0.0.1]:60244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSNOU-0006XG-6b for submit@debbugs.gnu.org; Sat, 25 Apr 2020 12:11:06 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53370) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSNOP-0006Wk-Hs for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 12:11:04 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57085) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSNOJ-00040l-9y; Sat, 25 Apr 2020 12:10:55 -0400 Received: from [176.228.60.248] (port=3255 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSNOI-0007nF-II; Sat, 25 Apr 2020 12:10:55 -0400 Date: Sat, 25 Apr 2020 19:10:44 +0300 Message-Id: <83lfmj7dh7.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Sat, 25 Apr 2020 15:48:39 +0000) Subject: Re: bug#40845: SVG rendering issues References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83o8rf7fc0.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Pip Cet > Date: Sat, 25 Apr 2020 15:48:39 +0000 > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org > > On Sat, Apr 25, 2020 at 3:30 PM Eli Zaretskii wrote: > > > > I don't think I understand why we need to call a function for this. > > This is about displaying an image with a specific background color, > > isn't it? > > Even if the problem were just the choice of background color, that > would require significant and non-trivial changes for some cases: for > example, an emoji might have to choose foreground colors that provide > sufficient contrast to the background color, and antialiasing and > sub-pixel rendering would also need to be taken into account. We are talking about displaying images, not characters, right? So why are emoji relevant to this? > I want to be able to define something that behaves like a character, > including displaying differently in different frames and depending > on different face parameters such as weight, slant, and RTL-ness. All of that is possible with images, so I don't think I understand why we need to handle this as a character. This very bug report was filed because I said we shouldn't use characters and fonts for these purposes, so let's not discuss that alternative, please, at least not here. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 12:42:18 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 16:42:18 +0000 Received: from localhost ([127.0.0.1]:60255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSNsf-0007H3-8Z for submit@debbugs.gnu.org; Sat, 25 Apr 2020 12:42:18 -0400 Received: from mail-qt1-f172.google.com ([209.85.160.172]:36819) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSNsd-0007Go-FE for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 12:42:15 -0400 Received: by mail-qt1-f172.google.com with SMTP id w29so10670771qtv.3 for <40845@debbugs.gnu.org>; Sat, 25 Apr 2020 09:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2Y6pRtfraEy0Iv+nGrZyMTuc6CMq5aW3Xiap+lpImck=; b=WjMOQctQiMFkF3C49QiU2HVpoTcL4gapAKqIA+LrzReET+wH3dMQHUmc6beOw3r6Wj h9wR8mcoAHwwwptES/BsA49X9fPTszjR7cpzXf68mcFhU9r/IDLG5VXUOSwFmYQdYGG3 WwfuEwBqab11q4cvSLVaJV9ppjyz3Lx/yi092trRki0tJdkwE13NpHBEXuT+RwE189gi TM2w4/li+NQWhcfpSQWo9eJJQZRU9OwCDlyqbPjSVdLLBTe3+70QO9NO5EXc0z054Oom 1FwT9bDyqAWdWqOTDV/GvwL80tMeci2mNgf3UKT333nYwiugePldS3YpAyagE5aGYl5n cfgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2Y6pRtfraEy0Iv+nGrZyMTuc6CMq5aW3Xiap+lpImck=; b=oYwhw1skKOVbCcyzU4A7YWUok8IcjY/5YHC7XttwoyGNplxNdGO/jnoenjo8IyHJg7 qFUP1vxxCVAXBLAvK8HZdCgyLzCNZ3W+buXCY4TBm03Hh5ItvAElbj+w7OmIuPU7lPOQ pqP6/3kslyTpbD8YkNPwXk/doavdKte11EYT3sb6HfWk4DIft6Ah3trm7GvICJPEr2wl MtE5QLiGHlq6N2w+/461dape6BHuZG1BpkfclH0EQc58jY9Fqg0coo6dv5RY07VB/RUo hNBGdhldKKuhnMUPEsgjZcSOahcEdFjPUYnuKOBbe8g7TjbSwnF1ylzJYzBeN6KbBk++ IW/Q== X-Gm-Message-State: AGi0PuZ5otftU126rvMCNMykaP0A7O2hvJ8IiLvWXWUypJ2gHYiIIXDj AVo+mJf+bXm+WNbqja6sccHfomPLPeQ= X-Google-Smtp-Source: APiQypLUW0XwZ2++tb2v74mXww0UR7A1lMFcd6AprQAtCO4sBo8og88pjJgHXlBubjCIG7WR5YKUYA== X-Received: by 2002:ac8:3f6d:: with SMTP id w42mr14892076qtk.171.1587832929752; Sat, 25 Apr 2020 09:42:09 -0700 (PDT) Received: from ?IPv6:2601:184:4180:66e7:54d6:bfeb:aa49:9d3b? ([2601:184:4180:66e7:54d6:bfeb:aa49:9d3b]) by smtp.googlemail.com with ESMTPSA id z18sm6516016qtz.77.2020.04.25.09.42.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Apr 2020 09:42:09 -0700 (PDT) Subject: Re: bug#40845: SVG rendering issues To: Eli Zaretskii , Pip Cet References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83mu6z7em5.fsf@gnu.org> From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Message-ID: <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> Date: Sat, 25 Apr 2020 12:42:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <83mu6z7em5.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 Cc: 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 25/04/2020 11.46, Eli Zaretskii wrote: >> From: Pip Cet >> Date: Sat, 25 Apr 2020 14:34:11 +0000 >> Cc: 40845@debbugs.gnu.org >> >>> 3. The SVG images don't inherit the foreground of the current face; instead, they use a black foreground. >> >> Also, IIRC, 3 is an rsvg issue. > > I don't think I understand what item 3 is complaining about. If I > visit etc/images/splash.svg, it gets the background color of the > default face. So is the complaint that it takes the background from > the default face instead of the current face? That should be easy to > fix, I think, as this code in svg_load_image shows: That's item 2: 2. The SVG images don't inherit the background of the current face; instead, they inherit the background of the default face. and you summarized it exactly right. Item 3 is about the color of the circle that the repro draws. . It should be purple, but it's black. Clément. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 13:03:11 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 17:03:12 +0000 Received: from localhost ([127.0.0.1]:60271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSOCt-0007m5-N7 for submit@debbugs.gnu.org; Sat, 25 Apr 2020 13:03:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSOCs-0007ls-3N for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 13:03:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57905) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSOCm-000672-Pw; Sat, 25 Apr 2020 13:03:04 -0400 Received: from [176.228.60.248] (port=2702 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSOCl-00065t-Om; Sat, 25 Apr 2020 13:03:04 -0400 Date: Sat, 25 Apr 2020 20:02:53 +0300 Message-Id: <83k1237b2a.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel In-Reply-To: <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Sat, 25 Apr 2020 12:42:07 -0400) Subject: Re: bug#40845: SVG rendering issues References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 40845@debbugs.gnu.org > From: Clément Pit-Claudel > Date: Sat, 25 Apr 2020 12:42:07 -0400 > > >>> 3. The SVG images don't inherit the foreground of the current face; instead, they use a black foreground. > >> > >> Also, IIRC, 3 is an rsvg issue. > > > > I don't think I understand what item 3 is complaining about. If I > > visit etc/images/splash.svg, it gets the background color of the > > default face. So is the complaint that it takes the background from > > the default face instead of the current face? That should be easy to > > fix, I think, as this code in svg_load_image shows: > > That's item 2: > > 2. The SVG images don't inherit the background of the current face; instead, they inherit the background of the default face. > > and you summarized it exactly right. Item 3 is about the color of the circle that the repro draws. . It should be purple, but it's black. Ah, sorry. But IMO the foreground of an image shouldn't be affected by the current face's foreground. Images should come with their own colors, and be displayed like that. I think in the context of the discussion that led to this bug report it's actually almost a must: we want images with attractive colors to serve as the icons, we don't want them to be affected by whatever face happens to be nearby. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 13:24:22 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 17:24:22 +0000 Received: from localhost ([127.0.0.1]:60284 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSOXO-0008J8-88 for submit@debbugs.gnu.org; Sat, 25 Apr 2020 13:24:22 -0400 Received: from mail-qt1-f171.google.com ([209.85.160.171]:35095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSOXN-0008Ix-45 for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 13:24:21 -0400 Received: by mail-qt1-f171.google.com with SMTP id s30so10751565qth.2 for <40845@debbugs.gnu.org>; Sat, 25 Apr 2020 10:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wYtcbL8SXKmIfmTEDlJTXmKFW7tMHAXCKKZiQJu4X9w=; b=oxdnTcUQfkLlCBhbh4kKUyy8W+sPMlZfi/OGdrps4WvObcP+PErlq36Pd5u1xsU6aI UBqx81bd0IzOUmJL5xBv50rau+4bYDuDY61Na7rWEbSYHxDTp+mFZ5bK/wcRH8T4p33o ZJbW2pVIHh2gBQrYDnI5BXr84FvqfwMKhFVnTuCkNNKkLUP8+6oGNAu4zKNribtUUcU1 +NlNounSgo9d8KCFQjK7E8CR7yTqqS0lkrZxoXheiR4W8jAVxWF1BbtLj6qFGNxBifKe BP/Y/aY9Kf6kRs0eVswD0kTMmx1WoizwOJEu4Dhnt4kNI3lSYpuKkRhzv2Ka0ZN2MekG IIPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wYtcbL8SXKmIfmTEDlJTXmKFW7tMHAXCKKZiQJu4X9w=; b=bHu95TSh4hOAqvAOHEZzEy+etPzjrXzQPmg7aBdGqEDxUPefZbyTQDGzryg96O1oSv YUej95yYkB+Rgg8R2ogXqvw5L/gIkS4fN3co1F1icibBeZZhxW8uhHCJFKJJEXR6ci3x 4NBbqgIJpDs3818g/J80aawFmsWw+lUDjoUY/QI0G7Gm2VUhZ0G5dPyW8KdNNqE58oX3 UToZK0uG3YsJPiYLowodYuWrbTsFYo4PiHqWGI7U6TDKyW/kRj25yIw+tD1Y3g3Ec2V8 4gN6+Y/NDmKT3R2j5w3aCsdzhzDz1+xVJnzu3/AofvQyfLM5CvtT9eYR8FSE+mNU4L71 cX2A== X-Gm-Message-State: AGi0PuadgZqEkZLbXt4HTBhPyJVu8BSj1GLlu5bHn7eiMkoJsk2rEHwR hwMFy2qgT0Jb3wu1Fyq57CmJZU90Ums= X-Google-Smtp-Source: APiQypIibT8TT6J1yjmMB8S3X3ZjgVmSEQAT06Zj4EuObssgPtvT1XP6g7gzn1FluAKPlOZ9IfmeOg== X-Received: by 2002:ac8:34b2:: with SMTP id w47mr15545801qtb.271.1587835455590; Sat, 25 Apr 2020 10:24:15 -0700 (PDT) Received: from ?IPv6:2601:184:4180:66e7:54d6:bfeb:aa49:9d3b? ([2601:184:4180:66e7:54d6:bfeb:aa49:9d3b]) by smtp.googlemail.com with ESMTPSA id o67sm6113552qkc.2.2020.04.25.10.24.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Apr 2020 10:24:15 -0700 (PDT) Subject: Re: bug#40845: SVG rendering issues To: Eli Zaretskii References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Message-ID: Date: Sat, 25 Apr 2020 13:24:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <83k1237b2a.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 Cc: 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 25/04/2020 13.02, Eli Zaretskii wrote: > IMO the foreground of an image shouldn't be affected by the > current face's foreground. Images should come with their own colors, > and be displayed like that. I think in the context of the discussion > that led to this bug report it's actually almost a must: we want > images with attractive colors to serve as the icons, we don't want > them to be affected by whatever face happens to be nearby. Yes, of course: if an image has a foreground color, it should be respected. But it's not uncommon for SVG images to not include a foreground color, as shown in the repro. In that case, the image should use the current foreground color, I think. (of course, a :foreground keyword, if any, should take precedence; that is issue 4). From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 13:39:15 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 17:39:15 +0000 Received: from localhost ([127.0.0.1]:60297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSOln-0000E6-28 for submit@debbugs.gnu.org; Sat, 25 Apr 2020 13:39:15 -0400 Received: from mail-ot1-f53.google.com ([209.85.210.53]:42565) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSOll-0000Dr-IW for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 13:39:14 -0400 Received: by mail-ot1-f53.google.com with SMTP id m18so18459413otq.9 for <40845@debbugs.gnu.org>; Sat, 25 Apr 2020 10:39:13 -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; bh=JlLxe+Q/3LREc3vFLB076yQjhgAM4+mR0/OY0YX6/2E=; b=vGf5BjqgefxLRW3Hx7nJXGc0GzWskrAOLtEV1ANynwQucqVgtP0E3peD8kRZtTDpNo yWCYufjLRWx0f+ttMf7HLwGSizLdzIJ2mI3ZSXXsZ7g4fibKdQRX7RRxrMMufeKkLzVA QQovTy97z5IEyX08dEVvTh4ILhouVBf+EFgsQAqCVLyC3PlWOW0HUvbClHVOp4OSCwO0 5mhiltSgxAwX1KsYYvHUgFPCuh/3F4isV+ZJOsC34wJevgUG5dIaNq8e66KjyAFKqbNQ 4t4X82tWssOV0u+atmlpcmOFmp6/VbdDgsgxbX9l5gA2XW0o4h/JXeKQIPyN+JYd9XHN cbEw== 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; bh=JlLxe+Q/3LREc3vFLB076yQjhgAM4+mR0/OY0YX6/2E=; b=EDzaRCrKdtoeq7YOfSB5Hqx1KCQnhcodmKCgnXNoPEr2CvGpJh7WyE8KtHF9rD8F+d CDG1g4815x+Y/m1LSaigr+73A0EIKJ7jXgIx0kKWHW+wolxmyCuLnDH+h1H8GQPVTEZf EzTtQJegCMiF84QLZmheO5dPmU15IzyUS0WvsdxA8eC0+6HHKQ4nDmE9VMyKXx7W1+Pl 1KC5pEdYG645OeWxtD6U9QrqDmLgo6rxWMutq9o7AB/forpLho7ff6hfUyrbdbpweAz4 Ue3grxKdBslQvIK4H+bX50bnKEK1mLZh88xeXVOsqRlna6AhJRUKMKphZhH/R2B6FIBO MpSA== X-Gm-Message-State: AGi0PuZyqXSdSZiClnRPEFphrZb2HQE6Fyi57oRYZ9aEVU71uvk4MAvN 1N1fifhvie0w2GJOSR8vGkGXfRmW6lQxUCgx8r0= X-Google-Smtp-Source: APiQypJays/Xf2n2MC2RwN6cgKFHd7JDwL3+6hXQgRVuOYaMyhTAGF49M6GB97t1muba06Cys83SBwr44cWzPim7Ohc= X-Received: by 2002:a9d:23a6:: with SMTP id t35mr13442473otb.154.1587836347746; Sat, 25 Apr 2020 10:39:07 -0700 (PDT) MIME-Version: 1.0 References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83o8rf7fc0.fsf@gnu.org> <83lfmj7dh7.fsf@gnu.org> In-Reply-To: <83lfmj7dh7.fsf@gnu.org> From: Pip Cet Date: Sat, 25 Apr 2020 17:38:31 +0000 Message-ID: Subject: Re: bug#40845: SVG rendering issues To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Apr 25, 2020 at 4:10 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Sat, 25 Apr 2020 15:48:39 +0000 > > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org > > > > On Sat, Apr 25, 2020 at 3:30 PM Eli Zaretskii wrote: > > > > > > I don't think I understand why we need to call a function for this. > > > This is about displaying an image with a specific background color, > > > isn't it? > > > > Even if the problem were just the choice of background color, that > > would require significant and non-trivial changes for some cases: for > > example, an emoji might have to choose foreground colors that provide > > sufficient contrast to the background color, and antialiasing and > > sub-pixel rendering would also need to be taken into account. > > We are talking about displaying images, not characters, right? Correct: images which behave like character glyphs, but don't actually have character codepoints, and aren't implemented by fonts. > So why are emoji relevant to this? An emoji is an example of an image which needs to know face properties to blend in, or stick out, or whatever it is people who use them want to happen. The intention was not that you'd use an emoji codepoint and a font providing a character for that codepoint, which is a silly way of implementing emoji. > > I want to be able to define something that behaves like a character, > > including displaying differently in different frames and depending > > on different face parameters such as weight, slant, and RTL-ness. > > All of that is possible with images, so I don't think I understand why > we need to handle this as a character. Yes, my approach uses images, and no, it doesn't "handle this as a character". It makes the glyph's apparent behavior match that of character glyphs, while actually displaying an image spec which changes with the properties of surrounding text, etc. > This very bug report was filed > because I said we shouldn't use characters and fonts for these > purposes, so let's not discuss that alternative, please, at least not > here. No one was. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 13:47:00 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 17:47:00 +0000 Received: from localhost ([127.0.0.1]:60301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSOtH-0000Pa-Uq for submit@debbugs.gnu.org; Sat, 25 Apr 2020 13:47:00 -0400 Received: from idiocy.org ([217.169.17.33]:53556 helo=breton.holly.idiocy.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSOtG-0000PL-6T for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 13:46:58 -0400 Received: by breton.holly.idiocy.org (Postfix, from userid 501) id A38BF20224E6CF; Sat, 25 Apr 2020 18:46:51 +0100 (BST) Date: Sat, 25 Apr 2020 18:46:51 +0100 From: Alan Third To: =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200425174651.GC82687@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel , Eli Zaretskii , 40845@debbugs.gnu.org, pipcet@gmail.com References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 Cc: Eli Zaretskii , 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Apr 25, 2020 at 01:24:13PM -0400, Clément Pit-Claudel wrote: > On 25/04/2020 13.02, Eli Zaretskii wrote: > > IMO the foreground of an image shouldn't be affected by the > > current face's foreground. Images should come with their own colors, > > and be displayed like that. I think in the context of the discussion > > that led to this bug report it's actually almost a must: we want > > images with attractive colors to serve as the icons, we don't want > > them to be affected by whatever face happens to be nearby. > > Yes, of course: if an image has a foreground color, it should be > respected. But it's not uncommon for SVG images to not include a > foreground color, as shown in the repro. In that case, the image > should use the current foreground color, I think. (of course, a > :foreground keyword, if any, should take precedence; that is issue > 4). Lars fixed the foreground issue for eww by wrapping svg files in another svg. See svg--wrap-svg in shr.el (bug#37159). I think this is the only practical way to handle svg files with no foreground colour set. To do this when loading _any_ svg we’d probably have to move it into create-image or image.c. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 14:07:37 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 18:07:37 +0000 Received: from localhost ([127.0.0.1]:60319 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSPDF-0002yV-Eq for submit@debbugs.gnu.org; Sat, 25 Apr 2020 14:07:37 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55358) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSPDD-0002yJ-Ow for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 14:07:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58975) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSPD8-00048a-HA; Sat, 25 Apr 2020 14:07:30 -0400 Received: from [176.228.60.248] (port=2776 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jSPD6-0007eu-EM; Sat, 25 Apr 2020 14:07:29 -0400 Date: Sat, 25 Apr 2020 21:07:12 +0300 Message-Id: <83eesb7833.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Sat, 25 Apr 2020 17:38:31 +0000) Subject: Re: bug#40845: SVG rendering issues References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83o8rf7fc0.fsf@gnu.org> <83lfmj7dh7.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Pip Cet > Date: Sat, 25 Apr 2020 17:38:31 +0000 > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org > > Correct: images which behave like character glyphs, but don't actually > have character codepoints, and aren't implemented by fonts. > > > So why are emoji relevant to this? > > An emoji is an example of an image which needs to know face properties > to blend in, or stick out, or whatever it is people who use them want > to happen. The intention was not that you'd use an emoji codepoint and > a font providing a character for that codepoint, which is a silly way > of implementing emoji. > > > > I want to be able to define something that behaves like a character, > > > including displaying differently in different frames and depending > > > on different face parameters such as weight, slant, and RTL-ness. > > > > All of that is possible with images, so I don't think I understand why > > we need to handle this as a character. > > Yes, my approach uses images, and no, it doesn't "handle this as a > character". It makes the glyph's apparent behavior match that of > character glyphs, while actually displaying an image spec which > changes with the properties of surrounding text, etc. > > > This very bug report was filed > > because I said we shouldn't use characters and fonts for these > > purposes, so let's not discuss that alternative, please, at least not > > here. > > No one was. Then I guess I don't understand your implementation at all. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 14:08:29 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 18:08:29 +0000 Received: from localhost ([127.0.0.1]:60323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSPE4-0002zx-Pd for submit@debbugs.gnu.org; Sat, 25 Apr 2020 14:08:29 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:33987) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSPE3-0002zl-Al for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 14:08:27 -0400 Received: by mail-ot1-f65.google.com with SMTP id 72so18634598otu.1 for <40845@debbugs.gnu.org>; Sat, 25 Apr 2020 11:08:27 -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 :content-transfer-encoding; bh=BjiMFp4T6KZTOmLPqtGXc/sYOsVjU1KGCwBYw7bPGes=; b=JlKJFJEExVClINeM9fCJhqHVFbKTqG8zgLItsbAk1wd6yueRj/PdHqid+Hc9Xk2z5j Llaw16cpvIJ51H0vsr8hDQtAr/zQ/Yx99vOtVGey+6Th39OHepHqHAKVAMzQUvHpwJQC sPGkDdlZTR3p/C9LkcCwBBAWFBgS4JPgHjDt13hYIfqeQm/SDbSdjvDesZykYtfkpJdC OQcP8AGynzDBIQ9pQEKXXse69akzekM7Mm8kr8Ai+LEH/3IEr2njYqhn+hRyWob8ES7K Ke9YZjLssiXKrDp7Cy8ouBN79IgaGvCefSi6f9nB+oH8JoRwd96Z4Zft8nVZE9pGKcS7 porw== 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:content-transfer-encoding; bh=BjiMFp4T6KZTOmLPqtGXc/sYOsVjU1KGCwBYw7bPGes=; b=soxrWW4z3MjGpzbJaTV6Vdz+t5FwFZOQKyLwJudRLDb1Fdvd0L0qswZKro8cBFZVKx dR+BlZuY/pBenMx3Qajs9D1Ze+j2Un7y7JeGR2e6iXwpHcEhT3kWcyfHLJLjK3BbIpNF ssCRg51zi18+n9F14aNOFL173/6pN6vBTDIqmSXT/g/S0t+uzSFLVl58w9qrWrh2FaRl Ws9l6P3BaHSOcRdJRUzKIQf0En7pT7Y+DOrMpoaLwqW8UVVtMUSi8FXwA6cikR8r6QXA 5OrCXUb0qDG89//+laXgPs9mccLV8FosOuAYaFDSMsGAZ5KZryAfbPLzQ6XWbHYoV3If ZZQw== X-Gm-Message-State: AGi0PuZMvuxF2d9Lf8L76Mn00EWR94hWrGiZ7GvHu125nPszf31Mp4cl FHbyAzwf2Q5Ax+8yCttdxmeepD17O58UF85Ho4U= X-Google-Smtp-Source: APiQypLFgNiBPlwyBtv4s7xgqpuw5C/N0bKMNoss9/dGS61XbmTj9mTexGl/wxyLHZIcPG6f1WgPesH7AzbLBZnT6xs= X-Received: by 2002:aca:5614:: with SMTP id k20mr10936185oib.30.1587838101661; Sat, 25 Apr 2020 11:08:21 -0700 (PDT) MIME-Version: 1.0 References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> In-Reply-To: <20200425174651.GC82687@breton.holly.idiocy.org> From: Pip Cet Date: Sat, 25 Apr 2020 18:07:45 +0000 Message-ID: Subject: Re: bug#40845: SVG rendering issues To: Alan Third , =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= , Eli Zaretskii , 40845@debbugs.gnu.org, pipcet@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Apr 25, 2020 at 5:46 PM Alan Third wrote: > On Sat, Apr 25, 2020 at 01:24:13PM -0400, Cl=C3=A9ment Pit-Claudel wrote: > > Yes, of course: if an image has a foreground color, it should be > > respected. But it's not uncommon for SVG images to not include a > > foreground color, as shown in the repro. In that case, the image > > should use the current foreground color, I think. (of course, a > > :foreground keyword, if any, should take precedence; that is issue > > 4). For reference, the relevant chunk of librsvg source code is this: // https://www.w3.org/TR/SVG/color.html#ColorProperty make_property!( ComputedValues, Color, // The SVG spec allows the user agent to choose its own default for the "color" property. // We don't allow passing in an initial CSS in the public API, so we'll start with black. // // See https://bugzilla.gnome.org/show_bug.cgi?id=3D764808 for a case where this would // be useful - rendering equations with currentColor, so they take on the color of the // surrounding text. default: cssparser::RGBA::new(0, 0, 0, 0xff), inherits_automatically: true, newtype_parse: cssparser::RGBA, ); > Lars fixed the foreground issue for eww by wrapping svg files in > another svg. See svg--wrap-svg in shr.el (bug#37159). > > I think this is the only practical way to handle svg files with no > foreground colour set. To do this when loading _any_ svg we=E2=80=99d pro= bably > have to move it into create-image or image.c. I think it's a neat hack, but it's just one of the more obvious ways of working around an annoying limitation of librsvg (Ideally, we'd use a library without such a limitation by default and fall back to modifying/wrapping SVGs when using a limited library.) For applications which change glyphs' foreground colors a lot, it might be preferrable to coax rsvg into providing an alpha-only map for the foreground plus an RGBA map for the background and blend them together, and that approach would work for other image types. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 15:42:15 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 19:42:15 +0000 Received: from localhost ([127.0.0.1]:60389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSQgp-0005F2-Eu for submit@debbugs.gnu.org; Sat, 25 Apr 2020 15:42:15 -0400 Received: from mail-ot1-f50.google.com ([209.85.210.50]:44839) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSQgn-0005Ep-Vo for 40845@debbugs.gnu.org; Sat, 25 Apr 2020 15:42:14 -0400 Received: by mail-ot1-f50.google.com with SMTP id j4so18946625otr.11 for <40845@debbugs.gnu.org>; Sat, 25 Apr 2020 12:42:13 -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; bh=v/1sdJpdo+rknc/7ecZ7/L+FrfSDOUK/tGUj4XiGSDE=; b=EiVGQ2Qtz7LCWc6SfCIb75X8lqlj9RLp08r8veofLqVY2hmhBiQbTU1UY65N5gA3Hg Ux2Hhu5N88qrHf9mx02l8DxYgRjZemF2wwUst2zBNy0RiM3JVLj46p7G5PQkk6yeiQSc fevs8sYQTShuvrFgWc0AQj7KtClSTfbe4R1wlGR7Jb77rMwNR3AUu/Wv0hq+gfNZeivN jKXhcwNsEgEyTRorzlmFKmbajoA6uouaGp5fNrjqoEUB59WyUjeVEtiB6Jo+PfqDlAOk V3wHQ8v0PH631jX42fpw8b/PgUgOEXo4+GX8hsnwm2BtJFooap/Sq919ulrN+HchebtU tbCw== 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; bh=v/1sdJpdo+rknc/7ecZ7/L+FrfSDOUK/tGUj4XiGSDE=; b=Hi1kPN2DxajeivCHIZJmCMpoC4Ekg2Bm8uAU+CiaLKr1swzS9iDKXjv3Frn18/lUdh /2XA7RMSNy58167ux4Gfq795LbVVFlUFFL3QrU85spg+j61KjSiKGcAEHItsHJE7h4CZ HcVhw2/iU85qSskvat7Aili/JqGimacNg2m7v8JvMZXMXOqZy+PnFXNC4nKt8tZ6B1Ht f7xDpecnFcIF+/MmQLEWao2HA5XoSYAmmAOQujgQ03ZSYgCG4pw9jvHitNb54AmJY7Ur 1js93EkO1DmPQkbdvnRpItmFgblutCVpyR9e+AWDLZUyxU+jDWJqhGF5c3Ssw2mWZmm5 PDsg== X-Gm-Message-State: AGi0Pual9UgiXDcAJmeigSzgg+gNRQ2H1Ow3A28VqxRxlezN8zNT98Sg /CbPo7PxWjw6ZHh2Zfp/vDUn63Y97LAjzZxGlVY= X-Google-Smtp-Source: APiQypLVzRbO4h2rruY8WQh4KxR5gzuX9H+mk/Fv2B8EksbkA74+5zQp+rn11O1M9mnv+pLSvBG10TT3Kj09f17gqsY= X-Received: by 2002:a9d:5a04:: with SMTP id v4mr13496941oth.292.1587843728120; Sat, 25 Apr 2020 12:42:08 -0700 (PDT) MIME-Version: 1.0 References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83o8rf7fc0.fsf@gnu.org> <83lfmj7dh7.fsf@gnu.org> <83eesb7833.fsf@gnu.org> In-Reply-To: <83eesb7833.fsf@gnu.org> From: Pip Cet Date: Sat, 25 Apr 2020 19:41:31 +0000 Message-ID: Subject: Re: bug#40845: SVG rendering issues To: Eli Zaretskii Content-Type: multipart/mixed; boundary="0000000000005fc4d905a422ad7c" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000005fc4d905a422ad7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 25, 2020 at 6:07 PM Eli Zaretskii wrote: or these > Then I guess I don't understand your implementation at all. 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=C3=A9ment'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. 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. 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. So I moved it to Lisp: there's Lisp code which is passed the font/face properties, and returns an image spec that's appropriate for that. The attached patch actually applies to and works with master, and includes an example. It can no longer easily be demonstrated to do the right thing when the same buffer is displayed in different frames, because Emacs currently applies text scaling per buffer rather than per frame (IMHO, that's a bug). It also doesn't properly display the cursor as a block cursor when it's over the glyph, because I can no longer find the code which allowed me to tell, from Lisp, whether that was the case. And of course it doesn't use the right font metrics, because these currently aren't exposed to Lisp. But all these limitations are fixable. --0000000000005fc4d905a422ad7c Content-Type: text/x-patch; charset="US-ASCII"; name="0001-support-generated-display-specs.patch" Content-Disposition: attachment; filename="0001-support-generated-display-specs.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_k9g10frs0 RnJvbSA4ZTdhYTM4ZTA5OGJkMDQ0YTcxZmEyMGRmMTU5M2QyYjM3MzQ3ZjFjIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiBTYXQs IDI1IEFwciAyMDIwIDE4OjQxOjAyICswMDAwClN1YmplY3Q6IFtQQVRDSF0gc3VwcG9ydCBnZW5l cmF0ZWQgZGlzcGxheSBzcGVjcwoKLS0tCiBnZW5lcmF0ZWQtaW1hZ2Utc3BlY3MuZWwgfCAzMSAr KysrKysrKysrKysrKysrKysrKysrKysrKysrCiBzcmMvY2FsbGludC5jICAgICAgICAgICAgfCAg MSArCiBzcmMveGRpc3AuYyAgICAgICAgICAgICAgfCA0NCArKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrCiBzcmMveGZhY2VzLmMgICAgICAgICAgICAgfCAgMiArLQogNCBm aWxlcyBjaGFuZ2VkLCA3NyBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pCiBjcmVhdGUgbW9k ZSAxMDA2NDQgZ2VuZXJhdGVkLWltYWdlLXNwZWNzLmVsCgpkaWZmIC0tZ2l0IGEvZ2VuZXJhdGVk LWltYWdlLXNwZWNzLmVsIGIvZ2VuZXJhdGVkLWltYWdlLXNwZWNzLmVsCm5ldyBmaWxlIG1vZGUg MTAwNjQ0CmluZGV4IDAwMDAwMDAwMDAuLmI3NjRkMTk5OWQKLS0tIC9kZXYvbnVsbAorKysgYi9n ZW5lcmF0ZWQtaW1hZ2Utc3BlY3MuZWwKQEAgLTAsMCArMSwzMSBAQAorKHJlcXVpcmUgJ3N2ZykK KworKGRlZnVuIGdlbmVyYXRlLWNpcmNsZS1pbWFnZSAoYWxpc3QpCisgIChsZXQqICgodnNpemUg KGZvbnQtZ2V0IChhbGlzdC1nZXQgOmZvbnQgYWxpc3QpIDpzaXplKSkKKyAgICAgICAgIChmb3Jl Z3JvdW5kIChhcHBseSAjJ2NvbG9yLXJnYi10by1oZXggKG5jb25jIChjb2xvci1uYW1lLXRvLXJn YiAoYWxpc3QtZ2V0IDpmb3JlZ3JvdW5kIGFsaXN0KSkgKGxpc3QgMikpKSkKKyAgICAgICAgIChi YWNrZ3JvdW5kIChhcHBseSAjJ2NvbG9yLXJnYi10by1oZXggKG5jb25jIChjb2xvci1uYW1lLXRv LXJnYiAoYWxpc3QtZ2V0IDpiYWNrZ3JvdW5kIGFsaXN0KSkgKGxpc3QgMikpKSkKKyAgICAgICAg IChoc2l6ZSAoKiB2c2l6ZSAuOCkpCisgICAgICAgICAoc3ZnIChzdmctY3JlYXRlIGhzaXplIHZz aXplKSkKKyAgICAgICAgIChzdyAoKiAuMSBoc2l6ZSkpKQorICAgIChzdmctcmVjdGFuZ2xlIHN2 ZyAwIDAgaHNpemUgdnNpemUgOmZpbGwgYmFja2dyb3VuZCkKKyAgICAoc3ZnLWNpcmNsZSBzdmcg KCogaHNpemUgLjUpCisgICAgICAgICAgICAgICAgKC0gKCogLjggdnNpemUpICgqIC41IGhzaXpl KSkKKyAgICAgICAgICAgICAgICAoLSAoKiBoc2l6ZSAuNSkgc3cpCisgICAgICAgICAgICAgICAg OmZpbGwgIm5vbmUiCisgICAgICAgICAgICAgICAgOnN0cm9rZSBmb3JlZ3JvdW5kCisgICAgICAg ICAgICAgICAgOnN0cm9rZS13aWR0aCBzdykKKyAgICAoc3ZnLWxpbmUgc3ZnCisgICAgICAgICAg ICAgICgqIGhzaXplIC41KSAoLSAoKiAuOCB2c2l6ZSkgKCogLjUgaHNpemUpKQorICAgICAgICAg ICAgICAoKiBoc2l6ZSAuNSkgKC0gKCogLjggdnNpemUpIHN3KQorICAgICAgICAgICAgICA6c3Ry b2tlIGZvcmVncm91bmQKKyAgICAgICAgICAgICAgOnN0cm9rZS13aWR0aCBzdykKKyAgICAoc3Zn LWNpcmNsZSBzdmcgKCogaHNpemUgLjUpICgtICgqIC44IHZzaXplKSAoKiAoLyAyLjAgMy4wKSBo c2l6ZSkpCisgICAgICAgICAgICAgICAgc3cKKyAgICAgICAgICAgICAgICA6ZmlsbCBmb3JlZ3Jv dW5kCisgICAgICAgICAgICAgICAgOnN0cm9rZSAibm9uZSIpCisgICAgKGxldCAoKHJldCAoc3Zn LWltYWdlIHN2ZykpKQorICAgICAgKHNldGNkciByZXQgKHBsaXN0LXB1dCAoY2RyIHJldCkgOnNj YWxlIDEuMCkpCisgICAgICAoc2V0Y2RyIHJldCAocGxpc3QtcHV0IChjZHIgcmV0KSA6YXNjZW50 IDgwKSkKKyAgICAgIHJldCkpKQorCisoaW5zZXJ0IChwcm9wZXJ0aXplICIgIiAnZGlzcGxheSBg KGdlbmVyYXRlZC1zcGVjICwjJ2dlbmVyYXRlLWNpcmNsZS1pbWFnZSkpKQpkaWZmIC0tZ2l0IGEv c3JjL2NhbGxpbnQuYyBiL3NyYy9jYWxsaW50LmMKaW5kZXggZWI5MTYzNTNhMC4uMmMzNGRkZGJl NCAxMDA2NDQKLS0tIGEvc3JjL2NhbGxpbnQuYworKysgYi9zcmMvY2FsbGludC5jCkBAIC04MjYs NiArODI2LDcgQEAgc3ltc19vZl9jYWxsaW50ICh2b2lkKQogICBERUZTWU0gKFFsZXQsICJsZXQi KTsKICAgREVGU1lNIChRaWYsICJpZiIpOwogICBERUZTWU0gKFF3aGVuLCAid2hlbiIpOworICBE RUZTWU0gKFFnZW5lcmF0ZWRfc3BlYywgImdlbmVyYXRlZC1zcGVjIik7CiAgIERFRlNZTSAoUWxl dHgsICJsZXQqIik7CiAgIERFRlNZTSAoUXNhdmVfZXhjdXJzaW9uLCAic2F2ZS1leGN1cnNpb24i KTsKICAgREVGU1lNIChRcHJvZ24sICJwcm9nbiIpOwpkaWZmIC0tZ2l0IGEvc3JjL3hkaXNwLmMg Yi9zcmMveGRpc3AuYwppbmRleCAzMjU4ODkzOTU2Li5iMzQxY2JiNzM1IDEwMDY0NAotLS0gYS9z cmMveGRpc3AuYworKysgYi9zcmMveGRpc3AuYwpAQCAtNTA1MCw2ICs1MDUwLDcgQEAgaGFuZGxl X2Rpc3BsYXlfc3BlYyAoc3RydWN0IGl0ICppdCwgTGlzcF9PYmplY3Qgc3BlYywgTGlzcF9PYmpl Y3Qgb2JqZWN0LAogI2VuZGlmCiAgICAgICAmJiAhRVEgKFhDQVIgKHNwZWMpLCBRc3BhY2UpCiAg ICAgICAmJiAhRVEgKFhDQVIgKHNwZWMpLCBRd2hlbikKKyAgICAgICYmICFFUSAoWENBUiAoc3Bl YyksIFFnZW5lcmF0ZWRfc3BlYykKICAgICAgICYmICFFUSAoWENBUiAoc3BlYyksIFFzbGljZSkK ICAgICAgICYmICFFUSAoWENBUiAoc3BlYyksIFFzcGFjZV93aWR0aCkKICAgICAgICYmICFFUSAo WENBUiAoc3BlYyksIFFoZWlnaHQpCkBAIC01MTQ4LDYgKzUxNDksOCBAQCBkaXNwbGF5X3Byb3Bf ZW5kIChzdHJ1Y3QgaXQgKml0LCBMaXNwX09iamVjdCBvYmplY3QsIHN0cnVjdCB0ZXh0X3BvcyBz dGFydF9wb3MpCiAgICBWYWx1ZSBpcyBub24temVybyBpZiBzb21ldGhpbmcgd2FzIGZvdW5kIHdo aWNoIHJlcGxhY2VzIHRoZSBkaXNwbGF5CiAgICBvZiBidWZmZXIgb3Igc3RyaW5nIHRleHQuICAq LwogCitleHRlcm4gTGlzcF9PYmplY3QgKmxmYWNlX2lkX3RvX25hbWU7CisKIHN0YXRpYyBpbnQK IGhhbmRsZV9zaW5nbGVfZGlzcGxheV9zcGVjIChzdHJ1Y3QgaXQgKml0LCBMaXNwX09iamVjdCBz cGVjLCBMaXNwX09iamVjdCBvYmplY3QsCiAJCQkgICAgTGlzcF9PYmplY3Qgb3ZlcmxheSwgc3Ry dWN0IHRleHRfcG9zICpwb3NpdGlvbiwKQEAgLTUxNTksNiArNTE2Miw0NyBAQCBoYW5kbGVfc2lu Z2xlX2Rpc3BsYXlfc3BlYyAoc3RydWN0IGl0ICppdCwgTGlzcF9PYmplY3Qgc3BlYywgTGlzcF9P YmplY3Qgb2JqZWN0LAogICBzdHJ1Y3QgdGV4dF9wb3Mgc3RhcnRfcG9zID0gKnBvc2l0aW9uOwog ICB2b2lkICppdGRhdGEgPSBOVUxMOwogCisgIGlmIChpdCAhPSBOVUxMICYmCisgICAgICBDT05T UCAoc3BlYykgJiYKKyAgICAgIEVRIChYQ0FSIChzcGVjKSwgUWdlbmVyYXRlZF9zcGVjKSkKKyAg ICB7CisgICAgICBzcGVjID0gWENEUiAoc3BlYyk7CisgICAgICBpZiAoIUNPTlNQIChzcGVjKSkK KwlyZXR1cm4gMDsKKyAgICAgIExpc3BfT2JqZWN0IGdlbiA9IFhDQVIgKHNwZWMpOworICAgICAg c3RydWN0IGZhY2UgKmZhY2UgPSBGQUNFX0ZST01fSUQgKGl0LT5mLCBpdC0+ZmFjZV9pZCk7Cisg ICAgICBMaXNwX09iamVjdCBsZmFjZSA9IFFuaWw7CisgICAgICBMaXNwX09iamVjdCBwcm9wc1td ID0geworCVFDdHlwZSwKKwlRQ2ZhbWlseSwKKwlRQ2ZvdW5kcnksCisJUUN3aWR0aCwKKwlRQ2hl aWdodCwKKwlRQ3dlaWdodCwKKwlRQ3NsYW50LAorCVFDdW5kZXJsaW5lLAorCVFDaW52ZXJzZV92 aWRlbywKKwlRQ2ZvcmVncm91bmQsCisJUUNiYWNrZ3JvdW5kLAorCVFDc3RpcHBsZSwKKwlRQ292 ZXJsaW5lLAorCVFDc3RyaWtlX3Rocm91Z2gsCisJUUNib3gsCisJUUNmb250LAorCVFDaW5oZXJp dCwKKwlRQ2ZvbnRzZXQsCisJUUNkaXN0YW50X2ZvcmVncm91bmQsCisJUUNleHRlbmQsCisgICAg ICB9OworICAgICAgZm9yIChpbnQgaSA9IDA7IGkgPCBMRkFDRV9WRUNUT1JfU0laRTsgaSsrKQor CWxmYWNlID0gRmNvbnMgKEZjb25zIChwcm9wc1tpXSwgZmFjZS0+bGZhY2VbaV0pLAorCQkgICAg ICAgbGZhY2UpOworICAgICAgTGlzcF9PYmplY3QgZm9udCA9IFFuaWw7CisgICAgICBYU0VURk9O VCAoZm9udCwgZmFjZS0+Zm9udCk7CisgICAgICBsZmFjZSA9IEZjb25zIChGY29ucyAoUUNmb250 LCBmb250KSwgbGZhY2UpOworICAgICAgc3BlYyA9IHNhZmVfY2FsbDEgKGdlbiwgbGZhY2UpOwor ICAgIH0KKwogICAvKiBJZiBTUEVDIGlzIGEgbGlzdCBvZiB0aGUgZm9ybSBgKHdoZW4gRk9STSAu IFZBTFVFKScsIGV2YWx1YXRlIEZPUk0uCiAgICAgIElmIHRoZSByZXN1bHQgaXMgbm9uLW5pbCwg dXNlIFZBTFVFIGluc3RlYWQgb2YgU1BFQy4gICovCiAgIGZvcm0gPSBRdDsKZGlmZiAtLWdpdCBh L3NyYy94ZmFjZXMuYyBiL3NyYy94ZmFjZXMuYwppbmRleCBiYWIxNDJhZGUwLi4wMTQyOWFjODZl IDEwMDY0NAotLS0gYS9zcmMveGZhY2VzLmMKKysrIGIvc3JjL3hmYWNlcy5jCkBAIC0zMTAsNyAr MzEwLDcgQEAgI2RlZmluZSBGQUNFX0NBQ0hFX0JVQ0tFVFNfU0laRSAxMDAxCiAKIC8qIEEgdmVj dG9yIG1hcHBpbmcgTGlzcCBmYWNlIElkJ3MgdG8gZmFjZSBuYW1lcy4gICovCiAKLXN0YXRpYyBM aXNwX09iamVjdCAqbGZhY2VfaWRfdG9fbmFtZTsKK0xpc3BfT2JqZWN0ICpsZmFjZV9pZF90b19u YW1lOwogc3RhdGljIHB0cmRpZmZfdCBsZmFjZV9pZF90b19uYW1lX3NpemU7CiAKICNpZmRlZiBI QVZFX1dJTkRPV19TWVNURU0KLS0gCjIuMjYuMgoK --0000000000005fc4d905a422ad7c-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 25 16:11:42 2020 Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 20:11:42 +0000 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 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 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 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 Date: Sat, 25 Apr 2020 23:11:23 +0300 Message-Id: <83d07v72c4.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Sat, 25 Apr 2020 19:41:31 +0000) Subject: Re: bug#40845: SVG rendering issues 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 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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.) From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 26 06:16:23 2020 Received: (at 40845) by debbugs.gnu.org; 26 Apr 2020 10:16:23 +0000 Received: from localhost ([127.0.0.1]:60899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSeKl-0006Ir-Dr for submit@debbugs.gnu.org; Sun, 26 Apr 2020 06:16:23 -0400 Received: from mail-ot1-f48.google.com ([209.85.210.48]:34909) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSeKj-0006Ia-QD for 40845@debbugs.gnu.org; Sun, 26 Apr 2020 06:16:22 -0400 Received: by mail-ot1-f48.google.com with SMTP id e26so20964522otr.2 for <40845@debbugs.gnu.org>; Sun, 26 Apr 2020 03:16:21 -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; bh=d5hkArqvPDEVKV6ZcDcClpmfHT0nwkav9QDgNw297VI=; b=uqXQuXQZ2VvrAe3OXeqeV5jf4Rt2ufKtZ3reKO0qSRpVaDKBX7wgW+XwfNssCK1im6 KZYosk6dQ5/jzq13Oq+rrEzFxwtoBCU3hZZ7o/P+1pXjAIAsuPMA2dYGJ2WHaMDpOQz3 cSKF/nNfy7PgTWVjFfSwzYT1IT1S3DiZfDT7IVs19502QQ6p3+Wi0g4FqURPzxjNnKfz F0eIgHDSR/g3+jtW0/YccGMmnJ9rRh2TLAFeR1jTZOFkgoAoFBL5ZX3gBw7PTmM3Cac2 cmcgoSJv67jnUGE8hKYnBr4PCMKrwv6qLjxSSSzvF9xMvAttZR9/n+F32KQB8dDMvnCR eKCg== 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; bh=d5hkArqvPDEVKV6ZcDcClpmfHT0nwkav9QDgNw297VI=; b=qhMiHb+TT2LAqw2ZdsFh0YCWfs17/9W4EMOO+OMK3bM3tIVwEStFHcaV4nFiAHoPdf pysh+tR0da52Quo/cRHbUa8gAmhBX/hSyBc+V+fS1tK/TzB1Dk2lIi85vM+IdscQQ7S0 DK6kKkubQi9sIQJr80fHl8c3Xyel/sVtNJ11RWFUBPG2/PB18vcRqnwkLnUeA9RPTD4h zGFbs+gTXV/f9WYsGRV5RgWU6t8Otz7/yPYpnLDY3+x2Csf5nGwjPvU6EJnnAqS1aJN6 5tNV0tcPqxznBRvyeJEtIeAhZ4w61dgC1Cvi9LDonjXIMd9qgzaZGb+CShQixB6j/su3 zZtw== X-Gm-Message-State: AGi0PuaLL5TF0REz71ZBUebgqa4ubdoqsh7/gbvjc3FuyuqDeNXB+Ovk ucb31o+o7bo6anQCoomM7j8bAepuYDljZ7rQMx8= X-Google-Smtp-Source: APiQypJYIHTmZQ365qZGjm81wogEKAFxFJInTYyxbzkKCjmtA4q+X+Azaxb+JYxyOXwSpN3gqNgoymiiN+4bQWk77Sk= X-Received: by 2002:aca:ec87:: with SMTP id k129mr13167131oih.44.1587896176112; Sun, 26 Apr 2020 03:16:16 -0700 (PDT) MIME-Version: 1.0 References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83o8rf7fc0.fsf@gnu.org> <83lfmj7dh7.fsf@gnu.org> <83eesb7833.fsf@gnu.org> <83d07v72c4.fsf@gnu.org> In-Reply-To: <83d07v72c4.fsf@gnu.org> From: Pip Cet Date: Sun, 26 Apr 2020 10:15:39 +0000 Message-ID: Subject: Re: bug#40845: SVG rendering issues To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Apr 25, 2020 at 8:11 PM Eli Zaretskii wrote: > > 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. > > > > 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 want to display a glyph that looks different depending on its textual context. That means it's not "an image", in the traditional sense. 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. To be clear, to me "an image" is a compressed way of storing RGBA information for each pixel in a rectangle. It has no concept of foreground color or background color or slant or weight. The enhancement I propose is a layer of indirection, allowing the image spec itself to be adjusted to face/font properties. Whether or not it's best to use a Lisp function for that, or a hash table, is something I'm not clear about yet. > 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 see anything in the above attributes that would be possible to have without major changes to image backends, for features that do not depend on the image backend. > 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. Thus "character-like glyph". It's not an image. My use case is displaying character-like glyphs, implemented as dynamically-generated images, not to display final images. And, no, there's no way for an image backend to interpret that. We have to use different image specs. > None of this requires a new spec or calling Lisp. I don't see how to do it without a new spec. I do see an obvious way of doing it without calling Lisp, by using, say, a hash table. That's an implementation detail, and one I'm willing to argue about, but "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. > 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. Indeed, so the display code has to expose those to Lisp. > 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. The advantage is my use case is supported, and with your proposal (which I don't understand completely, but it appears to be a perfunctory implementation of "foreground"/"background" colors for images) it isn't. Whether we should call Lisp (which would, in practice, return a cached image spec most of the time) or use a hash table (and we'd have to somehow trigger Lisp updating that hash table) is something I'm not clear about. Since we're already calling Lisp from code in the vicinity, it seems relatively safe to do so. > > 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? I'm talking about displaying character-like glyphs. > Why would the > display engine want or need to modify the image using them? To make the glyph character-like. > > 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. 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". That's one valid thing for the Lisp code to do, to leave the image alone and not modify it, but I want the option to have character-like glyphs, which look like characters but aren't, and that means they don't have bright, catchy colors that should be left alone. > Those who design such > icons do a much better job than any Lisp program. That's an end user decision, not something we should assume a priori. > > But all these limitations are fixable. > They wouldn't have existed if you used the code which displays images. I want to display character-like glyphs. I don't see a way doing that with existing image specs, because the image specs do not depend on face/font properties. I'm still not sure what you're proposing, but making images depend in a brutish way on "foreground" and "background" color is a highly specific and limited solution that doesn't solve my use case at all. > So I still don't understand the motivation for this approach. (Read: > I think it's wrong.) 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've certainly not seen any suggestion that would do the former. But, just to be clear, I posted this code because I'd already made the minor effort to get a new (and, IMHO, important) Emacs feature to work. I deliberately decided not to submit it, because while it is a new, generally useful feature Emacs sorely lacks, there are both productive discussions to have about it (such as whether it uses a hash table or a Lisp function calls) and unproductive ones, and the latter in particular translate to a major effort that I did not at the time feel was worth it. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 26 10:38:31 2020 Received: (at 40845) by debbugs.gnu.org; 26 Apr 2020 14:38:31 +0000 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 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 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 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 Date: Sun, 26 Apr 2020 17:38:14 +0300 Message-Id: <83y2qi5n3d.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Sun, 26 Apr 2020 10:15:39 +0000) Subject: Re: bug#40845: SVG rendering issues 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 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 26 15:01:20 2020 Received: (at 40845) by debbugs.gnu.org; 26 Apr 2020 19:01:20 +0000 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 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 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) MIME-Version: 1.0 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> In-Reply-To: <83y2qi5n3d.fsf@gnu.org> From: Pip Cet Date: Sun, 26 Apr 2020 19:00:36 +0000 Message-ID: Subject: Re: bug#40845: SVG rendering issues To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 26 17:17:49 2020 Received: (at 40845) by debbugs.gnu.org; 26 Apr 2020 21:17:49 +0000 Received: from localhost ([127.0.0.1]:35106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSoer-0000P4-Fw for submit@debbugs.gnu.org; Sun, 26 Apr 2020 17:17:49 -0400 Received: from idiocy.org ([217.169.17.33]:55369 helo=breton.holly.idiocy.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSoeq-0000Oq-60 for 40845@debbugs.gnu.org; Sun, 26 Apr 2020 17:17:48 -0400 Received: by breton.holly.idiocy.org (Postfix, from userid 501) id A3CF320225C2AE; Sun, 26 Apr 2020 22:17:41 +0100 (BST) Date: Sun, 26 Apr 2020 22:17:41 +0100 From: Alan Third To: =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel , Eli Zaretskii , 40845@debbugs.gnu.org, pipcet@gmail.com Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200426211741.GA93046@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel , Eli Zaretskii , 40845@debbugs.gnu.org, pipcet@gmail.com References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200425174651.GC82687@breton.holly.idiocy.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Apr 25, 2020 at 06:46:51PM +0100, Alan Third wrote: > On Sat, Apr 25, 2020 at 01:24:13PM -0400, Clément Pit-Claudel wrote: > > On 25/04/2020 13.02, Eli Zaretskii wrote: > > > IMO the foreground of an image shouldn't be affected by the > > > current face's foreground. Images should come with their own colors, > > > and be displayed like that. I think in the context of the discussion > > > that led to this bug report it's actually almost a must: we want > > > images with attractive colors to serve as the icons, we don't want > > > them to be affected by whatever face happens to be nearby. > > > > Yes, of course: if an image has a foreground color, it should be > > respected. But it's not uncommon for SVG images to not include a > > foreground color, as shown in the repro. In that case, the image > > should use the current foreground color, I think. (of course, a > > :foreground keyword, if any, should take precedence; that is issue > > 4). > > Lars fixed the foreground issue for eww by wrapping svg files in > another svg. See svg--wrap-svg in shr.el (bug#37159). > > I think this is the only practical way to handle svg files with no > foreground colour set. To do this when loading _any_ svg we’d probably > have to move it into create-image or image.c. FWIW, with some experimentation I’ve found that this wrapping method can easily sort the scaling problems too. The process would have to go, roughly: * load the svg code * parse it with librsvg * extract the size * calculate the new size (compute_image_size in image.c should work fine) * base64 encode the original svg * wrap it in the new svg code * parse * produce the bitmap Then we’re probably as well skipping all the matrix calculation stuff, the same as we do for ImageMagick, as the bitmap should be the exact size we want. I’m happy to give this a go, but I’m not sure about base64 encoding. Do we already have a way of doing that to a char buffer? -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 26 18:48:19 2020 Received: (at 40845) by debbugs.gnu.org; 26 Apr 2020 22:48:19 +0000 Received: from localhost ([127.0.0.1]:35184 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSq4Q-0002le-Vn for submit@debbugs.gnu.org; Sun, 26 Apr 2020 18:48:19 -0400 Received: from mail-qt1-f169.google.com ([209.85.160.169]:43884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jSq4P-0002lR-MM for 40845@debbugs.gnu.org; Sun, 26 Apr 2020 18:48:17 -0400 Received: by mail-qt1-f169.google.com with SMTP id z90so12838800qtd.10 for <40845@debbugs.gnu.org>; Sun, 26 Apr 2020 15:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=cEci+IvX3iaGodjJSdWlnTeqf0o2gPO1chlZg63mYXE=; b=FQH06cLp4E3Q8CC6wqNFnj0dR57pUfKqenwYBbSPKlGQJ5KAILZSGiFaZpzwQEQpf4 5Z0VU87FrP3vaLH8JDQ1mNsivtzzdGJmZ2atEVHtfs+UQW0mkDRjVB2k+EGK0C/6svbF dqqe5gLiJ0fiVAey9MzyqBVyzW2yPTHxRHlVBObgoK6nLHlInmYa+4jAGN5Z7Zo8/MgC KdmnOaxJXnfFRrSZS+w+aNk3Wv0gp6sije6auuArOR3nmd6tfYBgFxtR73C9fBZ1EthV RFKzgklHxBxidKdfCxqaYlEZfAsZ7r/iHZ4ttDjXoCLIjJHNYEMe5jNmBLC90+pGJCKU U61g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cEci+IvX3iaGodjJSdWlnTeqf0o2gPO1chlZg63mYXE=; b=BsAbqR0yT0FQcjedWgXh8vLqeLOw0xiPN1q8ml32Zv/xphgLYwjo4LvKXNQLB5Jnng pRoUVYRT2fuRC+kfjRP8BgHfRF7k50hq2HaqrxaHMJ3lk8oywhTS+LUVqDca80rBSXU6 LBONEZ4xZDAoXrFVqixbFnYOkpW2xTXPsS534zC8wpo7TX5W4sznmYHL8wcPcPiGz+U3 fDTVuvPE/62mYh6oqESe8Az8qD3WHVtZ7aSVneVONsrqdlNcxwe3S+JenkBGPWfAwQ2s o802h8B8fDbjHpMn+E7cESyQlwxR3R5R5Xpcp6MTZsurVCHrCdSyl2maZSWEdFDZlLt/ hDyQ== X-Gm-Message-State: AGi0PubMgY5oOsmuoU47AhU9dxH0Yj1Gymb7D6vytPYuJj7EUMG9zKk0 3sFdCx7T8PnoqMq5+exmwPw= X-Google-Smtp-Source: APiQypLdv38SVVwcbaksD8X4zbdQd+NBXOYHSwEXL4E4L2S1fyzi8CrZN7XNkviF76awr+xiH38PLg== X-Received: by 2002:ac8:6d35:: with SMTP id r21mr3930556qtu.210.1587941292151; Sun, 26 Apr 2020 15:48:12 -0700 (PDT) Received: from ?IPv6:2601:184:4180:66e7:54d6:bfeb:aa49:9d3b? ([2601:184:4180:66e7:54d6:bfeb:aa49:9d3b]) by smtp.googlemail.com with ESMTPSA id j9sm8495712qkk.99.2020.04.26.15.48.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Apr 2020 15:48:11 -0700 (PDT) Subject: Re: bug#40845: SVG rendering issues To: Alan Third , Eli Zaretskii , 40845@debbugs.gnu.org, pipcet@gmail.com References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Message-ID: <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> Date: Sun, 26 Apr 2020 18:48:09 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200426211741.GA93046@breton.holly.idiocy.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 40845 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 26/04/2020 17.17, Alan Third wrote: > I’m happy to give this a go, but I’m not sure about base64 encoding. > Do we already have a way of doing that to a char buffer? We have base64-encode-region and base64-encode-string, which are both C functions — but why do we need to base64 encode? From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 26 22:28:13 2020 Received: (at 40845) by debbugs.gnu.org; 27 Apr 2020 02:28:13 +0000 Received: from localhost ([127.0.0.1]:35290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jStVE-00088h-PV for submit@debbugs.gnu.org; Sun, 26 Apr 2020 22:28:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59112) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jStVE-00088W-1p for 40845@debbugs.gnu.org; Sun, 26 Apr 2020 22:28:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54703) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jStV8-00049O-2O; Sun, 26 Apr 2020 22:28:06 -0400 Received: from [176.228.60.248] (port=1602 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jStV6-0007cI-In; Sun, 26 Apr 2020 22:28:05 -0400 Date: Mon, 27 Apr 2020 05:27:59 +0300 Message-Id: <83368p64sw.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-Reply-To: <20200426211741.GA93046@breton.holly.idiocy.org> (message from Alan Third on Sun, 26 Apr 2020 22:17:41 +0100) Subject: Re: bug#40845: SVG rendering issues References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 26 Apr 2020 22:17:41 +0100 > From: Alan Third > > I’m happy to give this a go, but I’m not sure about base64 encoding. > Do we already have a way of doing that to a char buffer? I don't think I understand the question. Can you elaborate? From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 27 11:22:38 2020 Received: (at 40845) by debbugs.gnu.org; 27 Apr 2020 15:22:39 +0000 Received: from localhost ([127.0.0.1]:37904 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT5ag-0005Qr-Li for submit@debbugs.gnu.org; Mon, 27 Apr 2020 11:22:38 -0400 Received: from idiocy.org ([217.169.17.33]:55902 helo=breton.holly.idiocy.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT5ae-0005QV-Qr for 40845@debbugs.gnu.org; Mon, 27 Apr 2020 11:22:37 -0400 Received: by breton.holly.idiocy.org (Postfix, from userid 501) id 2BB4920225E8C5; Mon, 27 Apr 2020 16:22:29 +0100 (BST) Date: Mon, 27 Apr 2020 16:22:29 +0100 From: Alan Third To: =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200427152229.GA93571@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel , Eli Zaretskii , 40845@debbugs.gnu.org, pipcet@gmail.com References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 Cc: Eli Zaretskii , 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sun, Apr 26, 2020 at 06:48:09PM -0400, Clément Pit-Claudel wrote: > On 26/04/2020 17.17, Alan Third wrote: > > I’m happy to give this a go, but I’m not sure about base64 encoding. > > Do we already have a way of doing that to a char buffer? > > We have base64-encode-region and base64-encode-string, which are > both C functions — but why do we need to base64 encode? I could be wrong, but in order to wrap the SVG file in another SVG, we need to do something like: We can’t just put the contents in directly, like: stuff as the file may (and probably should) have XML declarations at the start which break the SVG file. We could strip them out but I’m not sure that that’s better than base64 encoding, as it would mean modifying the contents and I’m not sure that’s the only thing that might cause problems. We could also potentially just insert the file as‐is like so: but I can’t make that work. I think we’d have to URL encode the angle brackets and any quotes. If there’s anything obvious I’ve missed, please let me know. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 27 11:47:27 2020 Received: (at 40845) by debbugs.gnu.org; 27 Apr 2020 15:47:27 +0000 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 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 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 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 Date: Mon, 27 Apr 2020 18:47:11 +0300 Message-Id: <83k1213p8g.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Sun, 26 Apr 2020 19:00:36 +0000) Subject: Re: bug#40845: SVG rendering issues 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 27 12:04:41 2020 Received: (at 40845) by debbugs.gnu.org; 27 Apr 2020 16:04:41 +0000 Received: from localhost ([127.0.0.1]:37944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT6FM-0006qZ-Sf for submit@debbugs.gnu.org; Mon, 27 Apr 2020 12:04:41 -0400 Received: from mail-qk1-f179.google.com ([209.85.222.179]:34392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jT6FL-0006qI-3Q for 40845@debbugs.gnu.org; Mon, 27 Apr 2020 12:04:39 -0400 Received: by mail-qk1-f179.google.com with SMTP id t3so18566053qkg.1 for <40845@debbugs.gnu.org>; Mon, 27 Apr 2020 09:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=qKUbw0KV81OQObK6kJ1Yi/BjmODv7laWatQeW/s3kMc=; b=KMOJG4Kq7hg0+TNfwqHuLVsVfnBG6nMy/SMX1vJuaJAAkSUl6PkJcPzIabeFb9fbPL n4vdbz+V9YZ6umXVdqnT8aSoYCbDiEjox9b8PLOeT5eEvXEE0fUqRuHuHQJHLrN61bAF n/hJEw4CqiCRq5djys55HF+hmGoxVPuPy5nEbuRhHcYub23Ohl2Bvdasw3YwMkWz4WxA JxyCAjlzWhjvgo7M2FOnZVahZ+a1e1gGHKSGKvBkLkSWRFSlzyPt8XlCO9y7Werz0M0k TwDLELzueLV8VpSu4ORc1IqdsGLQvumb7Uq1h+qSVdMYVEJ4Hs89ycfxYBGN7Ucoqmza yQvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qKUbw0KV81OQObK6kJ1Yi/BjmODv7laWatQeW/s3kMc=; b=I7Ob7ov2JB86JWdHxfjthS+S7xjDjBWuKlaEhpfc1onV/OBsm0Gt1P8BJ8uDaR1n4P 4TGrxxeqvmoUhWliavOt5j4mMEtV2MNwe6qmoMQVt/LbPsbOE2MMG9iiUJ77Kivikf3l hjD3Vnj46CKHwQc0D0UGBaq6kBHHKdUfb/m/U4apPKg53AAcB0CAx4Wz1P2cVqednUGo Y2aXAKQP4VKFb7KFPmm8gHBfKhqXITPHwkqODeyUnoUes7VcGsjWpVPoXUUN4TrDi7Em IZLVS1S8U2S5fWj4e2JiFB7TnL2uwbFLh+cfxLj32scgfHCHQmrOcUz6C4Cjg/EGVXxC a3dQ== X-Gm-Message-State: AGi0PuZHNNCbM7DyRRX4HZqyY/a48ZpADIUtedydyWG5PGj6Z1iEIVoN QMDlCSRFDo9BzAjH65aAKvU= X-Google-Smtp-Source: APiQypJH8fCYmiEocKG0lyC9ZdstzxkuScMU23sdEmlq0F29QHF0be9LBIHsm5KEgJ46jMK0sswLmw== X-Received: by 2002:a37:a60c:: with SMTP id p12mr22701733qke.430.1588003473478; Mon, 27 Apr 2020 09:04:33 -0700 (PDT) Received: from ?IPv6:2601:184:4180:66e7:54d6:bfeb:aa49:9d3b? ([2601:184:4180:66e7:54d6:bfeb:aa49:9d3b]) by smtp.googlemail.com with ESMTPSA id b19sm11029144qkg.72.2020.04.27.09.04.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Apr 2020 09:04:31 -0700 (PDT) Subject: Re: bug#40845: SVG rendering issues To: Alan Third , Eli Zaretskii , 40845@debbugs.gnu.org, pipcet@gmail.com References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200427152229.GA93571@breton.holly.idiocy.org> From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Message-ID: Date: Mon, 27 Apr 2020 12:04:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200427152229.GA93571@breton.holly.idiocy.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 27/04/2020 11.22, Alan Third wrote: > On Sun, Apr 26, 2020 at 06:48:09PM -0400, Clément Pit-Claudel wrote: >> On 26/04/2020 17.17, Alan Third wrote: >>> I’m happy to give this a go, but I’m not sure about base64 encoding. >>> Do we already have a way of doing that to a char buffer? >> >> We have base64-encode-region and base64-encode-string, which are >> both C functions — but why do we need to base64 encode? > > We can’t just put the contents in directly […] > as the file may (and probably should) have XML declarations at the > start which break the SVG file. We could strip them out but I’m not > sure that that’s better than base64 encoding, as it would mean > modifying the contents and I’m not sure that’s the only thing that > might cause problems. Excellent point, I hadn't considered the xml declaration at the top. From debbugs-submit-bounces@debbugs.gnu.org Sun May 03 10:13:57 2020 Received: (at 40845) by debbugs.gnu.org; 3 May 2020 14:13:57 +0000 Received: from localhost ([127.0.0.1]:57506 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVFNU-0001lz-Sq for submit@debbugs.gnu.org; Sun, 03 May 2020 10:13:57 -0400 Received: from idiocy.org ([217.169.17.33]:61902 helo=breton.holly.idiocy.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVFNT-0001lm-8Q for 40845@debbugs.gnu.org; Sun, 03 May 2020 10:13:55 -0400 Received: by breton.holly.idiocy.org (Postfix, from userid 501) id DC6EF202287590; Sun, 3 May 2020 15:13:48 +0100 (BST) Date: Sun, 3 May 2020 15:13:48 +0100 From: Alan Third To: =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200503141348.GA4071@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel , Eli Zaretskii , 40845@debbugs.gnu.org, pipcet@gmail.com References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 Cc: Eli Zaretskii , 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sun, Apr 26, 2020 at 06:48:09PM -0400, Clément Pit-Claudel wrote: > On 26/04/2020 17.17, Alan Third wrote: > > I’m happy to give this a go, but I’m not sure about base64 encoding. > > Do we already have a way of doing that to a char buffer? > > We have base64-encode-region and base64-encode-string, which are both C functions — but why do we need to base64 encode? I’ve run into a problem with the base64 encoding. /usr/bin/base64 encodes this file differently from Emacs: https://upload.wikimedia.org/wikipedia/commons/9/92/MixedUnitAddition.svg librsvg doesn’t like the way Emacs encodes the file, but is fine with the system base64. I think the problem is the GBP £ symbol on line 39. Do I need to do something special, like set up character encodings? -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sun May 03 10:18:29 2020 Received: (at 40845) by debbugs.gnu.org; 3 May 2020 14:18:29 +0000 Received: from localhost ([127.0.0.1]:57514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVFRs-0001tX-MH for submit@debbugs.gnu.org; Sun, 03 May 2020 10:18:28 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37906) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVFRm-0001tF-4d for 40845@debbugs.gnu.org; Sun, 03 May 2020 10:18:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=WNMeroODNuU1Epvxkr5M9drFuNHG01x07f52n1F82wg=; b=K5qUXgwHdwiHq2wQ0ajHsw21xR xh9JWzQGZen0E7nL8dHNeyagrb7XL6uifQfNFuk4YiRuwOf1TN4j25lyQgi40990+/Is4d1eHbK62 wZoA8Gj2bXWkFNtnpy3lsbiB2mQ9P7SC4uNFUjYqdiJMSKV+P3qAHri58tzzBe01QRZQ=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jVFRS-0002Ov-DY; Sun, 03 May 2020 16:18:15 +0200 From: Lars Ingebrigtsen To: Alan Third Subject: Re: bug#40845: SVG rendering issues References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> Date: Sun, 03 May 2020 16:18:01 +0200 In-Reply-To: <20200503141348.GA4071@breton.holly.idiocy.org> (Alan Third's message of "Sun, 3 May 2020 15:13:48 +0100") Message-ID: <87tv0xw19i.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Alan Third writes: > I’ve run into a problem with the base64 encoding. > > /usr/bin/base64 encodes this file differently from Emacs: > > https://upload.wikimedia.org/wikipedia/commons/9/92/MixedUnitAddition.svg > > li [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 Cc: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel , Eli Zaretskii , pipcet@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Third writes: > I=E2=80=99ve run into a problem with the base64 encoding. > > /usr/bin/base64 encodes this file differently from Emacs: > > https://upload.wikimedia.org/wikipedia/commons/9/92/MixedUnitAddition= .svg > > librsvg doesn=E2=80=99t like the way Emacs encodes the file, but is fine = with > the system base64. > > I think the problem is the GBP =C2=A3 symbol on line 39. > > Do I need to do something special, like set up character encodings? Before base64-encoding, you should encode the data to whatever coding system is expected, which would probably be utf-8 here. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun May 03 12:08:17 2020 Received: (at 40845) by debbugs.gnu.org; 3 May 2020 16:08:17 +0000 Received: from localhost ([127.0.0.1]:57721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVHA2-0000am-K1 for submit@debbugs.gnu.org; Sun, 03 May 2020 12:08:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVHA1-0000aa-EI for 40845@debbugs.gnu.org; Sun, 03 May 2020 12:08:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55217) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVH9v-0006UW-Q4; Sun, 03 May 2020 12:08:03 -0400 Received: from [176.228.60.248] (port=2922 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jVH9v-0004T9-0o; Sun, 03 May 2020 12:08:03 -0400 Date: Sun, 03 May 2020 19:07:56 +0300 Message-Id: <83r1w1ovc3.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-Reply-To: <20200503141348.GA4071@breton.holly.idiocy.org> (message from Alan Third on Sun, 3 May 2020 15:13:48 +0100) Subject: Re: bug#40845: SVG rendering issues References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@gmail.com> <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 3 May 2020 15:13:48 +0100 > From: Alan Third > Cc: Eli Zaretskii , 40845@debbugs.gnu.org, pipcet@gmail.com > > I’ve run into a problem with the base64 encoding. > > /usr/bin/base64 encodes this file differently from Emacs: > > https://upload.wikimedia.org/wikipedia/commons/9/92/MixedUnitAddition.svg > > librsvg doesn’t like the way Emacs encodes the file, but is fine with > the system base64. > > I think the problem is the GBP £ symbol on line 39. > > Do I need to do something special, like set up character encodings? You need to make sure the text passed to base64-encode-region is unibyte. I suggest to look at how other packages call that function. Let me know if this general advice doesn't help. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun May 03 12:24:33 2020 Received: (at 40845) by debbugs.gnu.org; 3 May 2020 16:24:33 +0000 Received: from localhost ([127.0.0.1]:57747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVHPn-0000zw-5r for submit@debbugs.gnu.org; Sun, 03 May 2020 12:24:33 -0400 Received: from idiocy.org ([217.169.17.33]:62190 helo=breton.holly.idiocy.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVHPk-0000zg-An for 40845@debbugs.gnu.org; Sun, 03 May 2020 12:24:25 -0400 Received: by breton.holly.idiocy.org (Postfix, from userid 501) id C1074202289817; Sun, 3 May 2020 17:24:17 +0100 (BST) Date: Sun, 3 May 2020 17:24:17 +0100 From: Alan Third To: Eli Zaretskii Subject: Re: bug#40845: SVG rendering issues Message-ID: Mail-Followup-To: Alan Third , Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com References: <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> <83r1w1ovc3.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83r1w1ovc3.fsf@gnu.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Sun, May 03, 2020 at 07:07:56PM +0300, Eli Zaretskii wrote: > > Date: Sun, 3 May 2020 15:13:48 +0100 > > From: Alan Third > > Cc: Eli Zaretskii , 40845@debbugs.gnu.org, pipcet@gmail.com > > > > I’ve run into a problem with the base64 encoding. > > > > /usr/bin/base64 encodes this file differently from Emacs: > > > > https://upload.wikimedia.org/wikipedia/commons/9/92/MixedUnitAddition.svg > > > > librsvg doesn’t like the way Emacs encodes the file, but is fine with > > the system base64. > > > > I think the problem is the GBP £ symbol on line 39. > > > > Do I need to do something special, like set up character encodings? > > You need to make sure the text passed to base64-encode-region is > unibyte. I suggest to look at how other packages call that function. > > Let me know if this general advice doesn't help. Yes, it’s sorted the problem. Thanks! I’ve attached a first pass. It solves 1 and 4 from the original bug report: scaling and setting the foreground colour. One thing is that it gets the foreground colour from the default face instead of the current face. I’m not sure how to solve that. I’m unsure if my use of malloc is OK, as I know Emacs code uses some different methods in different places. -- Alan Third --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0001-Set-basic-SVG-attributes-bug-40845.patch" >From 78026c9697edda23073409a59176367fc1ad58ba Mon Sep 17 00:00:00 2001 From: Alan Third Date: Sun, 3 May 2020 17:09:31 +0100 Subject: [PATCH] Set basic SVG attributes (bug#40845) * lisp/net/shr.el (shr-parse-image-data): Remove call to svg--wrap-svg. (svg--wrap-svg): Remove function. * src/image.c (image_set_transform): SVGs should not be scaled by native transforms as they should be the correct size already. (enum svg_keyword_index): (svg_format): Add the :foreground keyword. (svg_load_image): Calculate the desired size of the SVG and wrap it in another SVG that allows us to resize it. Also set the background and foreground colors. --- lisp/net/shr.el | 17 ------ src/image.c | 150 +++++++++++++++++++++++++++++++++++++++--------- 2 files changed, 122 insertions(+), 45 deletions(-) diff --git a/lisp/net/shr.el b/lisp/net/shr.el index 1f80ab74db..c862cf04e3 100644 --- a/lisp/net/shr.el +++ b/lisp/net/shr.el @@ -1195,25 +1195,8 @@ shr-parse-image-data ;; that are non-ASCII. (shr-dom-to-xml (libxml-parse-xml-region (point) (point-max)) 'utf-8))) - ;; SVG images often do not have a specified foreground/background - ;; color, so wrap them in styles. - (when (and (display-images-p) - (eq content-type 'image/svg+xml)) - (setq data (svg--wrap-svg data))) (list data content-type))) -(defun svg--wrap-svg (data) - "Add a default foreground colour to SVG images." - (let ((size (image-size (create-image data nil t :scaling 1) t))) - (with-temp-buffer - (insert - (format - " " - (face-foreground 'default) - (car size) (cdr size) - (base64-encode-string data t))) - (buffer-string)))) - (defun shr-image-displayer (content-function) "Return a function to display an image. CONTENT-FUNCTION is a function to retrieve an image for a cid url that diff --git a/src/image.c b/src/image.c index c8a192aaaf..06760a62c2 100644 --- a/src/image.c +++ b/src/image.c @@ -2108,7 +2108,17 @@ image_set_transform (struct frame *f, struct image *img) /* Determine size. */ int width, height; - compute_image_size (img->width, img->height, img->spec, &width, &height); + +#ifdef HAVE_RSVG + /* SVGs are pre-scaled to the correct size. */ + if (EQ (image_spec_value (img->spec, QCtype, NULL), Qsvg)) + { + width = img->width; + height = img->height; + } + else +#endif + compute_image_size (img->width, img->height, img->spec, &width, &height); /* Determine rotation. */ double rotation = 0.0; @@ -9393,6 +9403,7 @@ DEFUN ("imagemagick-types", Fimagemagick_types, Simagemagick_types, 0, 0, 0, SVG_ALGORITHM, SVG_HEURISTIC_MASK, SVG_MASK, + SVG_FOREGROUND, SVG_BACKGROUND, SVG_LAST }; @@ -9411,6 +9422,7 @@ DEFUN ("imagemagick-types", Fimagemagick_types, Simagemagick_types, 0, 0, 0, {":conversion", IMAGE_DONT_CHECK_VALUE_TYPE, 0}, {":heuristic-mask", IMAGE_DONT_CHECK_VALUE_TYPE, 0}, {":mask", IMAGE_DONT_CHECK_VALUE_TYPE, 0}, + {":foreground", IMAGE_STRING_OR_NIL_VALUE, 0}, {":background", IMAGE_STRING_OR_NIL_VALUE, 0} }; @@ -9675,6 +9687,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents, int height; const guint8 *pixels; int rowstride; + char *wrapped_contents; + ptrdiff_t wrapped_size; #if ! GLIB_CHECK_VERSION (2, 36, 0) /* g_type_init is a glib function that must be called prior to @@ -9682,6 +9696,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents, g_type_init (); #endif + /* Parse the unmodified SVG data so we can get it's initial size. */ + #if LIBRSVG_CHECK_VERSION (2, 32, 0) GInputStream *input_stream = g_memory_input_stream_new_from_data (contents, size, NULL); @@ -9710,6 +9726,107 @@ svg_load_image (struct frame *f, struct image *img, char *contents, rsvg_handle_write (rsvg_handle, (unsigned char *) contents, size, &err); if (err) goto rsvg_error; + /* The parsing is complete, rsvg_handle is ready to used, close it + for further writes. */ + rsvg_handle_close (rsvg_handle, &err); + if (err) goto rsvg_error; +#endif + + /* Get the image dimensions. */ + rsvg_handle_get_dimensions (rsvg_handle, &dimension_data); + + /* We are now done with the unmodified data. */ + g_object_unref (rsvg_handle); + + /* Calculate the final image size. */ + compute_image_size (dimension_data.width, dimension_data.height, + img->spec, &width, &height); + + /* Wrap the SVG data in another SVG. This allows us to set the + width and height, as well as modify the foreground and background + colors. */ + { + Lisp_Object value; + unsigned long foreground = FRAME_FOREGROUND_PIXEL (f); + unsigned long background = FRAME_BACKGROUND_PIXEL (f); + + Lisp_Object encoded_contents = Fbase64_encode_string + (make_unibyte_string (contents, size), Qt); + + /* The wrapper sets the foreground color, width and height, and + viewBox must contain the dimensions of the original image. It + also draws a rectangle over the whole space, set to the + background color, before including the original image. This + acts to set the background color, instead of leaving it + transparent. */ + const char *wrapper = + "" + "" + "" + ""; + + /* FIXME: I've added 64 in the hope it will cover the size of the + width and height strings and things. */ + int buffer_size = SBYTES (encoded_contents) + strlen (wrapper) + 64; + + value = image_spec_value (img->spec, QCforeground, NULL); + if (!NILP (value)) + { + foreground = image_alloc_image_color (f, img, value, foreground); + } + value = image_spec_value (img->spec, QCbackground, NULL); + if (!NILP (value)) + { + background = image_alloc_image_color (f, img, value, background); + img->background = background; + img->background_valid = 1; + } + + wrapped_contents = malloc (buffer_size); + + if (!wrapped_contents + || buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper, + foreground & 0xFFFFFF, width, height, + dimension_data.width, dimension_data.height, + background & 0xFFFFFF, SSDATA (encoded_contents))) + goto rsvg_error; + + wrapped_size = strlen (wrapped_contents); + } + + /* Now we parse the wrapped version. */ + +#if LIBRSVG_CHECK_VERSION (2, 32, 0) + input_stream = g_memory_input_stream_new_from_data (wrapped_contents, wrapped_size, NULL); + base_file = filename ? g_file_new_for_path (filename) : NULL; + rsvg_handle = rsvg_handle_new_from_stream_sync (input_stream, base_file, + RSVG_HANDLE_FLAGS_NONE, + NULL, &err); + if (base_file) + g_object_unref (base_file); + g_object_unref (input_stream); + + /* Check rsvg_handle too, to avoid librsvg 2.40.13 bug (Bug#36773#26). */ + if (!rsvg_handle || err) goto rsvg_error; +#else + /* Make a handle to a new rsvg object. */ + rsvg_handle = rsvg_handle_new (); + eassume (rsvg_handle); + + /* Set base_uri for properly handling referenced images (via 'href'). + See rsvg bug 596114 - "image refs are relative to curdir, not .svg file" + . */ + if (filename) + rsvg_handle_set_base_uri (rsvg_handle, filename); + + /* Parse the contents argument and fill in the rsvg_handle. */ + rsvg_handle_write (rsvg_handle, (unsigned char *) wrapped_contents, wrapped_size, &err); + if (err) goto rsvg_error; + /* The parsing is complete, rsvg_handle is ready to used, close it for further writes. */ rsvg_handle_close (rsvg_handle, &err); @@ -9728,6 +9845,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents, pixbuf = rsvg_handle_get_pixbuf (rsvg_handle); if (!pixbuf) goto rsvg_error; g_object_unref (rsvg_handle); + free (wrapped_contents); /* Extract some meta data from the svg handle. */ width = gdk_pixbuf_get_width (pixbuf); @@ -9752,25 +9870,6 @@ svg_load_image (struct frame *f, struct image *img, char *contents, init_color_table (); - /* Handle alpha channel by combining the image with a background - color. */ - Emacs_Color background; - Lisp_Object specified_bg = image_spec_value (img->spec, QCbackground, NULL); - if (!STRINGP (specified_bg) - || !FRAME_TERMINAL (f)->defined_color_hook (f, - SSDATA (specified_bg), - &background, - false, - false)) - FRAME_TERMINAL (f)->query_frame_background_color (f, &background); - - /* SVG pixmaps specify transparency in the last byte, so right - shift 8 bits to get rid of it, since emacs doesn't support - transparency. */ - background.red >>= 8; - background.green >>= 8; - background.blue >>= 8; - /* This loop handles opacity values, since Emacs assumes non-transparent images. Each pixel must be "flattened" by calculating the resulting color, given the transparency of the @@ -9784,14 +9883,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents, int blue = *pixels++; int opacity = *pixels++; - red = ((red * opacity) - + (background.red * ((1 << 8) - opacity))); - green = ((green * opacity) - + (background.green * ((1 << 8) - opacity))); - blue = ((blue * opacity) - + (background.blue * ((1 << 8) - opacity))); - - PUT_PIXEL (ximg, x, y, lookup_rgb_color (f, red, green, blue)); + PUT_PIXEL (ximg, x, y, lookup_rgb_color (f, red << 8, green << 8, blue << 8)); } pixels += rowstride - 4 * width; @@ -9821,6 +9913,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents, rsvg_error: if (rsvg_handle) g_object_unref (rsvg_handle); + if (wrapped_contents) + free (wrapped_contents); /* FIXME: Use error->message so the user knows what is the actual problem with the image. */ image_error ("Error parsing SVG image `%s'", img->spec); -- 2.26.1 --fdj2RfSjLxBAspz7-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 03 12:49:59 2020 Received: (at 40845) by debbugs.gnu.org; 3 May 2020 16:49:59 +0000 Received: from localhost ([127.0.0.1]:57777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVHoV-0001e2-68 for submit@debbugs.gnu.org; Sun, 03 May 2020 12:49:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVHoT-0001dc-RY for 40845@debbugs.gnu.org; Sun, 03 May 2020 12:49:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56003) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVHoN-0001X0-PH; Sun, 03 May 2020 12:49:51 -0400 Received: from [176.228.60.248] (port=1621 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jVHoN-0001in-42; Sun, 03 May 2020 12:49:51 -0400 Date: Sun, 03 May 2020 19:49:45 +0300 Message-Id: <83ftchotee.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-Reply-To: (message from Alan Third on Sun, 3 May 2020 17:24:17 +0100) Subject: Re: bug#40845: SVG rendering issues References: <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> <83r1w1ovc3.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 3 May 2020 17:24:17 +0100 > From: Alan Third > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com > > I’ve attached a first pass. It solves 1 and 4 from the original bug > report: scaling and setting the foreground colour. Thanks. > One thing is that it gets the foreground colour from the default face > instead of the current face. I’m not sure how to solve that. Can you describe the difficulty in using the current face? > I’m unsure if my use of malloc is OK, as I know Emacs code uses some > different methods in different places. It's okay to call malloc and free in image.c. From debbugs-submit-bounces@debbugs.gnu.org Sun May 03 14:38:48 2020 Received: (at 40845) by debbugs.gnu.org; 3 May 2020 18:38:48 +0000 Received: from localhost ([127.0.0.1]:58011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVJVo-0004YG-7t for submit@debbugs.gnu.org; Sun, 03 May 2020 14:38:48 -0400 Received: from idiocy.org ([217.169.17.33]:62406 helo=breton.holly.idiocy.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVJVn-0004Xx-3F for 40845@debbugs.gnu.org; Sun, 03 May 2020 14:38:47 -0400 Received: by breton.holly.idiocy.org (Postfix, from userid 501) id 3840E20228A952; Sun, 3 May 2020 19:38:39 +0100 (BST) Date: Sun, 3 May 2020 19:38:39 +0100 From: Alan Third To: Eli Zaretskii Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200503183839.GA24860@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com References: <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> <83r1w1ovc3.fsf@gnu.org> <83ftchotee.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83ftchotee.fsf@gnu.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sun, May 03, 2020 at 07:49:45PM +0300, Eli Zaretskii wrote: > > Date: Sun, 3 May 2020 17:24:17 +0100 > > From: Alan Third > > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com > > > > One thing is that it gets the foreground colour from the default face > > instead of the current face. I’m not sure how to solve that. > > Can you describe the difficulty in using the current face? I’m mostly unsure how I access it. I don’t think images or image.c have any real concept of where they are in the buffer. I think we’d also have to recreate the image any time the face changed. For example in Clement’s test code from the original bug report, he has the face changing when the mouse hovers over the text. In order to handle that case we would need to create a new version of the image with the updated foreground and background when the mouse moves over it. We can work around having to update the background by using proper transparency, but I don’t know what other problems that might introduce. It’s harder for the foreground. Pip Cet suggested creating masks for foreground and background and using them to draw the image in sections, but I feel that’s perhaps getting a little complex, especially when I think most images won’t be changing their foreground and background colours. I feel it would be easier just to have two or more cached images with different foreground and backgrounds as required. > > I’m unsure if my use of malloc is OK, as I know Emacs code uses some > > different methods in different places. > > It's okay to call malloc and free in image.c. Excellent, thanks. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sun May 03 15:18:04 2020 Received: (at 40845) by debbugs.gnu.org; 3 May 2020 19:18:04 +0000 Received: from localhost ([127.0.0.1]:58043 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVK7o-0005VR-1J for submit@debbugs.gnu.org; Sun, 03 May 2020 15:18:04 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59924) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jVK7m-0005Uy-Uh for 40845@debbugs.gnu.org; Sun, 03 May 2020 15:18:03 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58489) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVK7h-0006IV-4t; Sun, 03 May 2020 15:17:57 -0400 Received: from [176.228.60.248] (port=2758 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jVK7g-0000Hd-JQ; Sun, 03 May 2020 15:17:56 -0400 Date: Sun, 03 May 2020 22:17:49 +0300 Message-Id: <834kswq142.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-Reply-To: <20200503183839.GA24860@breton.holly.idiocy.org> (message from Alan Third on Sun, 3 May 2020 19:38:39 +0100) Subject: Re: bug#40845: SVG rendering issues References: <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> <83r1w1ovc3.fsf@gnu.org> <83ftchotee.fsf@gnu.org> <20200503183839.GA24860@breton.holly.idiocy.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 3 May 2020 19:38:39 +0100 > From: Alan Third > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com > > > > One thing is that it gets the foreground colour from the default face > > > instead of the current face. I’m not sure how to solve that. > > > > Can you describe the difficulty in using the current face? > > I’m mostly unsure how I access it. I don’t think images or image.c > have any real concept of where they are in the buffer. When the 'load' method (in your case, svg_load) is called from prepare_image_for_display, we have the face information handy. Usually, at that point we don't call the 'load' method, because the image is already loaded and cached. But we could change the logic if we know that the image must be modified to have a different face. Then we can pass the color information to the 'load' method. > I think we’d also have to recreate the image any time the face > changed. Yes, because changing the color(s) makes a different image. But that is not a problem, I think. > I feel it would be easier just to have two or more cached images with > different foreground and backgrounds as required. Agreed. At least as the first approximation; we could always change that later if we find this not to be good enough. From debbugs-submit-bounces@debbugs.gnu.org Sat May 09 10:27:37 2020 Received: (at 40845) by debbugs.gnu.org; 9 May 2020 14:27:37 +0000 Received: from localhost ([127.0.0.1]:48214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXQS1-00016E-7v for submit@debbugs.gnu.org; Sat, 09 May 2020 10:27:37 -0400 Received: from idiocy.org ([217.169.17.33]:50372 helo=breton.holly.idiocy.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXQRz-00015r-Nq for 40845@debbugs.gnu.org; Sat, 09 May 2020 10:27:36 -0400 Received: by breton.holly.idiocy.org (Postfix, from userid 501) id AC2122022AC482; Sat, 9 May 2020 15:27:27 +0100 (BST) Date: Sat, 9 May 2020 15:27:27 +0100 From: Alan Third To: Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200509142727.GA42881@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com References: <83mu6z7em5.fsf@gnu.org> <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> <83r1w1ovc3.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sun, May 03, 2020 at 05:24:17PM +0100, Alan Third wrote: > > I’ve attached a first pass. It solves 1 and 4 from the original bug > report: scaling and setting the foreground colour. Can someone please try the patch from the previous email on a non‐NS platform and confirm whether or not the background colour in the image matches the background colour of the text? They don’t match here, but I strongly suspect that’s because the NS port uses different colour spaces for images and everything else. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sat May 09 15:54:24 2020 Received: (at 40845) by debbugs.gnu.org; 9 May 2020 19:54:24 +0000 Received: from localhost ([127.0.0.1]:48422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXVYG-0006ml-13 for submit@debbugs.gnu.org; Sat, 09 May 2020 15:54:24 -0400 Received: from idiocy.org ([217.169.17.33]:50840 helo=breton.holly.idiocy.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jXVYE-0006mT-AB for 40845@debbugs.gnu.org; Sat, 09 May 2020 15:54:23 -0400 Received: by breton.holly.idiocy.org (Postfix, from userid 501) id 104412022AF2F2; Sat, 9 May 2020 20:54:15 +0100 (BST) Date: Sat, 9 May 2020 20:54:15 +0100 From: Alan Third To: Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200509195415.GA44624@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com References: <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> <83r1w1ovc3.fsf@gnu.org> <20200509142727.GA42881@breton.holly.idiocy.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200509142727.GA42881@breton.holly.idiocy.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --jRHKVT23PllUwdXP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Sat, May 09, 2020 at 03:27:27PM +0100, Alan Third wrote: > On Sun, May 03, 2020 at 05:24:17PM +0100, Alan Third wrote: > > > > I’ve attached a first pass. It solves 1 and 4 from the original bug > > report: scaling and setting the foreground colour. > > Can someone please try the patch from the previous email on a non‐NS > platform and confirm whether or not the background colour in the image > matches the background colour of the text? > > They don’t match here, but I strongly suspect that’s because the NS > port uses different colour spaces for images and everything else. Apologies, please can someone try the attached patch. -- Alan Third --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0001-Set-basic-SVG-attributes-bug-40845.patch" >From 6c1620ebd80bcfa1065b02350dfa875bec04fc0c Mon Sep 17 00:00:00 2001 From: Alan Third Date: Sun, 3 May 2020 17:09:31 +0100 Subject: [PATCH] Set basic SVG attributes (bug#40845) --- lisp/net/shr.el | 17 ----- src/dispextern.h | 2 +- src/gtkutil.c | 2 +- src/image.c | 179 ++++++++++++++++++++++++++++++++++++----------- src/nsmenu.m | 2 +- src/xdisp.c | 6 +- 6 files changed, 145 insertions(+), 63 deletions(-) diff --git a/lisp/net/shr.el b/lisp/net/shr.el index 1f80ab74db..c862cf04e3 100644 --- a/lisp/net/shr.el +++ b/lisp/net/shr.el @@ -1195,25 +1195,8 @@ shr-parse-image-data ;; that are non-ASCII. (shr-dom-to-xml (libxml-parse-xml-region (point) (point-max)) 'utf-8))) - ;; SVG images often do not have a specified foreground/background - ;; color, so wrap them in styles. - (when (and (display-images-p) - (eq content-type 'image/svg+xml)) - (setq data (svg--wrap-svg data))) (list data content-type))) -(defun svg--wrap-svg (data) - "Add a default foreground colour to SVG images." - (let ((size (image-size (create-image data nil t :scaling 1) t))) - (with-temp-buffer - (insert - (format - " " - (face-foreground 'default) - (car size) (cdr size) - (base64-encode-string data t))) - (buffer-string)))) - (defun shr-image-displayer (content-function) "Return a function to display an image. CONTENT-FUNCTION is a function to retrieve an image for a cid url that diff --git a/src/dispextern.h b/src/dispextern.h index 0b1f3d14ae..cd09e0846c 100644 --- a/src/dispextern.h +++ b/src/dispextern.h @@ -3475,7 +3475,7 @@ #define TRY_WINDOW_IGNORE_FONTS_CHANGE (1 << 1) void mark_image_cache (struct image_cache *); bool valid_image_p (Lisp_Object); void prepare_image_for_display (struct frame *, struct image *); -ptrdiff_t lookup_image (struct frame *, Lisp_Object); +ptrdiff_t lookup_image (struct frame *, Lisp_Object, int face_id); #if defined HAVE_X_WINDOWS || defined USE_CAIRO || defined HAVE_NS #define RGB_PIXEL_COLOR unsigned long diff --git a/src/gtkutil.c b/src/gtkutil.c index 681f86f51b..2f6b664d2d 100644 --- a/src/gtkutil.c +++ b/src/gtkutil.c @@ -5101,7 +5101,7 @@ update_frame_tool_bar (struct frame *f) else idx = -1; - img_id = lookup_image (f, image); + img_id = lookup_image (f, image, -1); img = IMAGE_FROM_ID (f, img_id); prepare_image_for_display (f, img); diff --git a/src/image.c b/src/image.c index c8a192aaaf..5333d66c7d 100644 --- a/src/image.c +++ b/src/image.c @@ -1066,7 +1066,7 @@ DEFUN ("image-size", Fimage_size, Simage_size, 1, 3, 0, if (valid_image_p (spec)) { struct frame *f = decode_window_system_frame (frame); - ptrdiff_t id = lookup_image (f, spec); + ptrdiff_t id = lookup_image (f, spec, -1); struct image *img = IMAGE_FROM_ID (f, id); int width = img->width + 2 * img->hmargin; int height = img->height + 2 * img->vmargin; @@ -1096,7 +1096,7 @@ DEFUN ("image-mask-p", Fimage_mask_p, Simage_mask_p, 1, 2, 0, if (valid_image_p (spec)) { struct frame *f = decode_window_system_frame (frame); - ptrdiff_t id = lookup_image (f, spec); + ptrdiff_t id = lookup_image (f, spec, -1); struct image *img = IMAGE_FROM_ID (f, id); if (img->mask) mask = Qt; @@ -1119,7 +1119,7 @@ DEFUN ("image-metadata", Fimage_metadata, Simage_metadata, 1, 2, 0, if (valid_image_p (spec)) { struct frame *f = decode_window_system_frame (frame); - ptrdiff_t id = lookup_image (f, spec); + ptrdiff_t id = lookup_image (f, spec, -1); struct image *img = IMAGE_FROM_ID (f, id); ext = img->lisp_data; } @@ -1586,7 +1586,8 @@ make_image_cache (void) /* Find an image matching SPEC in the cache, and return it. If no image is found, return NULL. */ static struct image * -search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash) +search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash, + unsigned long foreground, unsigned long background) { struct image *img; struct image_cache *c = FRAME_IMAGE_CACHE (f); @@ -1609,8 +1610,8 @@ search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash) for (img = c->buckets[i]; img; img = img->next) if (img->hash == hash && !NILP (Fequal (img->spec, spec)) - && img->frame_foreground == FRAME_FOREGROUND_PIXEL (f) - && img->frame_background == FRAME_BACKGROUND_PIXEL (f)) + && img->frame_foreground == foreground + && img->frame_background == background) break; return img; } @@ -1621,7 +1622,7 @@ search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash) static void uncache_image (struct frame *f, Lisp_Object spec) { - struct image *img = search_image_cache (f, spec, sxhash (spec)); + struct image *img = search_image_cache (f, spec, sxhash (spec), FRAME_FOREGROUND_PIXEL (f), FRAME_BACKGROUND_PIXEL (f)); if (img) { free_image (f, img); @@ -2108,7 +2109,17 @@ image_set_transform (struct frame *f, struct image *img) /* Determine size. */ int width, height; - compute_image_size (img->width, img->height, img->spec, &width, &height); + +#ifdef HAVE_RSVG + /* SVGs are pre-scaled to the correct size. */ + if (EQ (image_spec_value (img->spec, QCtype, NULL), Qsvg)) + { + width = img->width; + height = img->height; + } + else +#endif + compute_image_size (img->width, img->height, img->spec, &width, &height); /* Determine rotation. */ double rotation = 0.0; @@ -2275,11 +2286,15 @@ image_set_transform (struct frame *f, struct image *img) SPEC must be a valid Lisp image specification (see valid_image_p). */ ptrdiff_t -lookup_image (struct frame *f, Lisp_Object spec) +lookup_image (struct frame *f, Lisp_Object spec, int face_id) { struct image *img; EMACS_UINT hash; + struct face *face = (face_id >= 0) ? FACE_FROM_ID (f, face_id) : FRAME_DEFAULT_FACE (f); + unsigned long foreground = FACE_COLOR_TO_PIXEL (face->foreground, f); + unsigned long background = FACE_COLOR_TO_PIXEL (face->background, f); + /* F must be a window-system frame, and SPEC must be a valid image specification. */ eassert (FRAME_WINDOW_P (f)); @@ -2287,7 +2302,7 @@ lookup_image (struct frame *f, Lisp_Object spec) /* Look up SPEC in the hash table of the image cache. */ hash = sxhash (spec); - img = search_image_cache (f, spec, hash); + img = search_image_cache (f, spec, hash, foreground, background); if (img && img->load_failed_p) { free_image (f, img); @@ -2300,9 +2315,9 @@ lookup_image (struct frame *f, Lisp_Object spec) block_input (); img = make_image (spec, hash); cache_image (f, img); + img->frame_foreground = foreground; + img->frame_background = background; img->load_failed_p = ! img->type->load (f, img); - img->frame_foreground = FRAME_FOREGROUND_PIXEL (f); - img->frame_background = FRAME_BACKGROUND_PIXEL (f); /* If we can't load the image, and we don't have a width and height, use some arbitrary width and height so that we can @@ -9393,6 +9408,7 @@ DEFUN ("imagemagick-types", Fimagemagick_types, Simagemagick_types, 0, 0, 0, SVG_ALGORITHM, SVG_HEURISTIC_MASK, SVG_MASK, + SVG_FOREGROUND, SVG_BACKGROUND, SVG_LAST }; @@ -9411,6 +9427,7 @@ DEFUN ("imagemagick-types", Fimagemagick_types, Simagemagick_types, 0, 0, 0, {":conversion", IMAGE_DONT_CHECK_VALUE_TYPE, 0}, {":heuristic-mask", IMAGE_DONT_CHECK_VALUE_TYPE, 0}, {":mask", IMAGE_DONT_CHECK_VALUE_TYPE, 0}, + {":foreground", IMAGE_STRING_OR_NIL_VALUE, 0}, {":background", IMAGE_STRING_OR_NIL_VALUE, 0} }; @@ -9675,6 +9692,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents, int height; const guint8 *pixels; int rowstride; + char *wrapped_contents; + ptrdiff_t wrapped_size; #if ! GLIB_CHECK_VERSION (2, 36, 0) /* g_type_init is a glib function that must be called prior to @@ -9682,6 +9701,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents, g_type_init (); #endif + /* Parse the unmodified SVG data so we can get it's initial size. */ + #if LIBRSVG_CHECK_VERSION (2, 32, 0) GInputStream *input_stream = g_memory_input_stream_new_from_data (contents, size, NULL); @@ -9710,6 +9731,107 @@ svg_load_image (struct frame *f, struct image *img, char *contents, rsvg_handle_write (rsvg_handle, (unsigned char *) contents, size, &err); if (err) goto rsvg_error; + /* The parsing is complete, rsvg_handle is ready to used, close it + for further writes. */ + rsvg_handle_close (rsvg_handle, &err); + if (err) goto rsvg_error; +#endif + + /* Get the image dimensions. */ + rsvg_handle_get_dimensions (rsvg_handle, &dimension_data); + + /* We are now done with the unmodified data. */ + g_object_unref (rsvg_handle); + + /* Calculate the final image size. */ + compute_image_size (dimension_data.width, dimension_data.height, + img->spec, &width, &height); + + /* Wrap the SVG data in another SVG. This allows us to set the + width and height, as well as modify the foreground and background + colors. */ + { + Lisp_Object value; + unsigned long foreground = img->frame_foreground; + unsigned long background = img->frame_background; + + Lisp_Object encoded_contents = Fbase64_encode_string + (make_unibyte_string (contents, size), Qt); + + /* The wrapper sets the foreground color, width and height, and + viewBox must contain the dimensions of the original image. It + also draws a rectangle over the whole space, set to the + background color, before including the original image. This + acts to set the background color, instead of leaving it + transparent. */ + const char *wrapper = + "" + "" + "" + ""; + + /* FIXME: I've added 64 in the hope it will cover the size of the + width and height strings and things. */ + int buffer_size = SBYTES (encoded_contents) + strlen (wrapper) + 64; + + value = image_spec_value (img->spec, QCforeground, NULL); + if (!NILP (value)) + { + foreground = image_alloc_image_color (f, img, value, img->frame_foreground); + } + value = image_spec_value (img->spec, QCbackground, NULL); + if (!NILP (value)) + { + background = image_alloc_image_color (f, img, value, img->frame_background); + img->background = background; + img->background_valid = 1; + } + + wrapped_contents = malloc (buffer_size); + + if (!wrapped_contents + || buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper, + foreground & 0xFFFFFF, width, height, + dimension_data.width, dimension_data.height, + background & 0xFFFFFF, SSDATA (encoded_contents))) + goto rsvg_error; + + wrapped_size = strlen (wrapped_contents); + } + + /* Now we parse the wrapped version. */ + +#if LIBRSVG_CHECK_VERSION (2, 32, 0) + input_stream = g_memory_input_stream_new_from_data (wrapped_contents, wrapped_size, NULL); + base_file = filename ? g_file_new_for_path (filename) : NULL; + rsvg_handle = rsvg_handle_new_from_stream_sync (input_stream, base_file, + RSVG_HANDLE_FLAGS_NONE, + NULL, &err); + if (base_file) + g_object_unref (base_file); + g_object_unref (input_stream); + + /* Check rsvg_handle too, to avoid librsvg 2.40.13 bug (Bug#36773#26). */ + if (!rsvg_handle || err) goto rsvg_error; +#else + /* Make a handle to a new rsvg object. */ + rsvg_handle = rsvg_handle_new (); + eassume (rsvg_handle); + + /* Set base_uri for properly handling referenced images (via 'href'). + See rsvg bug 596114 - "image refs are relative to curdir, not .svg file" + . */ + if (filename) + rsvg_handle_set_base_uri (rsvg_handle, filename); + + /* Parse the contents argument and fill in the rsvg_handle. */ + rsvg_handle_write (rsvg_handle, (unsigned char *) wrapped_contents, wrapped_size, &err); + if (err) goto rsvg_error; + /* The parsing is complete, rsvg_handle is ready to used, close it for further writes. */ rsvg_handle_close (rsvg_handle, &err); @@ -9728,6 +9850,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents, pixbuf = rsvg_handle_get_pixbuf (rsvg_handle); if (!pixbuf) goto rsvg_error; g_object_unref (rsvg_handle); + free (wrapped_contents); /* Extract some meta data from the svg handle. */ width = gdk_pixbuf_get_width (pixbuf); @@ -9752,25 +9875,6 @@ svg_load_image (struct frame *f, struct image *img, char *contents, init_color_table (); - /* Handle alpha channel by combining the image with a background - color. */ - Emacs_Color background; - Lisp_Object specified_bg = image_spec_value (img->spec, QCbackground, NULL); - if (!STRINGP (specified_bg) - || !FRAME_TERMINAL (f)->defined_color_hook (f, - SSDATA (specified_bg), - &background, - false, - false)) - FRAME_TERMINAL (f)->query_frame_background_color (f, &background); - - /* SVG pixmaps specify transparency in the last byte, so right - shift 8 bits to get rid of it, since emacs doesn't support - transparency. */ - background.red >>= 8; - background.green >>= 8; - background.blue >>= 8; - /* This loop handles opacity values, since Emacs assumes non-transparent images. Each pixel must be "flattened" by calculating the resulting color, given the transparency of the @@ -9784,14 +9888,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents, int blue = *pixels++; int opacity = *pixels++; - red = ((red * opacity) - + (background.red * ((1 << 8) - opacity))); - green = ((green * opacity) - + (background.green * ((1 << 8) - opacity))); - blue = ((blue * opacity) - + (background.blue * ((1 << 8) - opacity))); - - PUT_PIXEL (ximg, x, y, lookup_rgb_color (f, red, green, blue)); + PUT_PIXEL (ximg, x, y, lookup_rgb_color (f, red << 8, green << 8, blue << 8)); } pixels += rowstride - 4 * width; @@ -9821,6 +9918,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents, rsvg_error: if (rsvg_handle) g_object_unref (rsvg_handle); + if (wrapped_contents) + free (wrapped_contents); /* FIXME: Use error->message so the user knows what is the actual problem with the image. */ image_error ("Error parsing SVG image `%s'", img->spec); @@ -10119,7 +10218,7 @@ DEFUN ("lookup-image", Flookup_image, Slookup_image, 1, 1, 0, ptrdiff_t id = -1; if (valid_image_p (spec)) - id = lookup_image (SELECTED_FRAME (), spec); + id = lookup_image (SELECTED_FRAME (), spec, -1); debug_print (spec); return make_fixnum (id); diff --git a/src/nsmenu.m b/src/nsmenu.m index b7e4cbd565..e313fc03f4 100644 --- a/src/nsmenu.m +++ b/src/nsmenu.m @@ -1092,7 +1092,7 @@ - (Lisp_Object)runMenuAt: (NSPoint)p forFrame: (struct frame *)f continue; } - img_id = lookup_image (f, image); + img_id = lookup_image (f, image, -1); img = IMAGE_FROM_ID (f, img_id); prepare_image_for_display (f, img); diff --git a/src/xdisp.c b/src/xdisp.c index 140d134572..f05fc4cb37 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -5690,7 +5690,7 @@ handle_single_display_spec (struct it *it, Lisp_Object spec, Lisp_Object object, else { it->what = IT_IMAGE; - it->image_id = lookup_image (it->f, value); + it->image_id = lookup_image (it->f, value, it->face_id); it->position = start_pos; it->object = NILP (object) ? it->w->contents : object; it->method = GET_FROM_IMAGE; @@ -22379,7 +22379,7 @@ push_prefix_prop (struct it *it, Lisp_Object prop) else if (IMAGEP (prop)) { it->what = IT_IMAGE; - it->image_id = lookup_image (it->f, prop); + it->image_id = lookup_image (it->f, prop, it->face_id); it->method = GET_FROM_IMAGE; } #endif /* HAVE_WINDOW_SYSTEM */ @@ -27262,7 +27262,7 @@ calc_pixel_width_or_height (double *res, struct it *it, Lisp_Object prop, if (FRAME_WINDOW_P (it->f) && valid_image_p (prop)) { - ptrdiff_t id = lookup_image (it->f, prop); + ptrdiff_t id = lookup_image (it->f, prop, it->face_id); struct image *img = IMAGE_FROM_ID (it->f, id); return OK_PIXELS (width_p ? img->width : img->height); -- 2.26.1 --jRHKVT23PllUwdXP-- From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 07:10:17 2020 Received: (at 40845) by debbugs.gnu.org; 15 May 2020 11:10:17 +0000 Received: from localhost ([127.0.0.1]:35994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZYEK-00075Z-Um for submit@debbugs.gnu.org; Fri, 15 May 2020 07:10:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48046) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZYEJ-00075L-Gh for 40845@debbugs.gnu.org; Fri, 15 May 2020 07:10:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34870) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZYEE-0007pp-7v; Fri, 15 May 2020 07:10:10 -0400 Received: from [176.228.60.248] (port=4981 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZYED-0003nv-4W; Fri, 15 May 2020 07:10:09 -0400 Date: Fri, 15 May 2020 14:09:56 +0300 Message-Id: <835zcx314r.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-Reply-To: <20200509195415.GA44624@breton.holly.idiocy.org> (message from Alan Third on Sat, 9 May 2020 20:54:15 +0100) Subject: Re: bug#40845: SVG rendering issues References: <17307310-2afc-7941-8a48-5cd345d1ad63@gmail.com> <83k1237b2a.fsf@gnu.org> <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> <83r1w1ovc3.fsf@gnu.org> <20200509142727.GA42881@breton.holly.idiocy.org> <20200509195415.GA44624@breton.holly.idiocy.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 9 May 2020 20:54:15 +0100 > From: Alan Third > > On Sat, May 09, 2020 at 03:27:27PM +0100, Alan Third wrote: > > On Sun, May 03, 2020 at 05:24:17PM +0100, Alan Third wrote: > > > > > > I’ve attached a first pass. It solves 1 and 4 from the original bug > > > report: scaling and setting the foreground colour. > > > > Can someone please try the patch from the previous email on a non‐NS > > platform and confirm whether or not the background colour in the image > > matches the background colour of the text? > > > > They don’t match here, but I strongly suspect that’s because the NS > > port uses different colour spaces for images and everything else. > > Apologies, please can someone try the attached patch. I didn't yet have time to try that, but I haven't forgot. Hope the current tsunami on emacs-devel will soon calm down, and I will have more time. From debbugs-submit-bounces@debbugs.gnu.org Fri May 15 17:41:07 2020 Received: (at 40845) by debbugs.gnu.org; 15 May 2020 21:41:07 +0000 Received: from localhost ([127.0.0.1]:39011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZi4p-00021u-DB for submit@debbugs.gnu.org; Fri, 15 May 2020 17:41:07 -0400 Received: from mailout-l3b-97.contactoffice.com ([212.3.242.97]:38336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZi4o-00021H-IO for 40845@debbugs.gnu.org; Fri, 15 May 2020 17:41:06 -0400 Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 4F2E6306C; Fri, 15 May 2020 23:41:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1589578860; s=20200222-6h9o; d=idiocy.org; i=alan@idiocy.org; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To; l=1284; bh=Wl1vbktd3UVCdtxLk8TiXc/pmmB7Dke8pq4ebo4CW1Q=; b=SyYJ4hgVW1Oko3nU3PrACW+fL1P72SlY0SVzhIkI/m3i0bGj7UdiNPIEQLDb3A0w dX5jbOeLMxEXxvsETnlSlMevjuGkg2qm25ynWNVf426+6iNOQR2u844/DEnFo6PMFP+ Bu6ST3hyWNywzd1W+GOlCaekqUlKkRhPym2IeJUyp3qipawdjc/DTx2kvJqBHJFTGk5 N799SgxRhM5gub4+Uu2qXKK2WnVML34Bn9EDW75cPksqJRv5M6kthHsDjEuCKqxnb74 jxcNa63JqrZH7fLw/YL3pALFx8tyrAFr9nxIFkC+IA0d1F/zdZCkOjndB5kIYYLI6mx /BL6JPlbMQ== Received: by smtp.mailfence.com with ESMTPA ; Fri, 15 May 2020 23:40:48 +0200 (CEST) Received: by breton.holly.idiocy.org (Postfix, from userid 501) id B16FE2022CD859; Fri, 15 May 2020 22:40:47 +0100 (BST) Date: Fri, 15 May 2020 23:40:53 +0200 (CEST) From: Alan Third To: Eli Zaretskii Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200515214047.GB55337@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com References: <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> <83r1w1ovc3.fsf@gnu.org> <20200509142727.GA42881@breton.holly.idiocy.org> <20200509195415.GA44624@breton.holly.idiocy.org> <835zcx314r.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <835zcx314r.fsf@gnu.org> X-Spam-Flag: NO X-Spam-Status: No, hits=-2.9 required=4.7 symbols=ALL_TRUSTED, BAYES_00 device=10.2.0.1 X-ContactOffice-Account: com:241649512 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Fri, May 15, 2020 at 02:09:56PM +0300, Eli Zaretskii wrote: > > Date: Sat, 9 May 2020 20:54:15 +0100 > > From: Alan Third > > > > On Sat, May 09, 2020 at 03:27:27PM +0100, Alan Third wrote: > > > On Sun, May 03, 2020 at 05:24:17PM +0100, Alan Third wrote: > > > > > > > > I’ve attached a first pass. It solves 1 and 4 from the original bug > > > > report: scaling and setting the foreground colour. > > > > > > Can someone please try the patch from the previous email on a non‐NS > > > platform and confirm whether or not the background colour in the image > > > matches the background colour of the text? > > > > > > They don’t match here, but I strongly suspect that’s because the NS > > > port uses different colour spaces for images and everything else. > > > > Apologies, please can someone try the attached patch. > > I didn't yet have time to try that, but I haven't forgot. Hope the > current tsunami on emacs-devel will soon calm down, and I will have > more time. Take as long as you need, I'm in no great hurry. I still need to work out how to calculate whether I should be using the mouse face and decide exactly how to handle flushing an image from the cache as it's somewhat broken in that patch. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 22 12:15:30 2020 Received: (at 40845) by debbugs.gnu.org; 22 Aug 2020 16:15:30 +0000 Received: from localhost ([127.0.0.1]:51173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9WAz-0007QV-0g for submit@debbugs.gnu.org; Sat, 22 Aug 2020 12:15:30 -0400 Received: from mailout-l3b-97.contactoffice.com ([212.3.242.97]:46580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9WAt-0007GG-SU for 40845@debbugs.gnu.org; Sat, 22 Aug 2020 12:15:27 -0400 Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 45AABD49; Sat, 22 Aug 2020 18:15:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1598112918; s=20200222-6h9o; d=idiocy.org; i=alan@idiocy.org; h=Date:From:To:Subject:Message-ID:References:MIME-Version:Content-Type:In-Reply-To; l=25903; bh=+7OveJZvlvx7zc8UjNyggH6s8wfdXnrN2B8Q9smFpzI=; b=f1Cc23i7e+Fl84nXGmO7/coW2pqYZWzl9cLTlMFayLopuBgg0jJa8J/aa6FQy5vk e2f3whUnkIDGTsDH5PsUKfzC2naWpaS+iFaO4embBrDBAwCZchmN/pzbB/KkNvWBfKo Td7DXDwi9VkRiwP0qUvWNEqzpjLVUzC1yuW9KI691QNIneItj7dokL00HQ3phl7oU/Q Ja4Q601c9H0C83vYXoYm023yMGXucUHhWemxPTuAFxe68jazuE7sIkEmrmz4yW5bcDp 8EgzOJOzDtFkTKCak8RPpOJMgOkWHD5gLEg1t95lrBuA7t8bMm+gLZZQxRZRZKaVIKr jZngC2o/tQ== Received: by smtp.mailfence.com with ESMTPA ; Sat, 22 Aug 2020 18:15:11 +0200 (CEST) Received: by breton.holly.idiocy.org (Postfix, from userid 501) id 8656F2024C4150; Sat, 22 Aug 2020 17:15:10 +0100 (BST) Date: Sat, 22 Aug 2020 18:15:15 +0200 (CEST) From: Alan Third To: Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200822161510.GB89421@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com References: <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> <83r1w1ovc3.fsf@gnu.org> <20200509142727.GA42881@breton.holly.idiocy.org> <20200509195415.GA44624@breton.holly.idiocy.org> <835zcx314r.fsf@gnu.org> <20200515214047.GB55337@breton.holly.idiocy.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <20200515214047.GB55337@breton.holly.idiocy.org> X-Spam-Flag: NO X-Spam-Status: No, hits=-2.9 required=4.7 symbols=ALL_TRUSTED, BAYES_00 device=10.2.0.1 X-ContactOffice-Account: com:241649512 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40845 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 15, 2020 at 11:40:53PM +0200, Alan Third wrote: > > Take as long as you need, I'm in no great hurry. I still need to work > out how to calculate whether I should be using the mouse face and > decide exactly how to handle flushing an image from the cache as > it's somewhat broken in that patch. I still don't know how to use the mouse face. I couldn't see any way to detect if it's in use when we first load the image in xdisp.c. Most likely I've missed something, but if not then I worry that the easiest fix may be to actually support transparency when we draw to the screen instead of generating background colours when we load the images. I suspect we do it the way we do because it would have been slow on older machines, but modern machines should be able to handle it quickly via XRender and friends. As for the cache I decided to just delete all images that match the image spec, no matter what colours they use. It seems to me to be the safest option, as we don't want users flushing an image from the cache to display an updated version, only for the old one to reappear when the face changes. -- Alan Third --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0001-Set-basic-SVG-attributes-bug-40845.patch" >From e3ef587f86e3fe0fba1de80c070d495e06148c1b Mon Sep 17 00:00:00 2001 From: Alan Third Date: Sun, 3 May 2020 17:09:31 +0100 Subject: [PATCH] Set basic SVG attributes (bug#40845) * test/manual/image-transforms-tests.el: Replace hard-coded colors with defaults. * src/dispextern.h (struct image): * src/image.c (search_image_cache): (xbm_load_image): (xbm_load): (pbm_load): Rename from frame to face where relevant. (svg_load_image): Parse the image to find out the size, then wrap it in another SVG to set a new size and colors, etc. (lookup_image): Use the face colors instead of the frame colors. (search_image_cache): Add ability to ignore the face colors. (uncache_image): Uncache all copies of the image that share the spec, even if the face colors don't match. --- lisp/net/shr.el | 17 --- src/dispextern.h | 6 +- src/gtkutil.c | 2 +- src/image.c | 205 ++++++++++++++++++++------ src/nsmenu.m | 2 +- src/xdisp.c | 6 +- test/manual/image-transforms-tests.el | 50 +++---- 7 files changed, 189 insertions(+), 99 deletions(-) diff --git a/lisp/net/shr.el b/lisp/net/shr.el index ddd8112721..24595301b7 100644 --- a/lisp/net/shr.el +++ b/lisp/net/shr.el @@ -1209,25 +1209,8 @@ shr-parse-image-data ;; that are non-ASCII. (shr-dom-to-xml (libxml-parse-xml-region (point) (point-max)) 'utf-8))) - ;; SVG images often do not have a specified foreground/background - ;; color, so wrap them in styles. - (when (and (display-images-p) - (eq content-type 'image/svg+xml)) - (setq data (svg--wrap-svg data))) (list data content-type))) -(defun svg--wrap-svg (data) - "Add a default foreground colour to SVG images." - (let ((size (image-size (create-image data nil t :scaling 1) t))) - (with-temp-buffer - (insert - (format - " " - (face-foreground 'default) - (car size) (cdr size) - (base64-encode-string data t))) - (buffer-string)))) - (defun shr-image-displayer (content-function) "Return a function to display an image. CONTENT-FUNCTION is a function to retrieve an image for a cid url that diff --git a/src/dispextern.h b/src/dispextern.h index 311867a0c8..88bbb71fb9 100644 --- a/src/dispextern.h +++ b/src/dispextern.h @@ -3056,9 +3056,9 @@ reset_mouse_highlight (Mouse_HLInfo *hlinfo) if necessary. */ unsigned long background; - /* Foreground and background colors of the frame on which the image + /* Foreground and background colors of the face on which the image is created. */ - unsigned long frame_foreground, frame_background; + unsigned long face_foreground, face_background; /* True if this image has a `transparent' background -- that is, is uses an image mask. The accessor macro for this is @@ -3475,7 +3475,7 @@ #define TRY_WINDOW_IGNORE_FONTS_CHANGE (1 << 1) void mark_image_cache (struct image_cache *); bool valid_image_p (Lisp_Object); void prepare_image_for_display (struct frame *, struct image *); -ptrdiff_t lookup_image (struct frame *, Lisp_Object); +ptrdiff_t lookup_image (struct frame *, Lisp_Object, int face_id); #if defined HAVE_X_WINDOWS || defined USE_CAIRO || defined HAVE_NS #define RGB_PIXEL_COLOR unsigned long diff --git a/src/gtkutil.c b/src/gtkutil.c index 1fe160acca..fafd94c0f7 100644 --- a/src/gtkutil.c +++ b/src/gtkutil.c @@ -5113,7 +5113,7 @@ update_frame_tool_bar (struct frame *f) else idx = -1; - img_id = lookup_image (f, image); + img_id = lookup_image (f, image, -1); img = IMAGE_FROM_ID (f, img_id); prepare_image_for_display (f, img); diff --git a/src/image.c b/src/image.c index 123de54ba2..297278ec9a 100644 --- a/src/image.c +++ b/src/image.c @@ -1081,7 +1081,7 @@ DEFUN ("image-size", Fimage_size, Simage_size, 1, 3, 0, if (valid_image_p (spec)) { struct frame *f = decode_window_system_frame (frame); - ptrdiff_t id = lookup_image (f, spec); + ptrdiff_t id = lookup_image (f, spec, -1); struct image *img = IMAGE_FROM_ID (f, id); int width = img->width + 2 * img->hmargin; int height = img->height + 2 * img->vmargin; @@ -1111,7 +1111,7 @@ DEFUN ("image-mask-p", Fimage_mask_p, Simage_mask_p, 1, 2, 0, if (valid_image_p (spec)) { struct frame *f = decode_window_system_frame (frame); - ptrdiff_t id = lookup_image (f, spec); + ptrdiff_t id = lookup_image (f, spec, -1); struct image *img = IMAGE_FROM_ID (f, id); if (img->mask) mask = Qt; @@ -1134,7 +1134,7 @@ DEFUN ("image-metadata", Fimage_metadata, Simage_metadata, 1, 2, 0, if (valid_image_p (spec)) { struct frame *f = decode_window_system_frame (frame); - ptrdiff_t id = lookup_image (f, spec); + ptrdiff_t id = lookup_image (f, spec, -1); struct image *img = IMAGE_FROM_ID (f, id); ext = img->lisp_data; } @@ -1611,7 +1611,9 @@ equal_lists (Lisp_Object a, Lisp_Object b) /* Find an image matching SPEC in the cache, and return it. If no image is found, return NULL. */ static struct image * -search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash) +search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash, + unsigned long foreground, unsigned long background, + bool ignore_colors) { struct image *img; struct image_cache *c = FRAME_IMAGE_CACHE (f); @@ -1634,8 +1636,8 @@ search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash) for (img = c->buckets[i]; img; img = img->next) if (img->hash == hash && equal_lists (img->spec, spec) - && img->frame_foreground == FRAME_FOREGROUND_PIXEL (f) - && img->frame_background == FRAME_BACKGROUND_PIXEL (f)) + && (ignore_colors || (img->face_foreground == foreground + && img->face_background == background))) break; return img; } @@ -1646,8 +1648,13 @@ search_image_cache (struct frame *f, Lisp_Object spec, EMACS_UINT hash) static void uncache_image (struct frame *f, Lisp_Object spec) { - struct image *img = search_image_cache (f, spec, sxhash (spec)); - if (img) + struct image *img; + + /* Because the background colors are based on the current face, we + can have multiple copies of an image with the same spec. We want + to remove them all to ensure the user doesn't see an old version + of the image when the face changes. */ + while ((img = search_image_cache (f, spec, sxhash (spec), 0, 0, true))) { free_image (f, img); /* As display glyphs may still be referring to the image ID, we @@ -2133,7 +2140,17 @@ image_set_transform (struct frame *f, struct image *img) /* Determine size. */ int width, height; - compute_image_size (img->width, img->height, img->spec, &width, &height); + +#ifdef HAVE_RSVG + /* SVGs are pre-scaled to the correct size. */ + if (EQ (image_spec_value (img->spec, QCtype, NULL), Qsvg)) + { + width = img->width; + height = img->height; + } + else +#endif + compute_image_size (img->width, img->height, img->spec, &width, &height); /* Determine rotation. */ double rotation = 0.0; @@ -2312,11 +2329,16 @@ image_set_transform (struct frame *f, struct image *img) SPEC must be a valid Lisp image specification (see valid_image_p). */ ptrdiff_t -lookup_image (struct frame *f, Lisp_Object spec) +lookup_image (struct frame *f, Lisp_Object spec, int face_id) { struct image *img; EMACS_UINT hash; + struct face *face = (face_id >= 0) ? FACE_FROM_ID (f, face_id) + : FACE_FROM_ID_OR_NULL (f, DEFAULT_FACE_ID); + unsigned long foreground = FACE_COLOR_TO_PIXEL (face->foreground, f); + unsigned long background = FACE_COLOR_TO_PIXEL (face->background, f); + /* F must be a window-system frame, and SPEC must be a valid image specification. */ eassert (FRAME_WINDOW_P (f)); @@ -2324,7 +2346,7 @@ lookup_image (struct frame *f, Lisp_Object spec) /* Look up SPEC in the hash table of the image cache. */ hash = sxhash (spec); - img = search_image_cache (f, spec, hash); + img = search_image_cache (f, spec, hash, foreground, background, true); if (img && img->load_failed_p) { free_image (f, img); @@ -2337,9 +2359,9 @@ lookup_image (struct frame *f, Lisp_Object spec) block_input (); img = make_image (spec, hash); cache_image (f, img); + img->face_foreground = foreground; + img->face_background = background; img->load_failed_p = ! img->type->load (f, img); - img->frame_foreground = FRAME_FOREGROUND_PIXEL (f); - img->frame_background = FRAME_BACKGROUND_PIXEL (f); /* If we can't load the image, and we don't have a width and height, use some arbitrary width and height so that we can @@ -2393,8 +2415,7 @@ lookup_image (struct frame *f, Lisp_Object spec) if (!NILP (bg)) { img->background - = image_alloc_image_color (f, img, bg, - FRAME_BACKGROUND_PIXEL (f)); + = image_alloc_image_color (f, img, bg, background); img->background_valid = 1; } } @@ -3667,8 +3688,8 @@ xbm_load_image (struct frame *f, struct image *img, char *contents, char *end) &data, 0); if (rc) { - unsigned long foreground = FRAME_FOREGROUND_PIXEL (f); - unsigned long background = FRAME_BACKGROUND_PIXEL (f); + unsigned long foreground = img->face_foreground; + unsigned long background = img->face_background; bool non_default_colors = 0; Lisp_Object value; @@ -3764,8 +3785,8 @@ xbm_load (struct frame *f, struct image *img) { struct image_keyword fmt[XBM_LAST]; Lisp_Object data; - unsigned long foreground = FRAME_FOREGROUND_PIXEL (f); - unsigned long background = FRAME_BACKGROUND_PIXEL (f); + unsigned long foreground = img->face_foreground; + unsigned long background = img->face_background; bool non_default_colors = 0; char *bits; bool parsed_p; @@ -6125,8 +6146,8 @@ pbm_load (struct frame *f, struct image *img) unsigned char c = 0; int g; struct image_keyword fmt[PBM_LAST]; - unsigned long fg = FRAME_FOREGROUND_PIXEL (f); - unsigned long bg = FRAME_BACKGROUND_PIXEL (f); + unsigned long fg = img->face_foreground; + unsigned long bg = img->face_background; /* Parse the image specification. */ memcpy (fmt, pbm_format, sizeof fmt); parse_image_spec (img->spec, fmt, PBM_LAST, Qpbm); @@ -9433,6 +9454,7 @@ DEFUN ("imagemagick-types", Fimagemagick_types, Simagemagick_types, 0, 0, 0, SVG_ALGORITHM, SVG_HEURISTIC_MASK, SVG_MASK, + SVG_FOREGROUND, SVG_BACKGROUND, SVG_LAST }; @@ -9451,6 +9473,7 @@ DEFUN ("imagemagick-types", Fimagemagick_types, Simagemagick_types, 0, 0, 0, {":conversion", IMAGE_DONT_CHECK_VALUE_TYPE, 0}, {":heuristic-mask", IMAGE_DONT_CHECK_VALUE_TYPE, 0}, {":mask", IMAGE_DONT_CHECK_VALUE_TYPE, 0}, + {":foreground", IMAGE_STRING_OR_NIL_VALUE, 0}, {":background", IMAGE_STRING_OR_NIL_VALUE, 0} }; @@ -9715,6 +9738,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents, int height; const guint8 *pixels; int rowstride; + char *wrapped_contents = NULL; + ptrdiff_t wrapped_size; #if ! GLIB_CHECK_VERSION (2, 36, 0) /* g_type_init is a glib function that must be called prior to @@ -9722,6 +9747,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents, g_type_init (); #endif + /* Parse the unmodified SVG data so we can get it's initial size. */ + #if LIBRSVG_CHECK_VERSION (2, 32, 0) GInputStream *input_stream = g_memory_input_stream_new_from_data (contents, size, NULL); @@ -9750,6 +9777,107 @@ svg_load_image (struct frame *f, struct image *img, char *contents, rsvg_handle_write (rsvg_handle, (unsigned char *) contents, size, &err); if (err) goto rsvg_error; + /* The parsing is complete, rsvg_handle is ready to used, close it + for further writes. */ + rsvg_handle_close (rsvg_handle, &err); + if (err) goto rsvg_error; +#endif + + /* Get the image dimensions. */ + rsvg_handle_get_dimensions (rsvg_handle, &dimension_data); + + /* We are now done with the unmodified data. */ + g_object_unref (rsvg_handle); + + /* Calculate the final image size. */ + compute_image_size (dimension_data.width, dimension_data.height, + img->spec, &width, &height); + + /* Wrap the SVG data in another SVG. This allows us to set the + width and height, as well as modify the foreground and background + colors. */ + { + Lisp_Object value; + unsigned long foreground = img->face_foreground; + unsigned long background = img->face_background; + + Lisp_Object encoded_contents = Fbase64_encode_string + (make_unibyte_string (contents, size), Qt); + + /* The wrapper sets the foreground color, width and height, and + viewBox must contain the dimensions of the original image. It + also draws a rectangle over the whole space, set to the + background color, before including the original image. This + acts to set the background color, instead of leaving it + transparent. */ + const char *wrapper = + "" + "" + "" + ""; + + /* FIXME: I've added 64 in the hope it will cover the size of the + width and height strings and things. */ + int buffer_size = SBYTES (encoded_contents) + strlen (wrapper) + 64; + + value = image_spec_value (img->spec, QCforeground, NULL); + if (!NILP (value)) + { + foreground = image_alloc_image_color (f, img, value, img->face_foreground); + } + value = image_spec_value (img->spec, QCbackground, NULL); + if (!NILP (value)) + { + background = image_alloc_image_color (f, img, value, img->face_background); + img->background = background; + img->background_valid = 1; + } + + wrapped_contents = malloc (buffer_size); + + if (!wrapped_contents + || buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper, + foreground & 0xFFFFFF, width, height, + dimension_data.width, dimension_data.height, + background & 0xFFFFFF, SSDATA (encoded_contents))) + goto rsvg_error; + + wrapped_size = strlen (wrapped_contents); + } + + /* Now we parse the wrapped version. */ + +#if LIBRSVG_CHECK_VERSION (2, 32, 0) + input_stream = g_memory_input_stream_new_from_data (wrapped_contents, wrapped_size, NULL); + base_file = filename ? g_file_new_for_path (filename) : NULL; + rsvg_handle = rsvg_handle_new_from_stream_sync (input_stream, base_file, + RSVG_HANDLE_FLAGS_NONE, + NULL, &err); + if (base_file) + g_object_unref (base_file); + g_object_unref (input_stream); + + /* Check rsvg_handle too, to avoid librsvg 2.40.13 bug (Bug#36773#26). */ + if (!rsvg_handle || err) goto rsvg_error; +#else + /* Make a handle to a new rsvg object. */ + rsvg_handle = rsvg_handle_new (); + eassume (rsvg_handle); + + /* Set base_uri for properly handling referenced images (via 'href'). + See rsvg bug 596114 - "image refs are relative to curdir, not .svg file" + . */ + if (filename) + rsvg_handle_set_base_uri (rsvg_handle, filename); + + /* Parse the contents argument and fill in the rsvg_handle. */ + rsvg_handle_write (rsvg_handle, (unsigned char *) wrapped_contents, wrapped_size, &err); + if (err) goto rsvg_error; + /* The parsing is complete, rsvg_handle is ready to used, close it for further writes. */ rsvg_handle_close (rsvg_handle, &err); @@ -9768,6 +9896,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents, pixbuf = rsvg_handle_get_pixbuf (rsvg_handle); if (!pixbuf) goto rsvg_error; g_object_unref (rsvg_handle); + free (wrapped_contents); /* Extract some meta data from the svg handle. */ width = gdk_pixbuf_get_width (pixbuf); @@ -9792,25 +9921,6 @@ svg_load_image (struct frame *f, struct image *img, char *contents, init_color_table (); - /* Handle alpha channel by combining the image with a background - color. */ - Emacs_Color background; - Lisp_Object specified_bg = image_spec_value (img->spec, QCbackground, NULL); - if (!STRINGP (specified_bg) - || !FRAME_TERMINAL (f)->defined_color_hook (f, - SSDATA (specified_bg), - &background, - false, - false)) - FRAME_TERMINAL (f)->query_frame_background_color (f, &background); - - /* SVG pixmaps specify transparency in the last byte, so right - shift 8 bits to get rid of it, since emacs doesn't support - transparency. */ - background.red >>= 8; - background.green >>= 8; - background.blue >>= 8; - /* This loop handles opacity values, since Emacs assumes non-transparent images. Each pixel must be "flattened" by calculating the resulting color, given the transparency of the @@ -9822,16 +9932,11 @@ svg_load_image (struct frame *f, struct image *img, char *contents, int red = *pixels++; int green = *pixels++; int blue = *pixels++; - int opacity = *pixels++; - red = ((red * opacity) - + (background.red * ((1 << 8) - opacity))); - green = ((green * opacity) - + (background.green * ((1 << 8) - opacity))); - blue = ((blue * opacity) - + (background.blue * ((1 << 8) - opacity))); + /* Skip opacity. */ + pixels++; - PUT_PIXEL (ximg, x, y, lookup_rgb_color (f, red, green, blue)); + PUT_PIXEL (ximg, x, y, lookup_rgb_color (f, red << 8, green << 8, blue << 8)); } pixels += rowstride - 4 * width; @@ -9861,6 +9966,8 @@ svg_load_image (struct frame *f, struct image *img, char *contents, rsvg_error: if (rsvg_handle) g_object_unref (rsvg_handle); + if (wrapped_contents) + free (wrapped_contents); /* FIXME: Use error->message so the user knows what is the actual problem with the image. */ image_error ("Error parsing SVG image `%s'", img->spec); @@ -10159,7 +10266,7 @@ DEFUN ("lookup-image", Flookup_image, Slookup_image, 1, 1, 0, ptrdiff_t id = -1; if (valid_image_p (spec)) - id = lookup_image (SELECTED_FRAME (), spec); + id = lookup_image (SELECTED_FRAME (), spec, -1); debug_print (spec); return make_fixnum (id); diff --git a/src/nsmenu.m b/src/nsmenu.m index b7e4cbd565..e313fc03f4 100644 --- a/src/nsmenu.m +++ b/src/nsmenu.m @@ -1092,7 +1092,7 @@ - (Lisp_Object)runMenuAt: (NSPoint)p forFrame: (struct frame *)f continue; } - img_id = lookup_image (f, image); + img_id = lookup_image (f, image, -1); img = IMAGE_FROM_ID (f, img_id); prepare_image_for_display (f, img); diff --git a/src/xdisp.c b/src/xdisp.c index ad03ac4605..764d5345f2 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -5696,7 +5696,7 @@ handle_single_display_spec (struct it *it, Lisp_Object spec, Lisp_Object object, else { it->what = IT_IMAGE; - it->image_id = lookup_image (it->f, value); + it->image_id = lookup_image (it->f, value, it->face_id); it->position = start_pos; it->object = NILP (object) ? it->w->contents : object; it->method = GET_FROM_IMAGE; @@ -22434,7 +22434,7 @@ push_prefix_prop (struct it *it, Lisp_Object prop) else if (IMAGEP (prop)) { it->what = IT_IMAGE; - it->image_id = lookup_image (it->f, prop); + it->image_id = lookup_image (it->f, prop, it->face_id); it->method = GET_FROM_IMAGE; } #endif /* HAVE_WINDOW_SYSTEM */ @@ -27335,7 +27335,7 @@ calc_pixel_width_or_height (double *res, struct it *it, Lisp_Object prop, if (FRAME_WINDOW_P (it->f) && valid_image_p (prop)) { - ptrdiff_t id = lookup_image (it->f, prop); + ptrdiff_t id = lookup_image (it->f, prop, it->face_id); struct image *img = IMAGE_FROM_ID (it->f, id); return OK_PIXELS (width_p ? img->width : img->height); diff --git a/test/manual/image-transforms-tests.el b/test/manual/image-transforms-tests.el index 0ebd5c7a19..02607e6367 100644 --- a/test/manual/image-transforms-tests.el +++ b/test/manual/image-transforms-tests.el @@ -48,24 +48,24 @@ test-cropping (let ((image " - - + style='fill:none;stroke-width:1;stroke:currentColor'/> + + + style='fill:none;stroke-width:1;stroke:currentColor'/> ") (top-left " ") (middle " - - + style='fill:none;stroke-width:1;stroke:currentColor'/> + + ") (bottom-right " + style='fill:none;stroke-width:1;stroke:currentColor'/> ")) (insert-header "Test Crop: cropping an image (only works with ImageMagick)") (insert-test "all params" top-left image '(:crop (10 10 0 0))) @@ -77,23 +77,23 @@ test-cropping (defun test-scaling () (let ((image " - - + style='fill:none;stroke-width:1;stroke:currentColor'/> + + ") (large " + style='fill:none;stroke-width:2;stroke:currentColor'/> + style='stroke-width:2;stroke:currentColor'/> + style='stroke-width:2;stroke:currentColor'/> ") (small " - - + style='fill:none;stroke-width:1;stroke:currentColor'/> + + ")) (insert-header "Test Scaling: resize an image (pixelization may occur)") (insert-test "1x" image image '(:scale 1)) @@ -107,27 +107,27 @@ test-scaling (defun test-scaling-rotation () (let ((image " + style='fill:none;stroke-width:1;stroke:currentColor'/> + style='fill:currentColor'/> ") (x2-90 " + style='fill:none;stroke-width:1;stroke:currentColor'/> + style='fill:currentColor'/> ") (x2--90 " + style='fill:none;stroke-width:1;stroke:currentColor'/> + style='fill:currentColor'/> ") (x0.5-180 " + style='fill:none;stroke-width:1;stroke:currentColor'/> + style='fill:currentColor'/> ")) (insert-header "Test Scaling and Rotation: resize and rotate an image (pixelization may occur)") (insert-test "1x, 0 degrees" image image '(:scale 1 :rotation 0)) -- 2.26.1 --HcAYCG3uE/tztfnV-- From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 22 12:29:02 2020 Received: (at 40845) by debbugs.gnu.org; 22 Aug 2020 16:29:02 +0000 Received: from localhost ([127.0.0.1]:51222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9WO6-00019l-9s for submit@debbugs.gnu.org; Sat, 22 Aug 2020 12:29:02 -0400 Received: from quimby.gnus.org ([95.216.78.240]:37642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9WO4-00019M-Hb for 40845@debbugs.gnu.org; Sat, 22 Aug 2020 12:29:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=iRvKFsH1kS2X0YwlomTKh++TlabqZfwhXTs/5nB4MeM=; b=PMSfRX/KZEcv48yiZoYCaQ6o0I SHVXb8GWJ71VFoZMqIaSINr4HoUvk8hrBmWGNpOp0qXArw0VwfOpfQbMDbxCTJVzCQqlEctUSjfkD NFy9ZEAT0E8UaSnIvDkD/baf1ALnxe56rWKx4ahD0FGcNhC13bCo9Ax0jZt67trt0nd4=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k9WNv-000121-8O; Sat, 22 Aug 2020 18:28:53 +0200 From: Lars Ingebrigtsen To: Alan Third Subject: Re: bug#40845: SVG rendering issues References: <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> <83r1w1ovc3.fsf@gnu.org> <20200509142727.GA42881@breton.holly.idiocy.org> <20200509195415.GA44624@breton.holly.idiocy.org> <835zcx314r.fsf@gnu.org> <20200515214047.GB55337@breton.holly.idiocy.org> <20200822161510.GB89421@breton.holly.idiocy.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAIVBMVEX+/f7f1N6pnLSO b5FjV2k2L1AUFBs6W5+7qDlbmdf////Dr5ctAAAAAWJLR0QKaND0VgAAAAd0SU1FB+QIFhATNrZw x80AAAGpSURBVDjLpZPPTuMwEMZTdsW5KX/Oxam04lbiPEBpxuW62vU4cLe9PACu1SsCyXcOVd6W Ca1raHNg4TtEyfw8nvEXT5Z9XSOWD7P8MD4oWTnOWA8YD8orVvaBjJUXfRlTAtNRD5hlfD7ry6h5 Of/TUyPL8+GQGv6mJjUnVQA1AHB+FeM/7Z5ipXOLSJ8SarEBswgMIiprtEFr0KDagRvvOqIp2CHc ASka7xElamWtaVIG7eS9rz029NZ4F8GZFASgLr13tMCp3xHQugdACf5NmIAwuJQA8teGLBNAXEhZ yeIBnJFpq1OgFGEWOjzJhTULuwNSKOpf6fvQnVPZVFwopa3VKjyTIcbEdk/I2Aqs/StuAzUIMoGC TLeW8/vwRMaLCE45LLstoFIh3EDy6mxNzXeOo6AUkdwl0LbtS4d0CO8yzn3TdvLOmvC4dgms7tqN 1qtLeiTb/7VJa79y8YDH5gPwahpvp6Ial7u40+ne5h/0uXu6Hb7BAdgOxo8DcMEY42w4qeb7GePi aHQynZR8D1Szyahg1xXfH7ai5gTot/RM4UafO8R/6RUjdKzc4FUX+QAAACV0RVh0ZGF0ZTpjcmVh dGUAMjAyMC0wOC0yMlQxNjoxOTo1NCswMDowMOp/LgUAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjAt MDgtMjJUMTY6MTk6NTQrMDA6MDCbIpa5AAAAAElFTkSuQmCC X-Now-Playing: Old's _Formula_: "Break [You]" Date: Sat, 22 Aug 2020 18:28:49 +0200 In-Reply-To: <20200822161510.GB89421@breton.holly.idiocy.org> (Alan Third's message of "Sat, 22 Aug 2020 18:15:15 +0200 (CEST)") Message-ID: <87a6ymir0e.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Alan Third writes: > As for the cache I decided to just delete all images that match the > image spec, no matter what colours they use. It seems to me to be the > safest option, as we don't want users flushing an image [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845 Cc: Eli Zaretskii , cpitclaudel@gmail.com, pipcet@gmail.com, 40845@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Third writes: > As for the cache I decided to just delete all images that match the > image spec, no matter what colours they use. It seems to me to be the > safest option, as we don't want users flushing an image from the > cache to display an updated version, only for the old one to reappear > when the face changes. Makes sense. I've tried your patch set, and it fixes the test case in this bug report for me (under Debian). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 22 12:55:06 2020 Received: (at 40845) by debbugs.gnu.org; 22 Aug 2020 16:55:06 +0000 Received: from localhost ([127.0.0.1]:51281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9WnK-00043n-DX for submit@debbugs.gnu.org; Sat, 22 Aug 2020 12:55:06 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9WnH-00042z-RF for 40845@debbugs.gnu.org; Sat, 22 Aug 2020 12:55:04 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40358) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9WnB-0007OZ-GD; Sat, 22 Aug 2020 12:54:57 -0400 Received: from [176.228.60.248] (port=4936 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k9WnA-0004EH-Uw; Sat, 22 Aug 2020 12:54:57 -0400 Date: Sat, 22 Aug 2020 19:54:48 +0300 Message-Id: <835z9aaaef.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-Reply-To: <20200822161510.GB89421@breton.holly.idiocy.org> (message from Alan Third on Sat, 22 Aug 2020 18:15:15 +0200 (CEST)) Subject: Re: bug#40845: SVG rendering issues References: <20200425174651.GC82687@breton.holly.idiocy.org> <20200426211741.GA93046@breton.holly.idiocy.org> <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> <83r1w1ovc3.fsf@gnu.org> <20200509142727.GA42881@breton.holly.idiocy.org> <20200509195415.GA44624@breton.holly.idiocy.org> <835zcx314r.fsf@gnu.org> <20200515214047.GB55337@breton.holly.idiocy.org> <20200822161510.GB89421@breton.holly.idiocy.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 22 Aug 2020 18:15:15 +0200 (CEST) > From: Alan Third > > I still don't know how to use the mouse face. I couldn't see any way > to detect if it's in use when we first load the image in xdisp.c. Can you please remind me what was the problem? The bug discussion is very long, and I didn't have time/patience to find the mouse face bits. > -ptrdiff_t lookup_image (struct frame *, Lisp_Object); > +ptrdiff_t lookup_image (struct frame *, Lisp_Object, int face_id); ^^^^^^^^^^^ Please don't use names in prototypes, only types. > + /* Parse the unmodified SVG data so we can get it's initial size. */ ^^^^ "its" > + /* The parsing is complete, rsvg_handle is ready to used, close it ^^^^^^^^^^^^^^^^ "is ready to be used" > + background color, before including the original image. This ^^ Two spaces between sentences, please. > + Lisp_Object encoded_contents = Fbase64_encode_string > + (make_unibyte_string (contents, size), Qt); Our style of breaking long lines like this one is different: Lisp_Object encoded_contents = Fbase64_encode_string (make_unibyte_string (contents, size), Qt); > + if (!NILP (value)) > + { > + foreground = image_alloc_image_color (f, img, value, img->face_foreground); > + } No need for braces when the block has only one line. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 22 14:58:11 2020 Received: (at 40845) by debbugs.gnu.org; 22 Aug 2020 18:58:11 +0000 Received: from localhost ([127.0.0.1]:51471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9YiR-0000wq-1o for submit@debbugs.gnu.org; Sat, 22 Aug 2020 14:58:11 -0400 Received: from mailout-l3b-97.contactoffice.com ([212.3.242.97]:48558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9YiM-0000wI-RZ for 40845@debbugs.gnu.org; Sat, 22 Aug 2020 14:58:09 -0400 Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 51BAC430; Sat, 22 Aug 2020 20:58:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1598122680; s=20200222-6h9o; d=idiocy.org; i=alan@idiocy.org; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:In-Reply-To; l=1231; bh=ChAP6KyX1Fh1ETMCjvvE2KxFizVuBX+16FlTjQyTkxw=; b=m/1HPANgxxwDt9O+mNyGBb9YUoh0yaQon1yajeapdsYVzPNdpZxajekssytVQnfD npbWSHKd4zp3xOp91TzYote3FhZg1RtyQMY4tU3+/4UxWhA04LT4DEHLqy267N0/aMc D3TCLyQBVGqhuWNBQE5A2lXlsZKACCpPeGx973VMIXEHHxl5LVmVNlBQ2/TfPTcaAVj +Hiiu5J8JPqKQlqWBdi+jQ+Asq5hR1VaITgaaIBke8wMhzdbS+6QHo5TnmdkAGV//hv XBeFDOXzO8czybCBATBTbqcWIRHGAzDllQG/WQeYBYazYToKExVErceA2q0wYOdKjZ7 UH580Md94w== Received: by smtp.mailfence.com with ESMTPA ; Sat, 22 Aug 2020 20:57:57 +0200 (CEST) Received: by breton.holly.idiocy.org (Postfix, from userid 501) id 62B3C2024C593E; Sat, 22 Aug 2020 19:57:56 +0100 (BST) Date: Sat, 22 Aug 2020 20:57:59 +0200 (CEST) From: Alan Third To: Eli Zaretskii Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200822185756.GC89421@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com References: <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> <83r1w1ovc3.fsf@gnu.org> <20200509142727.GA42881@breton.holly.idiocy.org> <20200509195415.GA44624@breton.holly.idiocy.org> <835zcx314r.fsf@gnu.org> <20200515214047.GB55337@breton.holly.idiocy.org> <20200822161510.GB89421@breton.holly.idiocy.org> <835z9aaaef.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <835z9aaaef.fsf@gnu.org> X-Spam-Flag: NO X-Spam-Status: No, hits=-2.9 required=4.7 symbols=ALL_TRUSTED, BAYES_00 device=10.2.0.1 X-ContactOffice-Account: com:241649512 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Sat, Aug 22, 2020 at 07:54:48PM +0300, Eli Zaretskii wrote: > > Date: Sat, 22 Aug 2020 18:15:15 +0200 (CEST) > > From: Alan Third > > > > I still don't know how to use the mouse face. I couldn't see any way > > to detect if it's in use when we first load the image in xdisp.c. > > Can you please remind me what was the problem? The bug discussion is > very long, and I didn't have time/patience to find the mouse face > bits. No problem. Basically, if you try Clement's original example, when you move the mouse over the image the background colour doesn't change to match the rest of the line. I'm picking up the background colour from the face stored in "it" in push_prefix_prop or handle_single_display_spec in xdisp.c. As far as I can tell one or both of these are the only places we can define the image with the face colours as this is where we actually load the image. The problem is that I don't see any way to work out if the current image should use the background colour from the mouse face. I know that later on we can do (s->hl == DRAW_MOUSE_FACE), but I don't think those structures are built yet? I've fixed the mistakes you pointed out. Thanks. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 22 15:18:12 2020 Received: (at 40845) by debbugs.gnu.org; 22 Aug 2020 19:18:12 +0000 Received: from localhost ([127.0.0.1]:51508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9Z1o-0003i6-C9 for submit@debbugs.gnu.org; Sat, 22 Aug 2020 15:18:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9Z1m-0003hr-Ch for 40845@debbugs.gnu.org; Sat, 22 Aug 2020 15:18:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41926) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9Z1g-0006Vd-Cm; Sat, 22 Aug 2020 15:18:04 -0400 Received: from [176.228.60.248] (port=1794 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k9Z1f-0006zF-QG; Sat, 22 Aug 2020 15:18:04 -0400 Date: Sat, 22 Aug 2020 22:17:53 +0300 Message-Id: <83y2m68p7i.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-Reply-To: <20200822185756.GC89421@breton.holly.idiocy.org> (message from Alan Third on Sat, 22 Aug 2020 20:57:59 +0200 (CEST)) Subject: Re: bug#40845: SVG rendering issues References: <09a19c49-91cb-8024-8c34-53d846d98313@gmail.com> <20200503141348.GA4071@breton.holly.idiocy.org> <83r1w1ovc3.fsf@gnu.org> <20200509142727.GA42881@breton.holly.idiocy.org> <20200509195415.GA44624@breton.holly.idiocy.org> <835zcx314r.fsf@gnu.org> <20200515214047.GB55337@breton.holly.idiocy.org> <20200822161510.GB89421@breton.holly.idiocy.org> <835z9aaaef.fsf@gnu.org> <20200822185756.GC89421@breton.holly.idiocy.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 22 Aug 2020 20:57:59 +0200 (CEST) > From: Alan Third > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com > > Basically, if you try Clement's original example, when you move the > mouse over the image the background colour doesn't change to match the > rest of the line. > > I'm picking up the background colour from the face stored in "it" in > push_prefix_prop or handle_single_display_spec in xdisp.c. As far as I > can tell one or both of these are the only places we can define the > image with the face colours as this is where we actually load the > image. The problem is that I don't see any way to work out if the > current image should use the background colour from the mouse face. > > I know that later on we can do (s->hl == DRAW_MOUSE_FACE), but I don't > think those structures are built yet? I think you want to modify note_mouse_highlight so that it sets up the frame's mouse-highlight info for image glyphs, like it currently does for character glyphs. It's possible this is all that needs to be done; if not, we should see how to change show_mouse_face and its subroutines to display images with mouse-highlight. Let me know if you need more guidance. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 22 17:35:58 2020 Received: (at 40845) by debbugs.gnu.org; 22 Aug 2020 21:35:58 +0000 Received: from localhost ([127.0.0.1]:51630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9bB7-000319-OO for submit@debbugs.gnu.org; Sat, 22 Aug 2020 17:35:57 -0400 Received: from mailout-l3b-97.contactoffice.com ([212.3.242.97]:50092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9bB5-00030n-Cq for 40845@debbugs.gnu.org; Sat, 22 Aug 2020 17:35:56 -0400 Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 09A161D53; Sat, 22 Aug 2020 23:35:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1598132149; s=20200222-6h9o; d=idiocy.org; i=alan@idiocy.org; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:In-Reply-To; l=2028; bh=0fPzOXlB3kL0v4GkidEJXn36kLve40wW3pejnKke5JU=; b=vRtoNihCJ/K5eJCB/OUGjiYAXn3GlUwloz5ru4PUmc6TiI0s1cWJpwNrJA7y9STd 0+XoWDnKIB+cBFaXSy1j8+Q2o/FPL6W58wE9GCS3nFEy2ExTZLW3wtP1OzY5uMMlmMw Okt4zaaQbkTqHwVmxkhhjrqs17FNIzqVT4618trQy+wXzXEEVgf2TTUpn/kiXqujxOJ TPQ9yzolybqfrH6Uilhjk6CZYwm0kt7jrQzCnehp86tXPg/OnuRTgz09Oq285wGw/Ix ZcxHIgZd7ooJNW3V6FgoYL4oktLQT3TR+hD1LWNXZtcFT3gydo2Lu0J7SVAX08VlG3n D93arj94qg== Received: by smtp.mailfence.com with ESMTPA ; Sat, 22 Aug 2020 23:35:44 +0200 (CEST) Received: by breton.holly.idiocy.org (Postfix, from userid 501) id 455B22024C79CE; Sat, 22 Aug 2020 22:35:43 +0100 (BST) Date: Sat, 22 Aug 2020 23:35:46 +0200 (CEST) From: Alan Third To: Eli Zaretskii Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200822213543.GD89421@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com References: <83r1w1ovc3.fsf@gnu.org> <20200509142727.GA42881@breton.holly.idiocy.org> <20200509195415.GA44624@breton.holly.idiocy.org> <835zcx314r.fsf@gnu.org> <20200515214047.GB55337@breton.holly.idiocy.org> <20200822161510.GB89421@breton.holly.idiocy.org> <835z9aaaef.fsf@gnu.org> <20200822185756.GC89421@breton.holly.idiocy.org> <83y2m68p7i.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83y2m68p7i.fsf@gnu.org> X-Spam-Flag: NO X-Spam-Status: No, hits=-2.9 required=4.7 symbols=ALL_TRUSTED, BAYES_00 device=10.2.0.1 X-ContactOffice-Account: com:241649512 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Sat, Aug 22, 2020 at 10:17:53PM +0300, Eli Zaretskii wrote: > > Date: Sat, 22 Aug 2020 20:57:59 +0200 (CEST) > > From: Alan Third > > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com > > > > Basically, if you try Clement's original example, when you move the > > mouse over the image the background colour doesn't change to match the > > rest of the line. > > > > I'm picking up the background colour from the face stored in "it" in > > push_prefix_prop or handle_single_display_spec in xdisp.c. As far as I > > can tell one or both of these are the only places we can define the > > image with the face colours as this is where we actually load the > > image. The problem is that I don't see any way to work out if the > > current image should use the background colour from the mouse face. > > > > I know that later on we can do (s->hl == DRAW_MOUSE_FACE), but I don't > > think those structures are built yet? > > I think you want to modify note_mouse_highlight so that it sets up the > frame's mouse-highlight info for image glyphs, like it currently does > for character glyphs. It's possible this is all that needs to be > done; if not, we should see how to change show_mouse_face and its > subroutines to display images with mouse-highlight. > > Let me know if you need more guidance. Thanks for your help, and that certainly helped me understand a bit more about how mouse highlighting works and I don't think setting the background colour from a face is a practical way of doing this. But I've just realised we don't need to do it. Masks provide this functionality. If you want the background of your SVG to match the background of the buffer, use a mask, which can be keyed off a specific colour or whatever. Unfortunately it won't work well for semi-transparent images, but I think the only really practical solution for that is to introduce proper transparency handling. Therefore I think this patch is ready to go. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 23 01:47:42 2020 Received: (at 40845) by debbugs.gnu.org; 23 Aug 2020 05:47:42 +0000 Received: from localhost ([127.0.0.1]:51927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9ir0-0008WI-49 for submit@debbugs.gnu.org; Sun, 23 Aug 2020 01:47:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44458) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9iqy-0008W4-7m for 40845@debbugs.gnu.org; Sun, 23 Aug 2020 01:47:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49978) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9iqs-0002oj-DH; Sun, 23 Aug 2020 01:47:34 -0400 Received: from [176.228.60.248] (port=4340 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k9iqr-00005o-SE; Sun, 23 Aug 2020 01:47:34 -0400 Date: Sun, 23 Aug 2020 08:47:27 +0300 Message-Id: <83tuwt9amo.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-Reply-To: <20200822213543.GD89421@breton.holly.idiocy.org> (message from Alan Third on Sat, 22 Aug 2020 23:35:46 +0200 (CEST)) Subject: Re: bug#40845: SVG rendering issues References: <83r1w1ovc3.fsf@gnu.org> <20200509142727.GA42881@breton.holly.idiocy.org> <20200509195415.GA44624@breton.holly.idiocy.org> <835zcx314r.fsf@gnu.org> <20200515214047.GB55337@breton.holly.idiocy.org> <20200822161510.GB89421@breton.holly.idiocy.org> <835z9aaaef.fsf@gnu.org> <20200822185756.GC89421@breton.holly.idiocy.org> <83y2m68p7i.fsf@gnu.org> <20200822213543.GD89421@breton.holly.idiocy.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 22 Aug 2020 23:35:46 +0200 (CEST) > From: Alan Third > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com > > Therefore I think this patch is ready to go. Thanks. Before we install this, one question: is there a possibility someone would want the previous behavior? From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 23 05:09:10 2020 Received: (at 40845) by debbugs.gnu.org; 23 Aug 2020 09:09:10 +0000 Received: from localhost ([127.0.0.1]:52038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9lzy-0005DS-1V for submit@debbugs.gnu.org; Sun, 23 Aug 2020 05:09:10 -0400 Received: from mailout-l3b-97.contactoffice.com ([212.3.242.97]:57204) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9lzw-0005DG-87 for 40845@debbugs.gnu.org; Sun, 23 Aug 2020 05:09:09 -0400 Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id A77C418AC; Sun, 23 Aug 2020 11:09:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1598173742; s=20200222-6h9o; d=idiocy.org; i=alan@idiocy.org; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:In-Reply-To; l=617; bh=PIAMGtEPN1GnICfRHOMs0BI1BFv2MvciS8cCDzijCrA=; b=o8EcwJbSlIIZr2a+bvBzMKLNXsRz2rfLW59iBKC+Lwo/Ro/UiNpehZhxMPBHz/O2 uicJDzSkLuYCyLs5TNyrM6El/T4t7QrgiYlharYG5g6w6RN7de6m1I5IqHl75VR9o+3 y8gWrHwuP9aqhGKCOUWmYPL9VpmexUj/lT3Ee3FEYC2/93axnmfnVkVBGvR7SJG4dxN 68hlInnbdBysRBm/1bomdg2rXj9sJVuvU+7xBmWlVV9zBPnKMhn4aOjK7QJW7Ng+0g9 Jv4mSHG0ev+93r0j1Rkp5wBlo2fsyf8deGDPxl7EkCDhTE6nKrjP9QC/+RKlyHevLP4 XPPZ26WF2w== Received: by smtp.mailfence.com with ESMTPA ; Sun, 23 Aug 2020 11:09:01 +0200 (CEST) Received: by breton.holly.idiocy.org (Postfix, from userid 501) id CA0E62024C841E; Sun, 23 Aug 2020 10:08:59 +0100 (BST) Date: Sun, 23 Aug 2020 11:09:01 +0200 (CEST) From: Alan Third To: Eli Zaretskii Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200823090859.GE89421@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com References: <20200509142727.GA42881@breton.holly.idiocy.org> <20200509195415.GA44624@breton.holly.idiocy.org> <835zcx314r.fsf@gnu.org> <20200515214047.GB55337@breton.holly.idiocy.org> <20200822161510.GB89421@breton.holly.idiocy.org> <835z9aaaef.fsf@gnu.org> <20200822185756.GC89421@breton.holly.idiocy.org> <83y2m68p7i.fsf@gnu.org> <20200822213543.GD89421@breton.holly.idiocy.org> <83tuwt9amo.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83tuwt9amo.fsf@gnu.org> X-Spam-Flag: NO X-Spam-Status: No, hits=-1.0 required=4.7 symbols=ALL_TRUSTED device=10.2.0.21 X-ContactOffice-Account: com:241649512 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Sun, Aug 23, 2020 at 08:47:27AM +0300, Eli Zaretskii wrote: > > Date: Sat, 22 Aug 2020 23:35:46 +0200 (CEST) > > From: Alan Third > > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com > > > > Therefore I think this patch is ready to go. > > Thanks. Before we install this, one question: is there a possibility > someone would want the previous behavior? I don't think so. The resizing is plainly better, and if someone wants to enforce a foreground and background colour they can still do that with the :foreground and :background image properties. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 23 05:12:09 2020 Received: (at 40845) by debbugs.gnu.org; 23 Aug 2020 09:12:09 +0000 Received: from localhost ([127.0.0.1]:52059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9m2r-0005Iw-D2 for submit@debbugs.gnu.org; Sun, 23 Aug 2020 05:12:09 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9m2p-0005Ij-Qf for 40845@debbugs.gnu.org; Sun, 23 Aug 2020 05:12:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51863) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9m2k-0005z0-KS; Sun, 23 Aug 2020 05:12:02 -0400 Received: from [176.228.60.248] (port=1314 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k9m2i-0002Ro-MW; Sun, 23 Aug 2020 05:12:01 -0400 Date: Sun, 23 Aug 2020 12:11:55 +0300 Message-Id: <83eenx915w.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-Reply-To: <20200823090859.GE89421@breton.holly.idiocy.org> (message from Alan Third on Sun, 23 Aug 2020 11:09:01 +0200 (CEST)) Subject: Re: bug#40845: SVG rendering issues References: <20200509142727.GA42881@breton.holly.idiocy.org> <20200509195415.GA44624@breton.holly.idiocy.org> <835zcx314r.fsf@gnu.org> <20200515214047.GB55337@breton.holly.idiocy.org> <20200822161510.GB89421@breton.holly.idiocy.org> <835z9aaaef.fsf@gnu.org> <20200822185756.GC89421@breton.holly.idiocy.org> <83y2m68p7i.fsf@gnu.org> <20200822213543.GD89421@breton.holly.idiocy.org> <83tuwt9amo.fsf@gnu.org> <20200823090859.GE89421@breton.holly.idiocy.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 23 Aug 2020 11:09:01 +0200 (CEST) > From: Alan Third > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com > > > Thanks. Before we install this, one question: is there a possibility > > someone would want the previous behavior? > > I don't think so. The resizing is plainly better, and if someone wants > to enforce a foreground and background colour they can still do that > with the :foreground and :background image properties. OK, then let's say that last bit in the NEWS entry announcing this new behavior. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 23 07:48:55 2020 Received: (at 40845) by debbugs.gnu.org; 23 Aug 2020 11:48:55 +0000 Received: from localhost ([127.0.0.1]:52192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9oUZ-00032Q-7t for submit@debbugs.gnu.org; Sun, 23 Aug 2020 07:48:55 -0400 Received: from mailout-l3b-97.contactoffice.com ([212.3.242.97]:59286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9oUX-00032D-Ph for 40845@debbugs.gnu.org; Sun, 23 Aug 2020 07:48:54 -0400 Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 1725094F; Sun, 23 Aug 2020 13:48:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1598183327; s=20200222-6h9o; d=idiocy.org; i=alan@idiocy.org; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:In-Reply-To; l=1038; bh=9/04NPv2SQlr0kPvw+U+4Hi1PDkxQSonXmmAidGw1FM=; b=oe//rVAOrH3tkGpxyJfb9XT3oXKyyZDrtjp7CNSlxxv0mwiKDMHv1huKry8fB3t1 Jb34pQK26/BEjmiq+dseUzffk/iUul9vnC+4CNeUfXJwkLw/cq83l688SxJ54UAQa/r ovzk5KrnK8QGqeN5v6RL0tJ6gY8LoIq+yQPUxR2Ci4v54n8mERYtqCrHnEXTXDtSkeh eYGVK9PxrbByyQZcBmg3LNRWp9UxspMhvAGWZBPrE6JfGMTQTu2WsXnVgb+tcb7qu/S TIV0QFFhupXX6taBTRC4uk7iKpHMmq6OqqqNtpBaRDTdNLxWVCMzfl/RmH7v0WwdBF0 GPitPYUJHg== Received: by smtp.mailfence.com with ESMTPA ; Sun, 23 Aug 2020 13:48:44 +0200 (CEST) Received: by breton.holly.idiocy.org (Postfix, from userid 501) id 13C192024C8EE0; Sun, 23 Aug 2020 12:48:43 +0100 (BST) Date: Sun, 23 Aug 2020 13:48:45 +0200 (CEST) From: Alan Third To: Eli Zaretskii Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200823114843.GG89421@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com References: <835zcx314r.fsf@gnu.org> <20200515214047.GB55337@breton.holly.idiocy.org> <20200822161510.GB89421@breton.holly.idiocy.org> <835z9aaaef.fsf@gnu.org> <20200822185756.GC89421@breton.holly.idiocy.org> <83y2m68p7i.fsf@gnu.org> <20200822213543.GD89421@breton.holly.idiocy.org> <83tuwt9amo.fsf@gnu.org> <20200823090859.GE89421@breton.holly.idiocy.org> <83eenx915w.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83eenx915w.fsf@gnu.org> X-Spam-Flag: NO X-Spam-Status: No, hits=-2.9 required=4.7 symbols=ALL_TRUSTED, BAYES_00 device=10.2.0.20 X-ContactOffice-Account: com:241649512 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Sun, Aug 23, 2020 at 12:11:55PM +0300, Eli Zaretskii wrote: > > Date: Sun, 23 Aug 2020 11:09:01 +0200 (CEST) > > From: Alan Third > > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com > > > > > Thanks. Before we install this, one question: is there a possibility > > > someone would want the previous behavior? > > > > I don't think so. The resizing is plainly better, and if someone wants > > to enforce a foreground and background colour they can still do that > > with the :foreground and :background image properties. > > OK, then let's say that last bit in the NEWS entry announcing this new > behavior. Something like this? *** The background and foreground of images now default to face colors. To load images with the default frame colors use the ':foreground' and ':background' image attributes, for example: (create-image "filename" nil nil :foreground (face-attribute 'default :foreground) :background (face-attribute 'default :background)) -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 23 08:05:38 2020 Received: (at 40845) by debbugs.gnu.org; 23 Aug 2020 12:05:39 +0000 Received: from localhost ([127.0.0.1]:52216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9okk-0003SN-Nx for submit@debbugs.gnu.org; Sun, 23 Aug 2020 08:05:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42554) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9okj-0003SA-2q for 40845@debbugs.gnu.org; Sun, 23 Aug 2020 08:05:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52827) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9okd-0006Jv-0B; Sun, 23 Aug 2020 08:05:31 -0400 Received: from [176.228.60.248] (port=3950 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k9okc-0007Vq-53; Sun, 23 Aug 2020 08:05:30 -0400 Date: Sun, 23 Aug 2020 15:05:24 +0300 Message-Id: <83blj18t4r.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-Reply-To: <20200823114843.GG89421@breton.holly.idiocy.org> (message from Alan Third on Sun, 23 Aug 2020 13:48:45 +0200 (CEST)) Subject: Re: bug#40845: SVG rendering issues References: <835zcx314r.fsf@gnu.org> <20200515214047.GB55337@breton.holly.idiocy.org> <20200822161510.GB89421@breton.holly.idiocy.org> <835z9aaaef.fsf@gnu.org> <20200822185756.GC89421@breton.holly.idiocy.org> <83y2m68p7i.fsf@gnu.org> <20200822213543.GD89421@breton.holly.idiocy.org> <83tuwt9amo.fsf@gnu.org> <20200823090859.GE89421@breton.holly.idiocy.org> <83eenx915w.fsf@gnu.org> <20200823114843.GG89421@breton.holly.idiocy.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 23 Aug 2020 13:48:45 +0200 (CEST) > From: Alan Third > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com > > *** The background and foreground of images now default to face colors. > To load images with the default frame colors use the ':foreground' > and ':background' image attributes, for example: > > (create-image "filename" nil nil > :foreground (face-attribute 'default :foreground) > :background (face-attribute 'default :background)) Yes, thanks. But maybe expand a bit about "the face colors" part (not in the heading line, but in the body): what face is that, and when will the colors be used (I understand they will be used only if the image doesn't specify its own colors). From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 23 08:19:39 2020 Received: (at 40845) by debbugs.gnu.org; 23 Aug 2020 12:19:39 +0000 Received: from localhost ([127.0.0.1]:52222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9oyI-0005zX-V3 for submit@debbugs.gnu.org; Sun, 23 Aug 2020 08:19:39 -0400 Received: from mailout-l3b-97.contactoffice.com ([212.3.242.97]:59694) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9oyH-0005zG-Dv for 40845@debbugs.gnu.org; Sun, 23 Aug 2020 08:19:37 -0400 Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id D121C3C8; Sun, 23 Aug 2020 14:19:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1598185171; s=20200222-6h9o; d=idiocy.org; i=alan@idiocy.org; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:In-Reply-To; l=992; bh=ifxkpKlJuT3XYPWgFcrHGaoCQJMV20Z35IP4EFZIMnw=; b=vbGwhmjT2AVp9pvwrvPJjRI9USRHXpE1V9KWxCOLt2EdxqyXrqFTTM4Y7JfGIxUk n4uJ5CntQc15ac7jJslxbT34P+82RbbdcQT5ksZqQaUuDUmleLLGCxNxRwBRAKhYvPT xPQuEKjqA/p9rl0S6bNWYp9E79ILohctbjqU4e0XNFLsG+Hm0fiu4uWUXt2y2yAaLTS 7+zkEV3jOVrgCsNl0tEWkD8ETq/JIwiPvhnr4CcXZyXwURQ8cVJnZjM5x7UDGbTUmPZ 1/fFM0VbUPd+68vmm819IlDwAREeETe3e4RDacBWmkIdXIPig88G+GdmeNzRhgtpa8/ BE3LDJ3BzA== Received: by smtp.mailfence.com with ESMTPA ; Sun, 23 Aug 2020 14:19:27 +0200 (CEST) Received: by breton.holly.idiocy.org (Postfix, from userid 501) id E1EA92024C9CC7; Sun, 23 Aug 2020 13:19:25 +0100 (BST) Date: Sun, 23 Aug 2020 14:19:28 +0200 (CEST) From: Alan Third To: Eli Zaretskii Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200823121925.GH89421@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , Eli Zaretskii , cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com References: <20200822161510.GB89421@breton.holly.idiocy.org> <835z9aaaef.fsf@gnu.org> <20200822185756.GC89421@breton.holly.idiocy.org> <83y2m68p7i.fsf@gnu.org> <20200822213543.GD89421@breton.holly.idiocy.org> <83tuwt9amo.fsf@gnu.org> <20200823090859.GE89421@breton.holly.idiocy.org> <83eenx915w.fsf@gnu.org> <20200823114843.GG89421@breton.holly.idiocy.org> <83blj18t4r.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83blj18t4r.fsf@gnu.org> X-Spam-Flag: NO X-Spam-Status: No, hits=-2.9 required=4.7 symbols=ALL_TRUSTED, BAYES_00 device=10.2.0.1 X-ContactOffice-Account: com:241649512 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Sun, Aug 23, 2020 at 03:05:24PM +0300, Eli Zaretskii wrote: > > Yes, thanks. But maybe expand a bit about "the face colors" part (not > in the heading line, but in the body): what face is that, and when > will the colors be used (I understand they will be used only if the > image doesn't specify its own colors). How's this? --- *** The background and foreground of images now default to face colors. When an image doesn't specify a foreground or background color, Emacs now uses colors from the face used to draw the surrounding text instead of the frame's default colors. To load images with the default frame colors use the ':foreground' and ':background' image attributes, for example: (create-image "filename" nil nil :foreground (face-attribute 'default :foreground) :background (face-attribute 'default :background)) This change doesn't affect image types that do not support foreground and background colors, such as png or jpeg. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 23 08:23:47 2020 Received: (at 40845) by debbugs.gnu.org; 23 Aug 2020 12:23:47 +0000 Received: from localhost ([127.0.0.1]:52229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9p2I-00066e-Qo for submit@debbugs.gnu.org; Sun, 23 Aug 2020 08:23:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45590) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9p2G-00066Q-Tz for 40845@debbugs.gnu.org; Sun, 23 Aug 2020 08:23:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53116) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k9p2B-0008CG-KD; Sun, 23 Aug 2020 08:23:39 -0400 Received: from [176.228.60.248] (port=1084 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k9p2A-0002gF-WE; Sun, 23 Aug 2020 08:23:39 -0400 Date: Sun, 23 Aug 2020 15:23:33 +0300 Message-Id: <838se58sai.fsf@gnu.org> From: Eli Zaretskii To: Alan Third In-Reply-To: <20200823121925.GH89421@breton.holly.idiocy.org> (message from Alan Third on Sun, 23 Aug 2020 14:19:28 +0200 (CEST)) Subject: Re: bug#40845: SVG rendering issues References: <20200822161510.GB89421@breton.holly.idiocy.org> <835z9aaaef.fsf@gnu.org> <20200822185756.GC89421@breton.holly.idiocy.org> <83y2m68p7i.fsf@gnu.org> <20200822213543.GD89421@breton.holly.idiocy.org> <83tuwt9amo.fsf@gnu.org> <20200823090859.GE89421@breton.holly.idiocy.org> <83eenx915w.fsf@gnu.org> <20200823114843.GG89421@breton.holly.idiocy.org> <83blj18t4r.fsf@gnu.org> <20200823121925.GH89421@breton.holly.idiocy.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 40845 Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 23 Aug 2020 14:19:28 +0200 (CEST) > From: Alan Third > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com > > *** The background and foreground of images now default to face > colors. When an image doesn't specify a foreground or background > color, Emacs now uses colors from the face used to draw the > surrounding text instead of the frame's default colors. > > To load images with the default frame colors use the ':foreground' > and ':background' image attributes, for example: > > (create-image "filename" nil nil > :foreground (face-attribute 'default :foreground) > :background (face-attribute 'default :background)) > > This change doesn't affect image types that do not support foreground > and background colors, such as png or jpeg. Almost perfect: I would suggest to modify the last sentence so that it tells which types of images do support this feature. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 23 11:29:53 2020 Received: (at 40845-done) by debbugs.gnu.org; 23 Aug 2020 15:29:53 +0000 Received: from localhost ([127.0.0.1]:54919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9rwP-0005RZ-GZ for submit@debbugs.gnu.org; Sun, 23 Aug 2020 11:29:53 -0400 Received: from mailout-l3b-97.contactoffice.com ([212.3.242.97]:34442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9rwO-0005RL-0T for 40845-done@debbugs.gnu.org; Sun, 23 Aug 2020 11:29:52 -0400 Received: from smtpauth2.co-bxl (smtpauth2.co-bxl [10.2.0.24]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 68E9188B; Sun, 23 Aug 2020 17:29:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1598196586; s=20200222-6h9o; d=idiocy.org; i=alan@idiocy.org; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:In-Reply-To; l=1096; bh=OdJFjQyJr0bJOwuEFzGnzHnejbdsp93PjJyrpePxFRU=; b=nfePCjxHs9zqzS1TqgSD5JSQe3FdrUtGLdg9PFK/CzC6IanQE46VlEzpp13XWVk8 BDVrAYv+NJ0go/wqY5/E9eCmXJrPzO5GTuV+j+DeVBGC0mIxpGOhicKk+CJVqohxsrg QusHAKHYWIqVr5caLczY9DrG+voi08daIa7YgBeqL9Eds2ZXe4r8yolCVYVExfle+qs v6MM/RVwzjgK5wgQiIwFBjX/C96FqMaK1C7Zjw9BFvAAYSSHfAACLzpgFMEQjtZF8QO SbsnFLoDDRlvkH2Fm7zZBOKjmQrTkPZwHKX5vLyC0sJiWS3wIWMN/a70fBOZUd9al1p UMR+I1esiw== Received: by smtp.mailfence.com with ESMTPA ; Sun, 23 Aug 2020 17:29:43 +0200 (CEST) Received: by breton.holly.idiocy.org (Postfix, from userid 501) id EB3852024CCC21; Sun, 23 Aug 2020 16:29:41 +0100 (BST) Date: Sun, 23 Aug 2020 17:29:44 +0200 (CEST) From: Alan Third To: Eli Zaretskii Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200823152941.GI89421@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , Eli Zaretskii , cpitclaudel@gmail.com, 40845-done@debbugs.gnu.org, pipcet@gmail.com References: <20200822185756.GC89421@breton.holly.idiocy.org> <83y2m68p7i.fsf@gnu.org> <20200822213543.GD89421@breton.holly.idiocy.org> <83tuwt9amo.fsf@gnu.org> <20200823090859.GE89421@breton.holly.idiocy.org> <83eenx915w.fsf@gnu.org> <20200823114843.GG89421@breton.holly.idiocy.org> <83blj18t4r.fsf@gnu.org> <20200823121925.GH89421@breton.holly.idiocy.org> <838se58sai.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <838se58sai.fsf@gnu.org> X-Spam-Flag: NO X-Spam-Status: No, hits=-2.9 required=4.7 symbols=ALL_TRUSTED, BAYES_00 device=10.2.0.21 X-ContactOffice-Account: com:241649512 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40845-done Cc: cpitclaudel@gmail.com, 40845-done@debbugs.gnu.org, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Sun, Aug 23, 2020 at 03:23:33PM +0300, Eli Zaretskii wrote: > > Date: Sun, 23 Aug 2020 14:19:28 +0200 (CEST) > > From: Alan Third > > Cc: cpitclaudel@gmail.com, 40845@debbugs.gnu.org, pipcet@gmail.com > > > > *** The background and foreground of images now default to face > > colors. When an image doesn't specify a foreground or background > > color, Emacs now uses colors from the face used to draw the > > surrounding text instead of the frame's default colors. > > > > To load images with the default frame colors use the ':foreground' > > and ':background' image attributes, for example: > > > > (create-image "filename" nil nil > > :foreground (face-attribute 'default :foreground) > > :background (face-attribute 'default :background)) > > > > This change doesn't affect image types that do not support foreground > > and background colors, such as png or jpeg. > > Almost perfect: I would suggest to modify the last sentence so that it > tells which types of images do support this feature. Thanks. I've pushed it to master. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 23 11:43:42 2020 Received: (at 40845-done) by debbugs.gnu.org; 23 Aug 2020 15:43:42 +0000 Received: from localhost ([127.0.0.1]:54941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9s9m-0005pN-5Q for submit@debbugs.gnu.org; Sun, 23 Aug 2020 11:43:42 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9s9j-0005p4-9k for 40845-done@debbugs.gnu.org; Sun, 23 Aug 2020 11:43:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=uSHr6U9xTO5sBoMK+QIhQw2xi3Oh8tQFQ696JU1F1SM=; b=JpSmxl32BH5uvdikUUvR55fw3W uvdqLdBaPBcWtas51V9bYV+Dx6SWUcMJOZqeJ0XV9Q7bAEMSyRWrp3ukn1jaePyO3LOsBfixsWFmJ 1RIxkZ/vpcaPoFEdfkDVRK21qqIuf7C71C40ly8Mmg7mbEUz44FYKShK0rbVbSQvs4qA=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k9s9W-0000RV-8R; Sun, 23 Aug 2020 17:43:32 +0200 From: Lars Ingebrigtsen To: Alan Third Subject: Re: bug#40845: SVG rendering issues References: <20200822185756.GC89421@breton.holly.idiocy.org> <83y2m68p7i.fsf@gnu.org> <20200822213543.GD89421@breton.holly.idiocy.org> <83tuwt9amo.fsf@gnu.org> <20200823090859.GE89421@breton.holly.idiocy.org> <83eenx915w.fsf@gnu.org> <20200823114843.GG89421@breton.holly.idiocy.org> <83blj18t4r.fsf@gnu.org> <20200823121925.GH89421@breton.holly.idiocy.org> <838se58sai.fsf@gnu.org> <20200823152941.GI89421@breton.holly.idiocy.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAG1BMVEWlnHWyrI59X1NC QTqemoW0t6a+vaPPkkz////2JcpjAAAAAWJLR0QIht6VegAAAAd0SU1FB+QIFw8qJOSLuBcAAAGs SURBVDjLbZSxcsMgDIYxcXZo484E2mZ1Ue662inp7lzoG/QFvPj1K8Bg0VbJOY6++yUhyWasmIzG JCPGueJMK7xq/CHAABgLaHgDvRAE9EaBDUBDz5oCAJ0GzgA7/LyxRlCFtseHXlhhmkaKuqBgk5SC gIiE7QvP7ib8OcAGBPHLA1P/gifDzUtXgzEBAy/eU5IidVzpfQ3GBHYQFBOpawUfYD8r4BKYhpY5 X2IVgbyBNdYXyaZAcLFU0bqUQirFn6liBX4KM/quQAzVTWDt2ZdYbMih/N3pKwnlnEt+fwO4EsUK 0HHTIXeW4CnW5NlyqAgufEDpEL7tcE3gcFhP/kuCw3aVO5P/gE85SlX+67tWyDGBi26vG0EwjvGA j9irMwF4wATCstu/LZH3DBBRRQKxWV1RxCQRhPaSUAUsS1cpXFrpAPZkUHkgmHoJq5h7tQFj9Wlf JhVBaHAAMdQ0bTmGFu+M1qe5CjWkbeRg9fw6FdAyprVqJG8+QJsjVlxWVGM9zQWsA2Pel7nLjwcP PQoXZcCcsgJfDjsgtizzcQXcFC++S07LnB5d9gM0C6Zw1MantwAAACV0RVh0ZGF0ZTpjcmVhdGUA MjAyMC0wOC0yM1QxNTo0MjozNiswMDowMCGanEEAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjAtMDgt MjNUMTU6NDI6MzYrMDA6MDBQxyT9AAAAAElFTkSuQmCC X-Now-Playing: Charles Mingus's _The Black Saint and the Sinner Lady_: "Mode D: Trio and group dancers; Mode E: Single solos and group dance; Mode F: Group and solo dance" Date: Sun, 23 Aug 2020 17:43:24 +0200 In-Reply-To: <20200823152941.GI89421@breton.holly.idiocy.org> (Alan Third's message of "Sun, 23 Aug 2020 17:29:44 +0200 (CEST)") Message-ID: <87blj1fjvn.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Alan Third writes: > Thanks. I've pushed it to master. Great! Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845-done Cc: Eli Zaretskii , 40845-done@debbugs.gnu.org, cpitclaudel@gmail.com, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Third writes: > Thanks. I've pushed it to master. Great! I'm getting this warning, though: image.c: In function =E2=80=98lookup_image=E2=80=99: image.c:2340:17: warning: potential null pointer dereference [-Wnull-derefe= rence] 2340 | unsigned long background =3D FACE_COLOR_TO_PIXEL (face->backgroun= d, f); | ^~~~~~~~~~ image.c:2339:17: warning: potential null pointer dereference [-Wnull-derefe= rence] 2339 | unsigned long foreground =3D FACE_COLOR_TO_PIXEL (face->foregroun= d, f); | ^~~~~~~~~~ This is on Debian/bullseye, with gcc (Debian 9.3.0-15) 9.3.0. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 23 12:08:27 2020 Received: (at 40845-done) by debbugs.gnu.org; 23 Aug 2020 16:08:27 +0000 Received: from localhost ([127.0.0.1]:54949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9sXj-0006QS-Hr for submit@debbugs.gnu.org; Sun, 23 Aug 2020 12:08:27 -0400 Received: from mailout-l3b-97.contactoffice.com ([212.3.242.97]:34986) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9sXi-0006QG-D1 for 40845-done@debbugs.gnu.org; Sun, 23 Aug 2020 12:08:26 -0400 Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 32D113E8; Sun, 23 Aug 2020 18:08:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1598198900; s=20200222-6h9o; d=idiocy.org; i=alan@idiocy.org; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To; l=875; bh=9jfRnDnk6e79/mKrprBRZsATsdfCKfQ6LhIUMqDzGYs=; b=JAPdNgrHe4RtsPBKzbH0vjSjmP9Xm/U5ezlqXSGw+5IvCieQHguSuTA2AgYbdyMo BHMTjbY3eLh3LmWS+Zv+JTv0DPFrKrNBWpPnwcidB6orjVzP+pt4frTzTqLZcJY2tbN Yy9kAbq0ME4+/7JR60vzQyRT2Z8ySSSLwpC5PnH+GC2B85Nr99XS0QszyfZfudBIURM +pq3IUnm8047aeW+VgkI1me7JjFgcQd7VmKIBYrNEGpCiJ03xZuIt3fMDu4ylC7yY/R NA1sbt+Xny5K9QU2DEGIX8RC4p9r+6fmf4awnmvqoiP19yk4Mcm2zGBFGVr6Fi19geT yLX/KrfJyA== Received: by smtp.mailfence.com with ESMTPA ; Sun, 23 Aug 2020 18:08:16 +0200 (CEST) Received: by breton.holly.idiocy.org (Postfix, from userid 501) id AA0062024CD7D3; Sun, 23 Aug 2020 17:08:14 +0100 (BST) Date: Sun, 23 Aug 2020 18:08:17 +0200 (CEST) From: Alan Third To: Lars Ingebrigtsen Subject: Re: bug#40845: SVG rendering issues Message-ID: <20200823160814.GA36312@breton.holly.idiocy.org> Mail-Followup-To: Alan Third , Lars Ingebrigtsen , Eli Zaretskii , cpitclaudel@gmail.com, 40845-done@debbugs.gnu.org, pipcet@gmail.com References: <20200822213543.GD89421@breton.holly.idiocy.org> <83tuwt9amo.fsf@gnu.org> <20200823090859.GE89421@breton.holly.idiocy.org> <83eenx915w.fsf@gnu.org> <20200823114843.GG89421@breton.holly.idiocy.org> <83blj18t4r.fsf@gnu.org> <20200823121925.GH89421@breton.holly.idiocy.org> <838se58sai.fsf@gnu.org> <20200823152941.GI89421@breton.holly.idiocy.org> <87blj1fjvn.fsf@gnus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87blj1fjvn.fsf@gnus.org> X-Spam-Flag: NO X-Spam-Status: No, hits=-2.9 required=4.7 symbols=ALL_TRUSTED, BAYES_00 device=10.2.0.20 X-ContactOffice-Account: com:241649512 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 40845-done Cc: Eli Zaretskii , 40845-done@debbugs.gnu.org, cpitclaudel@gmail.com, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Sun, Aug 23, 2020 at 05:43:24PM +0200, Lars Ingebrigtsen wrote: > Alan Third writes: > > > Thanks. I've pushed it to master. > > Great! > > I'm getting this warning, though: > > image.c: In function ‘lookup_image’: > image.c:2340:17: warning: potential null pointer dereference [-Wnull-dereference] > 2340 | unsigned long background = FACE_COLOR_TO_PIXEL (face->background, f); > | ^~~~~~~~~~ > image.c:2339:17: warning: potential null pointer dereference [-Wnull-dereference] > 2339 | unsigned long foreground = FACE_COLOR_TO_PIXEL (face->foreground, f); > | ^~~~~~~~~~ > > This is on Debian/bullseye, with gcc (Debian 9.3.0-15) 9.3.0. I don't think I should have used FACE_FROM_ID_OR_NULL. I would hope we're not going to be trying to load images without a default face already defined. I've pushed a fix. -- Alan Third From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 23 12:38:29 2020 Received: (at 40845-done) by debbugs.gnu.org; 23 Aug 2020 16:38:29 +0000 Received: from localhost ([127.0.0.1]:55004 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9t0n-0007Ce-Jc for submit@debbugs.gnu.org; Sun, 23 Aug 2020 12:38:29 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47974) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9t0l-0007CQ-GV for 40845-done@debbugs.gnu.org; Sun, 23 Aug 2020 12:38:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=awjqaDqZ+o+pxXb3i42ee9xN2EqKyqZC6vmCnDh227U=; b=AQ8zwUdcXQMwsLDGCx3skDSDsG /KTqIH2fP1uok1Itc6XeCd+jaFMbn1ydke8kFdGGNyLw3MTGYYO5cW98/mS/cmuvgZo+g00qfdn3R 72flEntfekdyHaNR5DizUPNvlxwpGM95I14VzIr2htdk2BrNJiPTVAGSdk5Uf9gto5Ss=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k9t0W-0001LI-2q; Sun, 23 Aug 2020 18:38:20 +0200 From: Lars Ingebrigtsen To: Alan Third Subject: Re: bug#40845: SVG rendering issues References: <20200822213543.GD89421@breton.holly.idiocy.org> <83tuwt9amo.fsf@gnu.org> <20200823090859.GE89421@breton.holly.idiocy.org> <83eenx915w.fsf@gnu.org> <20200823114843.GG89421@breton.holly.idiocy.org> <83blj18t4r.fsf@gnu.org> <20200823121925.GH89421@breton.holly.idiocy.org> <838se58sai.fsf@gnu.org> <20200823152941.GI89421@breton.holly.idiocy.org> <87blj1fjvn.fsf@gnus.org> <20200823160814.GA36312@breton.holly.idiocy.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEXs6ueHdGmuqrf/ ///FSMiWAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+QIFxAlOGBoHNoAAAGFSURBVCjPTZIxixsxEIXn BAux+vRuDI5+RcqULiyxVrUEEpL9FZuFK+zKBGTutlrMaZHer8yb9UFOheDTjGbmPUlEDvJ/bVox RQRQ+NKKxWBTGAi7ozjMjfcEs0LZBd9ppGV++Zwq4ZNCX9IJV0JuTQ7lRfDCtPzriXA1WPTOTHi7 blZw87mGqdtoV4PxhJC6BhjE3P94hNg1/TKILeIR+1OOWCEB8P4dXnvcgP5GmCVGMKiR54NxwMQI Sz+3LGoDKmZqOzYqcbrpvvONGCOpWy3wP9iYKaKyV726ePD03XcGezGyZdpmFf8A2qLiP4DDYPSO JAIwG821D1ggjh5n/5UQ74YtFuRB4VzoYg0cHbWvOB+k+n4WVxHN2Er97YvYXMN4IfhwFZOzv3+b FNg6p3T5q3Dc09aEZQdCS09cGv1FobOx2FTHWKTGoanBpJ9bR2hpQ5A8uKWIC9tM5VafnFPP2Vf+ EkMr7Gpnef8uKHsKfdig+qZ7+QDTIBzDrif6nGkQ9w+MhbkQFffadAAAACV0RVh0ZGF0ZTpjcmVh dGUAMjAyMC0wOC0yM1QxNjozNzo1NiswMDowMJUtJ88AAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjAt MDgtMjNUMTY6Mzc6NTYrMDA6MDDkcJ9zAAAAAElFTkSuQmCC X-Now-Playing: Various's _The Wire Tapper 51_: "Tarot Twilight - Tarot One" Date: Sun, 23 Aug 2020 18:38:10 +0200 In-Reply-To: <20200823160814.GA36312@breton.holly.idiocy.org> (Alan Third's message of "Sun, 23 Aug 2020 18:08:17 +0200 (CEST)") Message-ID: <877dtpfhcd.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Alan Third writes: > I don't think I should have used FACE_FROM_ID_OR_NULL. I would hope > we're not going to be trying to load images without a default face > already defined. > > I've pushed a fix. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 40845-done Cc: Eli Zaretskii , 40845-done@debbugs.gnu.org, cpitclaudel@gmail.com, pipcet@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Third writes: > I don't think I should have used FACE_FROM_ID_OR_NULL. I would hope > we're not going to be trying to load images without a default face > already defined. > > I've pushed a fix. Thanks; that fixes the warnings. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Thu Jun 19 14:30:14 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 21 Sep 2020 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator