From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Text shadows Date: Sun, 12 Mar 2023 11:14:48 +0200 Message-ID: <83edpuuy9j.fsf@gnu.org> References: <72650A07-DEC8-4E08-A524-5C7AF804F3CB@gmail.com> <83mt4iv3xa.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20194"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Kai Ma Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 12 10:15:52 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pbHnz-000539-Rz for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Mar 2023 10:15:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pbHnE-00049H-CZ; Sun, 12 Mar 2023 05:15:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pbHnC-000495-KB for emacs-devel@gnu.org; Sun, 12 Mar 2023 05:15:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pbHnB-00039w-QL; Sun, 12 Mar 2023 05:15:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=YHWHnPLGDdNDrIs+ecBBtW+68xADdrKP480Zfa+lJWA=; b=e21E6YIzHD8AcpxKIiV6 E4s3QcEoJ0rga0Pe2WypZ9/zWl2MtjZLPb4pVp1ZoJeOsN8amI6tQKy92Lfgk2U7H8ET4xv2yODOI Olhf4n22fIfr6395FU65wyFBjKRt+1u2CMZvmHrv/WjksEigyyUA6xHwzfSWNvzVMO9pLOiD/OCRd lBZeqF3iw2zuENQ0rO9XmqywLacEiTzQTXXp4QmxWESLf+Qno6FSwYiq4+j0pwMwThji79cQqnIEP JZcS9nXSWR1Uace9/R86zJh9y4B6aB62OHyXleabEmzyhj8zmkFYXoMuXmOINkkV1nRkRwhbR3CCr 75dFi2VunoqOpA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pbHnA-0007Mi-Kl; Sun, 12 Mar 2023 05:15:00 -0400 In-Reply-To: (message from Kai Ma on Sun, 12 Mar 2023 16:24:17 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304356 Archived-At: > From: Kai Ma > Date: Sun, 12 Mar 2023 16:24:17 +0800 > Cc: emacs-devel@gnu.org > > > Which parts of the feature implementation really require Cairo? IOW, > > why cannot this be available to non-Cairo builds as well? > > Theoretically, nothing. I targeted Cairo because (I think) it is the most popular option on GNU/Linux. > > Speaking of this specific implementation, gaussian_blur() relies on a specific Cairo image format ARGB32, (this assumption could be easily removed), and then it is used by ftcrfont_draw() to generate shadows. > > I don’t know whether non-Cairo builds (non-cairo X, win32) can/should use gaussian_blur() though, since I’m not familiar with them. Would you please investigate that aspect? E.g., does Firefox support this without Cairo, and if so, how? At worst, perhaps it would be good enough not to support blurring on some platforms, or support it by some minor modification of the color? Or maybe we could implement the equivalent of gaussian_blur in our code? > >> This feature adds a new face attribute :shadow, and accepts values like: > >> > >> - FLOAT how much blurring? > >> - (FLOAT . COLOR) additionally, specifies a color for the shadow > >> - (FLOAT COLOR OFFSET) additionally, specifies an offset (x . y) > > > > I think at least in some GUI systems the offset is specified as radius > > and angle. > > The shadow is generated by this process: > > - draw glyphs (in the shadow color) onto a blank canvas; > - apply the blurring function; > - copy the “shadow” back to the original canvas at the specified x-y coordinate. > > So I don’t think radius and angle is relevant here. The radius and angle are just polar specifications of the Cartesian X-offset and Y-offset, that's all. If the API needs Cartesian specification, it should be trivial to convert polar to Cartesian before calling the API.