GNU bug report logs - #40845
SVG rendering issues

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Clément Pit-Claudel <cpitclaudel@HIDDEN>; dated Sat, 25 Apr 2020 12:20:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 3 May 2020 14:18:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 03 10:18:29 2020
Received: from localhost ([127.0.0.1]:57514 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jVFRs-0001tX-MH
	for submit <at> 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 <larsi@HIDDEN>) id 1jVFRm-0001tF-4d
 for 40845 <at> 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 <larsi@HIDDEN>)
 id 1jVFRS-0002Ov-DY; Sun, 03 May 2020 16:18:15 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
To: Alan Third <alan@HIDDEN>
Subject: Re: bug#40845: SVG rendering issues
References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83mu6z7em5.fsf@HIDDEN>
 <17307310-2afc-7941-8a48-5cd345d1ad63@HIDDEN>
 <83k1237b2a.fsf@HIDDEN>
 <bd59b4a7-6fcb-183b-9439-27fc239b8eaa@HIDDEN>
 <20200425174651.GC82687@HIDDEN>
 <20200426211741.GA93046@HIDDEN>
 <09a19c49-91cb-8024-8c34-53d846d98313@HIDDEN>
 <20200503141348.GA4071@HIDDEN>
Date: Sun, 03 May 2020 16:18:01 +0200
In-Reply-To: <20200503141348.GA4071@HIDDEN> (Alan Third's
 message of "Sun, 3 May 2020 15:13:48 +0100")
Message-ID: <87tv0xw19i.fsf@HIDDEN>
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 <alan@HIDDEN> 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 <cpitclaudel@HIDDEN>,
 Eli Zaretskii <eliz@HIDDEN>, pipcet@HIDDEN, 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Alan Third <alan@HIDDEN> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 3 May 2020 14:13:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 03 10:13:57 2020
Received: from localhost ([127.0.0.1]:57506 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jVFNU-0001lz-Sq
	for submit <at> 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 <alan@HIDDEN>) id 1jVFNT-0001lm-8Q
 for 40845 <at> 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 <alan@HIDDEN>
To: =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel <cpitclaudel@HIDDEN>
Subject: Re: bug#40845: SVG rendering issues
Message-ID: <20200503141348.GA4071@HIDDEN>
Mail-Followup-To: Alan Third <alan@HIDDEN>,
 =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel <cpitclaudel@HIDDEN>,
 Eli Zaretskii <eliz@HIDDEN>, 40845 <at> debbugs.gnu.org,
 pipcet@HIDDEN
References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83mu6z7em5.fsf@HIDDEN>
 <17307310-2afc-7941-8a48-5cd345d1ad63@HIDDEN>
 <83k1237b2a.fsf@HIDDEN>
 <bd59b4a7-6fcb-183b-9439-27fc239b8eaa@HIDDEN>
 <20200425174651.GC82687@HIDDEN>
 <20200426211741.GA93046@HIDDEN>
 <09a19c49-91cb-8024-8c34-53d846d98313@HIDDEN>
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@HIDDEN>
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 40845
Cc: Eli Zaretskii <eliz@HIDDEN>, 40845 <at> debbugs.gnu.org, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 27 Apr 2020 16:04:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 27 12:04:41 2020
Received: from localhost ([127.0.0.1]:37944 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jT6FM-0006qZ-Sf
	for submit <at> 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 <cpitclaudel@HIDDEN>) id 1jT6FL-0006qI-3Q
 for 40845 <at> 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 <at> 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 <alan@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 40845 <at> debbugs.gnu.org, pipcet@HIDDEN
References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83mu6z7em5.fsf@HIDDEN> <17307310-2afc-7941-8a48-5cd345d1ad63@HIDDEN>
 <83k1237b2a.fsf@HIDDEN> <bd59b4a7-6fcb-183b-9439-27fc239b8eaa@HIDDEN>
 <20200425174651.GC82687@HIDDEN>
 <20200426211741.GA93046@HIDDEN>
 <09a19c49-91cb-8024-8c34-53d846d98313@HIDDEN>
 <20200427152229.GA93571@HIDDEN>
