From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs Mac port Date: Wed, 30 Dec 2015 11:32:59 +0100 Message-ID: <5683B2DB.7000209@gmail.com> References: <87bn9a8an8.fsf@isaac.fritz.box> <5682CA30.904@gmail.com> <5682CC68.8070205@yandex.ru> <5682D13E.7090202@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hvsu9l33wuCSftIM3U6IHmsKQbwM6A6I9" X-Trace: ger.gmane.org 1451471628 14846 80.91.229.3 (30 Dec 2015 10:33:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Dec 2015 10:33:48 +0000 (UTC) Cc: emacs-devel@gnu.org, dgutov@yandex.ru To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 30 11:33:36 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aEE4V-0000xD-0q for ged-emacs-devel@m.gmane.org; Wed, 30 Dec 2015 11:33:35 +0100 Original-Received: from localhost ([::1]:51739 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEE4U-0006Kw-CQ for ged-emacs-devel@m.gmane.org; Wed, 30 Dec 2015 05:33:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEE4B-0006Kl-In for emacs-devel@gnu.org; Wed, 30 Dec 2015 05:33:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aEE46-0003V1-LL for emacs-devel@gnu.org; Wed, 30 Dec 2015 05:33:15 -0500 Original-Received: from mout.kundenserver.de ([212.227.126.133]:61990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aEE46-0003Ut-CG; Wed, 30 Dec 2015 05:33:10 -0500 Original-Received: from [192.168.1.82] ([109.24.225.43]) by mrelayeu.kundenserver.de (mreue003) with ESMTPSA (Nemesis) id 0ME295-1aTrNy1UNz-00HRou; Wed, 30 Dec 2015 11:33:09 +0100 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: X-Provags-ID: V03:K0:Gb5t+cCP2N+tgzMiO63tsX025Fo/HtrHVNWVMDiWwLT2oWIv11/ f8QPBnXStHK+KtzgqTllMvtapx5dTDdf2xT7a+evgDibZBe8SEWRLChayoTPcqlgtsu1pOm 7Vbox2e6Os7ublvkwQJECapu5WyJtw3eTiphjZqDf35u7TnBvyYYLIwE+oRqU5cGtx75J03 xno8JGxe9MYRTqq0nPKkg== X-UI-Out-Filterresults: notjunk:1;V01:K0:TdNN3Qcdiyk=:tEn8hrG8J7ZG7pU6ASGayz gyBeEoienE7DXGB/X8VO6K4hZqAjNE46XVr+1F1j0ISFVM9a+9NapjlP4VA6mkVh3wGh04LET XyuIO82JUAp9XIok+Q+aW3MuVxMSKCefDR+2vRSgOMcFx5hw9lOPWEmnnwYlEYjvLnS2ofbwx ga6+jsDo7o/zjB1AUjbWMrYxWKxd+0XcRxMukQJjRGAOVj4yY8/KfPeuS0OqTu2zTyd/2qZ/S 5jF13ut2QBosHWY2vtrePFG0kyjhxStekIsbRXMI670unTAtjk7ggOpHHw/Suy5YMWx2wHhcz HtG2KIQeChLMHeDLhuUvXPZWSvKNGenii6Odf0/OLl5eU7w6wppefi35gaOBUsmqE2LHSRJN5 w2kNvWh3CIkbFtLG/+xfiTjMG8zE9TtbVQO7RUvotcqCSJkqImHZSaU0bn9maom/BGLWjFLPy IxcZxEA8zOsllKDDGES57KekpcLjEqbSBcTtdqzymmx/rj0I2QsWCg6HteSCTBijH1rPgtrQU ob2wEriMOQbfWLIhNWPRHIfujUp5B6iEzM3YXGwlOtMcnFlQs1HdLTbxF7Sa64SAfdEvBLe8G 9AL0UW5lkW3S+KwFTf5cikCyg2/FbT+GjsD6NYR+Xrh21O2WmvaV7m4RX9QSVPaTguEAA472j hEcAD57rhxha2p94gkD1tnNwK3ml038nqP4YRjRZCu4TAdNl9T5USmN1abL3a+93Qrik= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.126.133 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:197164 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hvsu9l33wuCSftIM3U6IHmsKQbwM6A6I9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/30/2015 07:11 AM, Richard Stallman wrote: > To correct this technical problem entails (1) putting support into X > display for these features and (2) making Emacs interface to them. > Since (1) is the hard job and (2) is comparatively easy, our proper > technical response is to urge people to work on (1). Would you like > to work on it? If anyone knows a libXft maintainer, I'll be happy to talk to them; my em= ail to their mailing list gathered exactly one response, which I can unfo= rtunately not make any sense of: }} -------- Forwarded Message -------- }} Subject: Re: Color bitmap support in Xft? }} Date: Fri, 18 Dec 2015 08:16:37 +0100 }} From: Michael Titke }} To: xorg@lists.x.org }} }} Just add a video mode font (we'll need to "typeset" videos intext anyw= ay - what was layout then?) and replace user input with random noise wher= e DSP would have told those smart ones ... }} }} On 17/12/2015 21:23, Cl=C3=A9ment Pit--Claudel wrote: }} > Hi all, }} > }} > I'm looking into adding support for color emoji to Emacs. Color emoj= i use a new feature of OpenType fonts that allows font designers to embed= full-color images in a font for certain glyphs. Fonts such as Google Not= o Emoji or Apple Color Emoji thus have a table mapping certain Unicode po= ints to raster color images. This feature is frequently used on smartphon= es, and was more recently added to Chrome and Firefox (both get it throug= ht Freetype). }} > }} > Freetype has support for these multicolor glyphs since version 2.5 (= 2013). So does FontConfig (and, apparently, Skia). However, it does not s= eem to be possible to use this feature through Xft. }} > Has there been efforts to support it? }} > }} > IIUC, the required changes would involve extending case matches that= look at the FT_Pixel_Mode enumeration (it gained a new member FT_PIXEL_M= ODE_BGRA), and passing an extra flag to Freetype. Here is the relevant do= cumentation: }} > }} >> FT_PIXEL_MODE_BGRA }} >> }} >> An image with four 8-bit channels per pixel, representing a color }} >> image (such as emoticons) with alpha channel. For each pixel, the }} >> format is BGRA, which means, the blue channel comes first in memory= =2E }} >> The color channels are pre-multiplied and in the sRGB colorspace. F= or }} >> example, full red at half-translucent opacity will be represented a= s }} >> =E2=80=9800,00,80,80=E2=80=99, not =E2=80=9800,00,FF,80=E2=80=99. S= ee also FT_LOAD_COLOR. }} >> FT_LOAD_COLOR }} >> }} >> This flag is used to request loading of color embedded-bitmap }} >> images. The resulting color bitmaps, if available, will have the }} >> FT_PIXEL_MODE_BGRA format. When the flag is not used and color }} >> bitmaps are found, they will be converted to 256-level gray bitmaps= }} >> transparently. Those bitmaps will be in the FT_PIXEL_MODE_GRAY }} >> format }} > Has such an extension been discussed before? Or am I taking the wron= g approach? }} > }} > Cl=C3=A9ment. On the other hand, the person who implemented support in Freetype said th= at he would look into it (in an exchange at https://github.com/googlei18n= /color-emoji/issues/5). Having no experience with this (and seeing that a patch adding support fo= r it was proposed to libXft at http://lists.x.org/archives/xorg-devel/201= 5-August/047175.html last August but received no responses), I'm not sure= what more to do. Advice is very welcome though! Cl=C3=A9ment. --hvsu9l33wuCSftIM3U6IHmsKQbwM6A6I9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWg7LkAAoJEPqg+cTm90wj7U4QAKw8AZ+uENT4oJJBeMdDegcA yzKknLz3MBM/IjiISO6Dj5jypeL1htzVIxHq3u8bKvUheJs/5ep0DL+kOpOpWRnI flDTxcpu+dCMx8xpMRYpBlCyFgl13MNldgeN16pli+cVAgctGmliOuZngqk2Y/y5 zmsmG98ETlZJa78JVbcSisk8hFxpE7JUgq0WyrQqBAi9Vv+8G7y8OQrrWyQPgUuH A08QKLRVK5BPeicEi0gwYRwczG8v04IJxggBMZuZ8Yi1RZ+4q5BdCgpaxRZk2cBI NGEMGpW9JdoBiedPhsjt5uuhwyDPnYnireKTQCwKtU+xsBkk5rFz/nG8xWPeovVp FVsW60LWA0g9SxVckys9FLHeRTHqz7aPLarAnybJLfcp90dwPoNuY/Rnz6DKLbdQ Wb2D+7khCBedbQnPHgTvzjbbDPXQpu9bfPdtU9YNwMIcLHeqWJu9s2gXtFZHecHc 0AFwJvC7pMo4sDab4fUC9atMyjOTUV895SDVGYTRagPZsGlR6SsE4Bdneg3gVZJD BPHKFIadQgLn5bA8eoidCE6C2OkXo0zAPPyd+76WuF0jLbZNSYhS9NMEZW0BT0TX R97UiS62LQkC5/h5/5dewM5j8pmYlJNvq2/vva+cHzG3IkggOlGaj8xhoRyACFPD wkb7QHNAFAE5Ai9uY5us =tpMn -----END PGP SIGNATURE----- --hvsu9l33wuCSftIM3U6IHmsKQbwM6A6I9--