From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steve Purcell Newsgroups: gmane.emacs.devel Subject: Re: sRGB color support in NS port [PATCH] Date: Sat, 21 Dec 2013 21:11:12 +0000 Message-ID: References: <23825B39C60F460E80B59C5ADF04F637@gmail.com> <83zjnv9yrp.fsf@gnu.org> <16B838CD-13DC-468E-94D1-108EBFE68F6D@swipnet.se> <7FA1C0353EC248D28B9E7242BA7BDFCC@gmail.com> <933E75DF-F665-46C0-8D82-111186A809B1@sanityinc.com> <3C0A35C3-5D2B-4E6A-9C63-9EE98056DC3A@swipnet.se> <1EE253E4-A38A-4747-A96C-F5ABC5C1CB2C@sanityinc.com> <52B5F992.2020505@harpegolden.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1387660292 25854 80.91.229.3 (21 Dec 2013 21:11:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Dec 2013 21:11:32 +0000 (UTC) Cc: Eli Zaretskii , =?windows-1252?Q?Jan_Dj=E4rv?= , Bozhidar Batsov , emacs-devel To: David De La Harpe Golden Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 21 22:11:36 2013 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 1VuTpg-0006Vm-Di for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2013 22:11:36 +0100 Original-Received: from localhost ([::1]:55615 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuTpf-000240-WF for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2013 16:11:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60078) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuTpY-00022I-9d for emacs-devel@gnu.org; Sat, 21 Dec 2013 16:11:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuTpT-0002MU-GN for emacs-devel@gnu.org; Sat, 21 Dec 2013 16:11:28 -0500 Original-Received: from h1189701.stratoserver.net ([85.214.32.38]:48174) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuTpL-0002Lf-Ee; Sat, 21 Dec 2013 16:11:15 -0500 Original-Received: from [192.168.1.112] (host109-158-248-123.range109-158.btcentralplus.com [109.158.248.123]) by h1189701.stratoserver.net (Postfix) with ESMTPSA id C2075820018; Sat, 21 Dec 2013 22:11:12 +0100 (CET) In-Reply-To: <52B5F992.2020505@harpegolden.net> X-Mailer: Apple Mail (2.1827) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 85.214.32.38 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:166709 Archived-At: Hi David, On 21 Dec 2013, at 20:26, David De La Harpe Golden = wrote: > But Emacs is presently primarily a (coding-friendly) text-editor = (leaving aside recent discussions about wysiwig word processing). So = sRGB, whatever its failings, seems fairly adequate for emacs' normal = duties. sRGB is obviously fine for ordinary text-editing and coding, you = don't need wide gamut for a few different syntax highlights, and it's = actively beneficial for the webdev guys. And cross-platform consistency = of emacs color themes might be something a lot of users want. Yes, there are a *lot* of themes out there, and some of the most popular = contain outrageous and unreliable hacks to compensate for the = inconsistent interpretation of rgb literals on different emacs = platforms: = https://github.com/sellout/emacs-color-theme-solarized/blob/master/solariz= ed-definitions.el#L43 Others assume (more sanely) that OS X users have an sRGB patch compiled = into their emacs, so that the theme will look the same as on Windows, = which is (as you note) the only other major emacs platform to = consistently handle plain #RRGGBB colours. > If emacs devs were to just up and declare: >=20 > """On color-management-capable platforms, where possible emacs shall = default to sRGB for interpretation of rgb triples without any explicit = color space declaration.""" >=20 > (and maybe a related: """emacs will adopt the static list of = HTML/CSS/SVG named-color definitions where applicable, superseding any = historical X11/emacs named-color definitions - and user-defined = named-colors on platforms that support them (i.e. X11) - where they = clash""" [3][4]) >=20 > ...that's a reasonable enough project decision if you ask me. Not sure = I'd bother even including an option to switch the default color space = for such unqualified triples to anything else (just maybe note that at = some future date a larger component value range may become valid, for = scRGB). Yes, I also believe such a declaration would be extremely helpful, and a = big improvement on the current situation. > But do bear in mind X11 has history here. The full X11 color = specification string syntax that is fundamentally where emacs gets its = notions of how to interpret color specifications has long included = support for explicitly device-independent colors with a color space = qualification prefix like e.g. "CIEXYZ:x/y/z". Though no-one ever = added support for "srgb:r/g/b" to date which is a shame, and it may be = difficult to find X people who care to do so now, with so many treating = X as legacy and looking to Wayland (and I imagine that'll almost = certainly default to sRGB, though haven't checked). Yes, it does look like Wayland plan to default to sRGB: http://www.chaosreigns.com/wiki/Wayland_design_documents_and_drawing > Unfortunately, "#RRGGBB" and "rgb:r/g/b" and "rgbi:r/g/b" are all = _explicitly defined_ to be in the vague device-dependent space in the = X11 syntax (man XParseColors). So if emacs DOES decide the above, X11 = color handling code will need work: X11 emacs wouldn't be able to just = hand off all color strings to X11 for resolution any more, it would have = to treat color-space-unqualified triples (and perhaps named colors) = differently to X11 itself. Right, so in summary, without any immediate changes emacs on X11 would = be unaffected by any standardisation on sRGB, but over time further work = could be undertaken on that platform to ensure that those =93plain=94 = RGB colour specs are interpreted as well-defined sRGB colours. Makes = sense. > (The alternative, changing ns/mac and w32 to treat #RRGGBB as = device-dependent and require explicit color space prefixing for anything = else for full "feature"-compatibility with X11, doesn't seem all that = attractive, but would also be consistent... I mention it for = completeness) Agreed. -Steve=