From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= <cpitclaudel@HIDDEN>
Message-ID: <dc6d28f0-0167-52f9-bb5a-d0a9060f44fa@HIDDEN>
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@HIDDEN>
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 27 Apr 2020 15:47:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 27 11:47:27 2020
Received: from localhost ([127.0.0.1]:37939 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jT5yd-0006Fw-S4
	for submit <at> 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 <eliz@HIDDEN>) id 1jT5yb-0006Fe-Qf
 for 40845 <at> 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 <eliz@HIDDEN>)
 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <CAOqdjBf+J_D8YASF53F=U5ob0S0R4eRbcy9t2j-zEY1Zi+v5Ow@HIDDEN>
 (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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83o8rf7fc0.fsf@HIDDEN>
 <CAOqdjBdcLp0AviU1vf7ZWDcdsfnuDW8X+CGEB0dam5+7NvqwjQ@HIDDEN>
 <83lfmj7dh7.fsf@HIDDEN>
 <CAOqdjBcD10MSN6faJxp4bBgwfm6Y1M2wrTy28Uib7hYzquOQsg@HIDDEN>
 <83eesb7833.fsf@HIDDEN>
 <CAOqdjBcX0WgmJenStzb-4s0pnnTWm3rzxHiXFJSzMUM-H4zULQ@HIDDEN>
 <83d07v72c4.fsf@HIDDEN>
 <CAOqdjBc+i_E5qN-M=zzZgrnVUYtJ63KCmE7jLaHQR4nRbStXyQ@HIDDEN>
 <83y2qi5n3d.fsf@HIDDEN>
 <CAOqdjBf+J_D8YASF53F=U5ob0S0R4eRbcy9t2j-zEY1Zi+v5Ow@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 40845
Cc: cpitclaudel@HIDDEN, 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Sun, 26 Apr 2020 19:00:36 +0000
> Cc: cpitclaudel@HIDDEN, 40845 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 27 Apr 2020 15:22:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 27 11:22:38 2020
Received: from localhost ([127.0.0.1]:37904 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jT5ag-0005Qr-Li
	for submit <at> 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 <alan@HIDDEN>) id 1jT5ae-0005QV-Qr
 for 40845 <at> 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 <alan@HIDDEN>
To: =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel <cpitclaudel@HIDDEN>
Subject: Re: bug#40845: SVG rendering issues
Message-ID: <20200427152229.GA93571@HIDDEN>
Mail-Followup-To: Alan Third <alan@HIDDEN>,
 =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel <cpitclaudel@HIDDEN>,
 Eli Zaretskii <eliz@HIDDEN>, 40845 <at> debbugs.gnu.org,
 pipcet@HIDDEN
References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83mu6z7em5.fsf@HIDDEN>
 <17307310-2afc-7941-8a48-5cd345d1ad63@HIDDEN>
 <83k1237b2a.fsf@HIDDEN>
 <bd59b4a7-6fcb-183b-9439-27fc239b8eaa@HIDDEN>
 <20200425174651.GC82687@HIDDEN>
 <20200426211741.GA93046@HIDDEN>
 <09a19c49-91cb-8024-8c34-53d846d98313@HIDDEN>
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@HIDDEN>
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 40845
Cc: Eli Zaretskii <eliz@HIDDEN>, 40845 <at> debbugs.gnu.org, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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:

    <svg xmlns:xlink="http://www.w3.org/1999/xlink"
         xmlns:xi="http://www.w3.org/2001/XInclude"
         width="100" height="100"
         preserveAspectRatio="none"
         viewBox="0 0 283.465 283.465">
      <xi:include href="data:image/svg+xml;base64,<base64 encoded data>">
      </xi:include>
    </svg>

We can’t just put the contents in directly, like:

    <svg xmlns:xlink="http://www.w3.org/1999/xlink"
         width="100" height="100"
         preserveAspectRatio="none"
         viewBox="0 0 283.465 283.465">
      <!-- file contents -->   
      <svg>
         stuff
      </svg>
      <!-- end file contents -->
    </svg>

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:

    <svg xmlns:xlink="http://www.w3.org/1999/xlink"
         xmlns:xi="http://www.w3.org/2001/XInclude"
         width="100" height="100"
         preserveAspectRatio="none"
         viewBox="0 0 283.465 283.465">
      <xi:include href="data:image/svg+xml;utf8,<svg>stuff</svg>">
      </xi:include>
    </svg>

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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 27 Apr 2020 02:28:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 26 22:28:13 2020
Received: from localhost ([127.0.0.1]:35290 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jStVE-00088h-PV
	for submit <at> 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 <eliz@HIDDEN>) id 1jStVE-00088W-1p
 for 40845 <at> 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 <eliz@HIDDEN>)
 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Alan Third <alan@HIDDEN>
In-Reply-To: <20200426211741.GA93046@HIDDEN> (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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83mu6z7em5.fsf@HIDDEN>
 <17307310-2afc-7941-8a48-5cd345d1ad63@HIDDEN>
 <83k1237b2a.fsf@HIDDEN>
 <bd59b4a7-6fcb-183b-9439-27fc239b8eaa@HIDDEN>
 <20200425174651.GC82687@HIDDEN>
 <20200426211741.GA93046@HIDDEN>
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@HIDDEN, 40845 <at> debbugs.gnu.org, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Sun, 26 Apr 2020 22:17:41 +0100
> From: Alan Third <alan@HIDDEN>
> 
> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 26 Apr 2020 22:48:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 26 18:48:19 2020
Received: from localhost ([127.0.0.1]:35184 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSq4Q-0002le-Vn
	for submit <at> 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 <cpitclaudel@HIDDEN>) id 1jSq4P-0002lR-MM
 for 40845 <at> 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 <at> 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 <alan@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
 40845 <at> debbugs.gnu.org, pipcet@HIDDEN
References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83mu6z7em5.fsf@HIDDEN> <17307310-2afc-7941-8a48-5cd345d1ad63@HIDDEN>
 <83k1237b2a.fsf@HIDDEN> <bd59b4a7-6fcb-183b-9439-27fc239b8eaa@HIDDEN>
 <20200425174651.GC82687@HIDDEN>
 <20200426211741.GA93046@HIDDEN>
From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= <cpitclaudel@HIDDEN>
Message-ID: <09a19c49-91cb-8024-8c34-53d846d98313@HIDDEN>
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@HIDDEN>
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 26 Apr 2020 21:17:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 26 17:17:49 2020
Received: from localhost ([127.0.0.1]:35106 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSoer-0000P4-Fw
	for submit <at> 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 <alan@HIDDEN>) id 1jSoeq-0000Oq-60
 for 40845 <at> 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 <alan@HIDDEN>
To: =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel <cpitclaudel@HIDDEN>,
 Eli Zaretskii <eliz@HIDDEN>, 40845 <at> debbugs.gnu.org, pipcet@HIDDEN
Subject: Re: bug#40845: SVG rendering issues
Message-ID: <20200426211741.GA93046@HIDDEN>
Mail-Followup-To: Alan Third <alan@HIDDEN>,
 =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel <cpitclaudel@HIDDEN>,
 Eli Zaretskii <eliz@HIDDEN>, 40845 <at> debbugs.gnu.org,
 pipcet@HIDDEN
References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83mu6z7em5.fsf@HIDDEN>
 <17307310-2afc-7941-8a48-5cd345d1ad63@HIDDEN>
 <83k1237b2a.fsf@HIDDEN>
 <bd59b4a7-6fcb-183b-9439-27fc239b8eaa@HIDDEN>
 <20200425174651.GC82687@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200425174651.GC82687@HIDDEN>
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 40845
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 26 Apr 2020 19:01:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 26 15:01:20 2020
Received: from localhost ([127.0.0.1]:34930 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSmWl-0002V0-W9
	for submit <at> 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 <pipcet@HIDDEN>) id 1jSmWk-0002Ul-39
 for 40845 <at> 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 <at> 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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83o8rf7fc0.fsf@HIDDEN>
 <CAOqdjBdcLp0AviU1vf7ZWDcdsfnuDW8X+CGEB0dam5+7NvqwjQ@HIDDEN>
 <83lfmj7dh7.fsf@HIDDEN>
 <CAOqdjBcD10MSN6faJxp4bBgwfm6Y1M2wrTy28Uib7hYzquOQsg@HIDDEN>
 <83eesb7833.fsf@HIDDEN>
 <CAOqdjBcX0WgmJenStzb-4s0pnnTWm3rzxHiXFJSzMUM-H4zULQ@HIDDEN>
 <83d07v72c4.fsf@HIDDEN>
 <CAOqdjBc+i_E5qN-M=zzZgrnVUYtJ63KCmE7jLaHQR4nRbStXyQ@HIDDEN>
 <83y2qi5n3d.fsf@HIDDEN>
In-Reply-To: <83y2qi5n3d.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Sun, 26 Apr 2020 19:00:36 +0000
Message-ID: <CAOqdjBf+J_D8YASF53F=U5ob0S0R4eRbcy9t2j-zEY1Zi+v5Ow@HIDDEN>
Subject: Re: bug#40845: SVG rendering issues
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 40845
Cc: cpitclaudel@HIDDEN, 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Sun, Apr 26, 2020 at 2:38 PM Eli Zaretskii <eliz@HIDDEN> wrote:
> > From: Pip Cet <pipcet@HIDDEN>
> > Date: Sun, 26 Apr 2020 10:15:39 +0000
> > Cc: cpitclaudel@HIDDEN, 40845 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 26 Apr 2020 14:38:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 26 10:38:31 2020
Received: from localhost ([127.0.0.1]:33887 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSiQR-0007ds-1r
	for submit <at> 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 <eliz@HIDDEN>) id 1jSiQP-0007df-KE
 for 40845 <at> 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 <eliz@HIDDEN>)
 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <CAOqdjBc+i_E5qN-M=zzZgrnVUYtJ63KCmE7jLaHQR4nRbStXyQ@HIDDEN>
 (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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83o8rf7fc0.fsf@HIDDEN>
 <CAOqdjBdcLp0AviU1vf7ZWDcdsfnuDW8X+CGEB0dam5+7NvqwjQ@HIDDEN>
 <83lfmj7dh7.fsf@HIDDEN>
 <CAOqdjBcD10MSN6faJxp4bBgwfm6Y1M2wrTy28Uib7hYzquOQsg@HIDDEN>
 <83eesb7833.fsf@HIDDEN>
 <CAOqdjBcX0WgmJenStzb-4s0pnnTWm3rzxHiXFJSzMUM-H4zULQ@HIDDEN>
 <83d07v72c4.fsf@HIDDEN>
 <CAOqdjBc+i_E5qN-M=zzZgrnVUYtJ63KCmE7jLaHQR4nRbStXyQ@HIDDEN>
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@HIDDEN, 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Sun, 26 Apr 2020 10:15:39 +0000
> Cc: cpitclaudel@HIDDEN, 40845 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 26 Apr 2020 10:16:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 26 06:16:23 2020
Received: from localhost ([127.0.0.1]:60899 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSeKl-0006Ir-Dr
	for submit <at> 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 <pipcet@HIDDEN>) id 1jSeKj-0006Ia-QD
 for 40845 <at> 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 <at> 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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83o8rf7fc0.fsf@HIDDEN>
 <CAOqdjBdcLp0AviU1vf7ZWDcdsfnuDW8X+CGEB0dam5+7NvqwjQ@HIDDEN>
 <83lfmj7dh7.fsf@HIDDEN>
 <CAOqdjBcD10MSN6faJxp4bBgwfm6Y1M2wrTy28Uib7hYzquOQsg@HIDDEN>
 <83eesb7833.fsf@HIDDEN>
 <CAOqdjBcX0WgmJenStzb-4s0pnnTWm3rzxHiXFJSzMUM-H4zULQ@HIDDEN>
 <83d07v72c4.fsf@HIDDEN>
In-Reply-To: <83d07v72c4.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Sun, 26 Apr 2020 10:15:39 +0000
Message-ID: <CAOqdjBc+i_E5qN-M=zzZgrnVUYtJ63KCmE7jLaHQR4nRbStXyQ@HIDDEN>
Subject: Re: bug#40845: SVG rendering issues
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 40845
Cc: cpitclaudel@HIDDEN, 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Sat, Apr 25, 2020 at 8:11 PM Eli Zaretskii <eliz@HIDDEN> wrote:
> > From: Pip Cet <pipcet@HIDDEN>
> > Date: Sat, 25 Apr 2020 19:41:31 +0000
> > Cc: cpitclaudel@HIDDEN, 40845 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 20:11:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 16:11:42 2020
Received: from localhost ([127.0.0.1]:60410 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSR9K-0005vk-7T
	for submit <at> 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 <eliz@HIDDEN>) id 1jSR9J-0005vX-2C
 for 40845 <at> 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 <eliz@HIDDEN>)
 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <CAOqdjBcX0WgmJenStzb-4s0pnnTWm3rzxHiXFJSzMUM-H4zULQ@HIDDEN>
 (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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83o8rf7fc0.fsf@HIDDEN>
 <CAOqdjBdcLp0AviU1vf7ZWDcdsfnuDW8X+CGEB0dam5+7NvqwjQ@HIDDEN>
 <83lfmj7dh7.fsf@HIDDEN>
 <CAOqdjBcD10MSN6faJxp4bBgwfm6Y1M2wrTy28Uib7hYzquOQsg@HIDDEN>
 <83eesb7833.fsf@HIDDEN>
 <CAOqdjBcX0WgmJenStzb-4s0pnnTWm3rzxHiXFJSzMUM-H4zULQ@HIDDEN>
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@HIDDEN, 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Sat, 25 Apr 2020 19:41:31 +0000
> Cc: cpitclaudel@HIDDEN, 40845 <at> 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.)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 19:42:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 15:42:15 2020
Received: from localhost ([127.0.0.1]:60389 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSQgp-0005F2-Eu
	for submit <at> 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 <pipcet@HIDDEN>) id 1jSQgn-0005Ep-Vo
 for 40845 <at> 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 <at> 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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83o8rf7fc0.fsf@HIDDEN>
 <CAOqdjBdcLp0AviU1vf7ZWDcdsfnuDW8X+CGEB0dam5+7NvqwjQ@HIDDEN>
 <83lfmj7dh7.fsf@HIDDEN>
 <CAOqdjBcD10MSN6faJxp4bBgwfm6Y1M2wrTy28Uib7hYzquOQsg@HIDDEN>
 <83eesb7833.fsf@HIDDEN>
In-Reply-To: <83eesb7833.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Sat, 25 Apr 2020 19:41:31 +0000
Message-ID: <CAOqdjBcX0WgmJenStzb-4s0pnnTWm3rzxHiXFJSzMUM-H4zULQ@HIDDEN>
Subject: Re: bug#40845: SVG rendering issues
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/mixed; boundary="0000000000005fc4d905a422ad7c"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 40845
Cc: cpitclaudel@HIDDEN, 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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 <eliz@HIDDEN> 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: <f_k9g10frs0>
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--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 18:08:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 14:08:29 2020
Received: from localhost ([127.0.0.1]:60323 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSPE4-0002zx-Pd
	for submit <at> 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 <pipcet@HIDDEN>) id 1jSPE3-0002zl-Al
 for 40845 <at> 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 <at> 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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83mu6z7em5.fsf@HIDDEN> <17307310-2afc-7941-8a48-5cd345d1ad63@HIDDEN>
 <83k1237b2a.fsf@HIDDEN> <bd59b4a7-6fcb-183b-9439-27fc239b8eaa@HIDDEN>
 <20200425174651.GC82687@HIDDEN>
In-Reply-To: <20200425174651.GC82687@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Sat, 25 Apr 2020 18:07:45 +0000
Message-ID: <CAOqdjBegFqX2wTyoMvUrMfvZjxNiuS8hKwQc0ibWQcQc9n9L=g@HIDDEN>
Subject: Re: bug#40845: SVG rendering issues
To: Alan Third <alan@HIDDEN>,
 =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= <cpitclaudel@HIDDEN>, 
 Eli Zaretskii <eliz@HIDDEN>, 40845 <at> debbugs.gnu.org, pipcet@HIDDEN
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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Sat, Apr 25, 2020 at 5:46 PM Alan Third <alan@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 18:07:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 14:07:37 2020
Received: from localhost ([127.0.0.1]:60319 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSPDF-0002yV-Eq
	for submit <at> 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 <eliz@HIDDEN>) id 1jSPDD-0002yJ-Ow
 for 40845 <at> 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 <eliz@HIDDEN>)
 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <CAOqdjBcD10MSN6faJxp4bBgwfm6Y1M2wrTy28Uib7hYzquOQsg@HIDDEN>
 (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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83o8rf7fc0.fsf@HIDDEN>
 <CAOqdjBdcLp0AviU1vf7ZWDcdsfnuDW8X+CGEB0dam5+7NvqwjQ@HIDDEN>
 <83lfmj7dh7.fsf@HIDDEN>
 <CAOqdjBcD10MSN6faJxp4bBgwfm6Y1M2wrTy28Uib7hYzquOQsg@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 40845
Cc: cpitclaudel@HIDDEN, 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Sat, 25 Apr 2020 17:38:31 +0000
> Cc: cpitclaudel@HIDDEN, 40845 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 17:47:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 13:47:00 2020
Received: from localhost ([127.0.0.1]:60301 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSOtH-0000Pa-Uq
	for submit <at> 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 <alan@HIDDEN>) id 1jSOtG-0000PL-6T
 for 40845 <at> 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 <alan@HIDDEN>
To: =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel <cpitclaudel@HIDDEN>
Subject: Re: bug#40845: SVG rendering issues
Message-ID: <20200425174651.GC82687@HIDDEN>
Mail-Followup-To: Alan Third <alan@HIDDEN>,
 =?iso-8859-1?Q?Cl=E9ment?= Pit-Claudel <cpitclaudel@HIDDEN>,
 Eli Zaretskii <eliz@HIDDEN>, 40845 <at> debbugs.gnu.org,
 pipcet@HIDDEN
References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83mu6z7em5.fsf@HIDDEN>
 <17307310-2afc-7941-8a48-5cd345d1ad63@HIDDEN>
 <83k1237b2a.fsf@HIDDEN>
 <bd59b4a7-6fcb-183b-9439-27fc239b8eaa@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <bd59b4a7-6fcb-183b-9439-27fc239b8eaa@HIDDEN>
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 40845
Cc: Eli Zaretskii <eliz@HIDDEN>, 40845 <at> debbugs.gnu.org, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 17:39:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 13:39:15 2020
Received: from localhost ([127.0.0.1]:60297 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSOln-0000E6-28
	for submit <at> 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 <pipcet@HIDDEN>) id 1jSOll-0000Dr-IW
 for 40845 <at> 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 <at> 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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83o8rf7fc0.fsf@HIDDEN>
 <CAOqdjBdcLp0AviU1vf7ZWDcdsfnuDW8X+CGEB0dam5+7NvqwjQ@HIDDEN>
 <83lfmj7dh7.fsf@HIDDEN>
In-Reply-To: <83lfmj7dh7.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Sat, 25 Apr 2020 17:38:31 +0000
Message-ID: <CAOqdjBcD10MSN6faJxp4bBgwfm6Y1M2wrTy28Uib7hYzquOQsg@HIDDEN>
Subject: Re: bug#40845: SVG rendering issues
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 40845
Cc: cpitclaudel@HIDDEN, 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Sat, Apr 25, 2020 at 4:10 PM Eli Zaretskii <eliz@HIDDEN> wrote:
> > From: Pip Cet <pipcet@HIDDEN>
> > Date: Sat, 25 Apr 2020 15:48:39 +0000
> > Cc: cpitclaudel@HIDDEN, 40845 <at> debbugs.gnu.org
> >
> > On Sat, Apr 25, 2020 at 3:30 PM Eli Zaretskii <eliz@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 17:24:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 13:24:22 2020
Received: from localhost ([127.0.0.1]:60284 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSOXO-0008J8-88
	for submit <at> 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 <cpitclaudel@HIDDEN>) id 1jSOXN-0008Ix-45
 for 40845 <at> 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 <at> 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 <eliz@HIDDEN>
References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83mu6z7em5.fsf@HIDDEN> <17307310-2afc-7941-8a48-5cd345d1ad63@HIDDEN>
 <83k1237b2a.fsf@HIDDEN>
From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= <cpitclaudel@HIDDEN>
Message-ID: <bd59b4a7-6fcb-183b-9439-27fc239b8eaa@HIDDEN>
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@HIDDEN>
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 <at> debbugs.gnu.org, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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).





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 17:03:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 13:03:11 2020
Received: from localhost ([127.0.0.1]:60271 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSOCt-0007m5-N7
	for submit <at> 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 <eliz@HIDDEN>) id 1jSOCs-0007ls-3N
 for 40845 <at> 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 <eliz@HIDDEN>)
 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel <cpitclaudel@HIDDEN>
In-Reply-To: <17307310-2afc-7941-8a48-5cd345d1ad63@HIDDEN> (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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83mu6z7em5.fsf@HIDDEN> <17307310-2afc-7941-8a48-5cd345d1ad63@HIDDEN>
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 <at> debbugs.gnu.org, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 40845 <at> debbugs.gnu.org
> From: Clément Pit-Claudel <cpitclaudel@HIDDEN>
> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 16:42:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 12:42:18 2020
Received: from localhost ([127.0.0.1]:60255 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSNsf-0007H3-8Z
	for submit <at> 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 <cpitclaudel@HIDDEN>) id 1jSNsd-0007Go-FE
 for 40845 <at> 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 <at> 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 <eliz@HIDDEN>, Pip Cet <pipcet@HIDDEN>
References: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83mu6z7em5.fsf@HIDDEN>
From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= <cpitclaudel@HIDDEN>
Message-ID: <17307310-2afc-7941-8a48-5cd345d1ad63@HIDDEN>
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@HIDDEN>
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 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On 25/04/2020 11.46, Eli Zaretskii wrote:
>> From: Pip Cet <pipcet@HIDDEN>
>> Date: Sat, 25 Apr 2020 14:34:11 +0000
>> Cc: 40845 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 16:11:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 12:11:06 2020
Received: from localhost ([127.0.0.1]:60244 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSNOU-0006XG-6b
	for submit <at> 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 <eliz@HIDDEN>) id 1jSNOP-0006Wk-Hs
 for 40845 <at> 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 <eliz@HIDDEN>)
 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <CAOqdjBdcLp0AviU1vf7ZWDcdsfnuDW8X+CGEB0dam5+7NvqwjQ@HIDDEN>
 (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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83o8rf7fc0.fsf@HIDDEN>
 <CAOqdjBdcLp0AviU1vf7ZWDcdsfnuDW8X+CGEB0dam5+7NvqwjQ@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 40845
Cc: cpitclaudel@HIDDEN, 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Sat, 25 Apr 2020 15:48:39 +0000
> Cc: cpitclaudel@HIDDEN, 40845 <at> debbugs.gnu.org
> 
> On Sat, Apr 25, 2020 at 3:30 PM Eli Zaretskii <eliz@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 15:49:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 11:49:23 2020
Received: from localhost ([127.0.0.1]:60236 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSN3T-00061y-3I
	for submit <at> 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 <pipcet@HIDDEN>) id 1jSN3R-00061k-9L
 for 40845 <at> 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 <at> 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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 <83o8rf7fc0.fsf@HIDDEN>
In-Reply-To: <83o8rf7fc0.fsf@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Sat, 25 Apr 2020 15:48:39 +0000
Message-ID: <CAOqdjBdcLp0AviU1vf7ZWDcdsfnuDW8X+CGEB0dam5+7NvqwjQ@HIDDEN>
Subject: Re: bug#40845: SVG rendering issues
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 40845
Cc: cpitclaudel@HIDDEN, 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Sat, Apr 25, 2020 at 3:30 PM Eli Zaretskii <eliz@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 15:46:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 11:46:46 2020
Received: from localhost ([127.0.0.1]:60232 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSN0v-0005y4-WC
	for submit <at> 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 <eliz@HIDDEN>) id 1jSN0g-0005xX-EB
 for 40845 <at> 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 <eliz@HIDDEN>)
 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 (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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 40845
Cc: cpitclaudel@HIDDEN, 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Sat, 25 Apr 2020 14:34:11 +0000
> Cc: 40845 <at> 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);




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 15:31:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 11:31:00 2020
Received: from localhost ([127.0.0.1]:60228 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSMlg-0005cH-KK
	for submit <at> 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 <eliz@HIDDEN>) id 1jSMle-0005c4-Sq
 for 40845 <at> 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 <eliz@HIDDEN>)
 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
 (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@HIDDEN>
 <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 40845
Cc: cpitclaudel@HIDDEN, 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Pip Cet <pipcet@HIDDEN>
> Date: Sat, 25 Apr 2020 14:34:11 +0000
> Cc: 40845 <at> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at 40845 <at> debbugs.gnu.org:


Received: (at 40845) by debbugs.gnu.org; 25 Apr 2020 14:34:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 10:34:56 2020
Received: from localhost ([127.0.0.1]:60189 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSLtP-0004FN-IG
	for submit <at> 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 <pipcet@HIDDEN>) id 1jSLtN-0004FA-7S
 for 40845 <at> 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 <at> 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@HIDDEN>
In-Reply-To: <72ebf5eb-6b00-ebb4-dab3-a047e35ae1ae@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Date: Sat, 25 Apr 2020 14:34:11 +0000
Message-ID: <CAOqdjBeJOD0J6m8=0nJ_oBs_NE0cMZQHHQfTViK3NaCk50KRkw@HIDDEN>
Subject: Re: bug#40845: SVG rendering issues
To: =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= <cpitclaudel@HIDDEN>
Content-Type: multipart/mixed; boundary="0000000000003afedd05a41e62fe"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 40845
Cc: 40845 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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
<cpitclaudel@HIDDEN> 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: <f_k9fq3vr70>
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--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 25 Apr 2020 12:19:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 25 08:19:07 2020
Received: from localhost ([127.0.0.1]:58966 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jSJlz-0006sn-2F
	for submit <at> 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 <cpitclaudel@HIDDEN>) id 1jSJlx-0006se-4H
 for submit <at> 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 <cpitclaudel@HIDDEN>) id 1jSJlw-00054f-Jc
 for bug-gnu-emacs@HIDDEN; 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 <cpitclaudel@HIDDEN>) id 1jSJlw-0002pu-0j
 for bug-gnu-emacs@HIDDEN; 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 <cpitclaudel@HIDDEN>)
 id 1jSJlv-0002ji-JO
 for bug-gnu-emacs@HIDDEN; Sat, 25 Apr 2020 08:19:03 -0400
Received: by mail-qk1-x730.google.com with SMTP id 20so13062661qkl.10
 for <bug-gnu-emacs@HIDDEN>; 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 <bug-gnu-emacs@HIDDEN>
 (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 <bug-gnu-emacs@HIDDEN>
From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= <cpitclaudel@HIDDEN>
Autocrypt: addr=clement.pitclaudel@HIDDEN; 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@HIDDEN>
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@HIDDEN; 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 <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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.




Acknowledgement sent to Clément Pit-Claudel <cpitclaudel@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#40845; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Sun, 3 May 2020 14:30:01 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.