* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. [not found] <E1PArgx-0006dS-00@quimby.gnus.org> @ 2010-10-26 23:58 ` Lars Magne Ingebrigtsen 2010-10-27 0:15 ` Katsumi Yamaoka 2010-10-27 18:06 ` Ted Zlatanov 0 siblings, 2 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-10-26 23:58 UTC (permalink / raw) To: ding Katsumi Yamaoka <yamaoka@jpl.org> writes: > +(defun shr-tag-div (cont) > + (shr-ensure-newline) > + (shr-indent) > + (shr-generic cont) > + (shr-ensure-newline)) I'm not sure this is actually helpful for rendering. Very often the div is just used as a container, and the css spells out that there should be no "rendering" effect of the div. (Many people haven't heard of span. :-)) So that's why I left the div rendering be null. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-10-26 23:58 ` [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added Lars Magne Ingebrigtsen @ 2010-10-27 0:15 ` Katsumi Yamaoka 2010-10-27 0:22 ` Katsumi Yamaoka 2010-10-27 0:28 ` Lars Magne Ingebrigtsen 2010-10-27 18:06 ` Ted Zlatanov 1 sibling, 2 replies; 67+ messages in thread From: Katsumi Yamaoka @ 2010-10-27 0:15 UTC (permalink / raw) To: ding Lars Magne Ingebrigtsen wrote: > Katsumi Yamaoka <yamaoka@jpl.org> writes: >> +(defun shr-tag-div (cont) >> + (shr-ensure-newline) >> + (shr-indent) >> + (shr-generic cont) >> + (shr-ensure-newline)) > I'm not sure this is actually helpful for rendering. Very often the div > is just used as a container, and the css spells out that there should be > no "rendering" effect of the div. (Many people haven't heard of span. > :-)) So that's why I left the div rendering be null. But many business mails I receive assume that <div>...</div> represents a paragraph, , i.e., text within the tag begins with and end with newlines. For instance: <div>There are two items:</div> <div>1 foo</div> <div>2 bar</div> shr rendered this as: There are two items: 1 foo 2 bar But it should be: There are two items: 1 foo 2 bar If a mail contains text/plain and text/plain parts as multipart/alternative, now both are displayed similarly. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-10-27 0:15 ` Katsumi Yamaoka @ 2010-10-27 0:22 ` Katsumi Yamaoka 2010-10-27 0:28 ` Lars Magne Ingebrigtsen 1 sibling, 0 replies; 67+ messages in thread From: Katsumi Yamaoka @ 2010-10-27 0:22 UTC (permalink / raw) To: ding Katsumi Yamaoka wrote: > If a mail contains text/plain and text/plain parts as html ;-) > multipart/alternative, now both are displayed similarly. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-10-27 0:15 ` Katsumi Yamaoka 2010-10-27 0:22 ` Katsumi Yamaoka @ 2010-10-27 0:28 ` Lars Magne Ingebrigtsen 2010-10-27 0:43 ` Katsumi Yamaoka 1 sibling, 1 reply; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-10-27 0:28 UTC (permalink / raw) To: ding Katsumi Yamaoka <yamaoka@jpl.org> writes: > But many business mails I receive assume that <div>...</div> > represents a paragraph, , i.e., text within the tag begins with > and end with newlines. For instance: > > <div>There are two items:</div> > <div>1 foo</div> > <div>2 bar</div> > > shr rendered this as: > > There are two items: 1 foo 2 bar > > But it should be: > > There are two items: > 1 foo > 2 bar Yeah, that's bad, but stuff like This is a sentence with <div style="inline; color: blue;">blue</div> text from someone who doesn't know about span. will be rendered as This is a sentence with blue text from someone who doesn't know about span. instead of This is a sentence with blue text from someone who doesn't know about span. I'm not sure what's worse, or what's more common. Just leave it as is now (with the ensure-newline stuff), and we'll see how things look... Of course, we could start parsing the CSS, but then we'd have to have something else that shr could stand for, because it wouldn't be "Simple HTML Renderer" any more. :-) I took a stab at it for "color" in span, but I'm not particularly satisfied with the result. That is, somebody has <span color="blue">, which renders the text totally unreadable for me, because I use a black background. So I was thinking about either backing that out again or... er... well, I don't have an "or". :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-10-27 0:28 ` Lars Magne Ingebrigtsen @ 2010-10-27 0:43 ` Katsumi Yamaoka 0 siblings, 0 replies; 67+ messages in thread From: Katsumi Yamaoka @ 2010-10-27 0:43 UTC (permalink / raw) To: ding Lars Magne Ingebrigtsen wrote: > Yeah, that's bad, but stuff like > This is a sentence with <div style="inline; color: blue;">blue</div> > text from someone who doesn't know about span. > will be rendered as > This is a sentence with > blue > text from someone who doesn't know about span. > instead of > This is a sentence with blue text from someone who doesn't know about > span. Oh, that's too bad. I only know that many web pages describe like this: Browsers usually place a line break before and after the div element. (This example is from: http://www.w3schools.com/tags/tag_div.asp) > I'm not sure what's worse, or what's more common. Just leave it as is > now (with the ensure-newline stuff), and we'll see how things look... > Of course, we could start parsing the CSS, but then we'd have to have > something else that shr could stand for, because it wouldn't be "Simple > HTML Renderer" any more. :-) Agreed. ;-) > I took a stab at it for "color" in span, but I'm not particularly > satisfied with the result. That is, somebody has <span color="blue">, > which renders the text totally unreadable for me, because I use a black > background. So I was thinking about either backing that out again > or... er... well, I don't have an "or". :-) ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-10-26 23:58 ` [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added Lars Magne Ingebrigtsen 2010-10-27 0:15 ` Katsumi Yamaoka @ 2010-10-27 18:06 ` Ted Zlatanov 2010-10-29 23:18 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 67+ messages in thread From: Ted Zlatanov @ 2010-10-27 18:06 UTC (permalink / raw) To: ding On Wed, 27 Oct 2010 01:58:28 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Very often the div is just used as a container, and the css spells LMI> out that there should be no "rendering" effect of the div. (Many LMI> people haven't heard of span. :-)) There are very good reasons to use DIV instead of SPAN elements for layout. I won't bore you with the details, but it's surprisingly annoying to use SPANs in older browsers and in certain situations. On Wed, 27 Oct 2010 02:28:32 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Of course, we could start parsing the CSS, but then we'd have to have LMI> something else that shr could stand for, because it wouldn't be "Simple LMI> HTML Renderer" any more. :-) Parsing CSS is not hard. HTML layout according to the CSS styles is very hard and I don't think it should be attempted (I said a while back that it would require many man-years to get it right). But a few CSS properties could be interpreted: some properties I list below for appearance and "display" and "visibility" for layout. The renderer doesn't have to be perfect but it could be usable. Here's the appearance properties list that IMO would make sense in Emacs: border background-color color text-decoration text-transform line-height font-family font-style font-size font-weight list-style list-style-type list-style-image list-style-position For DIV vs SPAN, if "display" is "block" then the element should be rendered by itself. And DIV elements have display:block by default in all user agents. Also at a minimum "visibility:none" should be honored. If you want to support CSS, you have to parse referenced CSS stylesheets. I think that's not a big burden for shr.el and would make it much better. But otherwise let's not try to support DIVs specifically; stick to HTML 3.2 (http://www.w3.org/TR/REC-html32.html) and don't do anything extra for unknown tags. LMI> I took a stab at it for "color" in span, but I'm not particularly LMI> satisfied with the result. That is, somebody has <span color="blue">, LMI> which renders the text totally unreadable for me, because I use a black LMI> background. So I was thinking about either backing that out again LMI> or... er... well, I don't have an "or". :-) I think you need to interpret background-color? Ted ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-10-27 18:06 ` Ted Zlatanov @ 2010-10-29 23:18 ` Lars Magne Ingebrigtsen 2010-11-09 22:25 ` Ted Zlatanov 0 siblings, 1 reply; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-10-29 23:18 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > Parsing CSS is not hard. Well, yes and no. Parsing <p style=".."> is easy, but getting a machinery in place to handle <p class=".."> and inheritance and stuff is a bit of work, I think. > Here's the appearance properties list that IMO would make sense in Emacs: > > border > background-color > color color is problematic in the Gwene groups, at least, since the RSS feeds don't specify a default background colour. > text-decoration > text-transform > line-height Hm. line-height would be awkward to implement, wouldn't it? > font-family > font-style > font-size > font-weight Emacs' support for mixing fonts in the same buffer is so weak that I think this is best left unimplemented. I mean -- you can do it, but it usually looks awfully awful since mixing fonts of different widths makes all line breaking totally haphazard. > list-style > list-style-type > list-style-image > list-style-position And these I don't even know what is. :-) > For DIV vs SPAN, if "display" is "block" then the element should be > rendered by itself. And DIV elements have display:block by default in > all user agents. Also at a minimum "visibility:none" should be honored. I've been using shr on my Nokia e72 a bit, and the most annoying thing is actually the ALT texts on images. Most give no information of note, but just clutter up the text... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-10-29 23:18 ` Lars Magne Ingebrigtsen @ 2010-11-09 22:25 ` Ted Zlatanov 2010-11-09 22:47 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 67+ messages in thread From: Ted Zlatanov @ 2010-11-09 22:25 UTC (permalink / raw) To: ding On Sat, 30 Oct 2010 01:18:50 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Ted Zlatanov <tzz@lifelogs.com> writes: >> Parsing CSS is not hard. LMI> Well, yes and no. Parsing <p style=".."> is easy, but getting a LMI> machinery in place to handle <p class=".."> and inheritance and stuff is LMI> a bit of work, I think. There's also external and inline stylesheets. Let's say I parse those out and get the inheritance right, can you go from there? >> Here's the appearance properties list that IMO would make sense in Emacs: >> >> border >> background-color >> color LMI> color is problematic in the Gwene groups, at least, since the RSS feeds LMI> don't specify a default background colour. Ah, but the article's original CSS spec probably does :) >> text-decoration >> text-transform >> line-height LMI> Hm. line-height would be awkward to implement, wouldn't it? Dunno. It's not really necessary, but the other two are pretty trivial. text-transform can be uppercase, lowercase, or capitalize (default is none). text-decoration can be underline, overline, line-through, or blink (default is also none). >> font-family >> font-style >> font-size >> font-weight LMI> Emacs' support for mixing fonts in the same buffer is so weak that I LMI> think this is best left unimplemented. I mean -- you can do it, but it LMI> usually looks awfully awful since mixing fonts of different widths makes LMI> all line breaking totally haphazard. At least font-style could be useful (it can be normal, oblique, italic, or inherit). font-weight specifies bold (it can be bold, bolder, lighter, normal, or a number between 100 and 900 where 400 is normal and 800 is bold). So that's possible I think. >> list-style >> list-style-type >> list-style-image >> list-style-position LMI> And these I don't even know what is. :-) http://www.w3schools.com/css/css_list.asp Pretty simple stuff. It just replaces the default list item indicator with something else. Definitely needed is the armenian list-style-type :) >> For DIV vs SPAN, if "display" is "block" then the element should be >> rendered by itself. And DIV elements have display:block by default in >> all user agents. Also at a minimum "visibility:none" should be honored. LMI> I've been using shr on my Nokia e72 a bit, and the most annoying thing LMI> is actually the ALT texts on images. Most give no information of note, LMI> but just clutter up the text... OK. But display:block and visibility:none are the basic stuff needed to render HTML semi-properly. And you can put it on your resume. Ted ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-11-09 22:25 ` Ted Zlatanov @ 2010-11-09 22:47 ` Lars Magne Ingebrigtsen 2010-11-09 23:02 ` Steinar Bang ` (3 more replies) 0 siblings, 4 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-09 22:47 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > There's also external and inline stylesheets. Let's say I parse those > out and get the inheritance right, can you go from there? I'm not sure it's worth it... reading Gwene feeds with Gnus is more pleasant that reading them via a web browser, and part of that is that it's plainer text. Most of the CSS things are just visual noise. :-) (And get off my lawn! Courier should be enough for everybody!) >>> color > > LMI> color is problematic in the Gwene groups, at least, since the RSS feeds > LMI> don't specify a default background colour. > > Ah, but the article's original CSS spec probably does :) But we don't have the original CSS, usually... I wonder whether it's possible to do something creative with the colours. languagelog uses colouring to mark cited text, so if you're reading it in black-and-white, it can be difficult to understand. However, they use colours like "blue", which are impossible to read on a black background. So I wonder whether it's easy to write a function (or whether someone already has written) that would take two colours -- in this instance, "blue" (say #0000ff) and black, and transform the blue into a colour "light enough" to be read on a black background. (And the opposite with a white background, of course.) After thinking about if for 30 seconds, I don't see any immediately trivial solutions. If you implement that, then we'll see about doing real CSS handling in shr. :-) >>> text-decoration >>> text-transform >>> line-height > > LMI> Hm. line-height would be awkward to implement, wouldn't it? > > Dunno. It's not really necessary, but the other two are pretty trivial. > > text-transform can be uppercase, lowercase, or capitalize (default is > none). > > text-decoration can be underline, overline, line-through, or blink > (default is also none). The textual transforms might be nice to have, yeah... > At least font-style could be useful (it can be normal, oblique, italic, > or inherit). font-weight specifies bold (it can be bold, bolder, > lighter, normal, or a number between 100 and 900 where 400 is normal and > 800 is bold). So that's possible I think. Yes, those would be useful. >>> list-style >>> list-style-type >>> list-style-image >>> list-style-position > > LMI> And these I don't even know what is. :-) > > http://www.w3schools.com/css/css_list.asp > > Pretty simple stuff. It just replaces the default list item indicator > with something else. Definitely needed is the armenian list-style-type :) Doesn't seem very, er, essential. :-) > OK. But display:block and visibility:none are the basic stuff needed to > render HTML semi-properly. And you can put it on your resume. Those first would also be nice, but the second probably isn't very useful outside of a JS-enabled context, most of the time, I'd guess. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-11-09 22:47 ` Lars Magne Ingebrigtsen @ 2010-11-09 23:02 ` Steinar Bang 2010-11-10 9:54 ` Julien Danjou ` (2 subsequent siblings) 3 siblings, 0 replies; 67+ messages in thread From: Steinar Bang @ 2010-11-09 23:02 UTC (permalink / raw) To: ding >>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>: > (And get off my lawn! Courier should be enough for everybody!) Fixed width, yeah. But Courier only when it can't be avoided. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-11-09 22:47 ` Lars Magne Ingebrigtsen 2010-11-09 23:02 ` Steinar Bang @ 2010-11-10 9:54 ` Julien Danjou 2010-11-10 17:49 ` Colourspace (was: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.) Lars Magne Ingebrigtsen 2010-11-10 13:14 ` [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added Ted Zlatanov 2010-11-19 16:13 ` Julien Danjou 3 siblings, 1 reply; 67+ messages in thread From: Julien Danjou @ 2010-11-10 9:54 UTC (permalink / raw) To: ding On Tue, Nov 09 2010, Lars Magne Ingebrigtsen wrote: > So I wonder whether it's easy to write a function (or whether someone > already has written) that would take two colours -- in this instance, > "blue" (say #0000ff) and black, and transform the blue into a colour > "light enough" to be read on a black background. (And the opposite with > a white background, of course.) In rainbow-mode[1], I use luminance computing to determine if the background is light or dark. (defun rainbow-color-luminance (red green blue) "Calculate the luminance of color composed of RED, BLUE and GREEN." (floor (+ (* .2126 red) (* .7152 green) (* .0722 blue)) 256)) If it's > 128, you can assume the color is dark. I'm pretty sure there's a easy way to light or dark a color using its HSV representation and increasing/decreasing it's saturation and value. I can dig a bit and come up with some code if you want. :) [1] http://julien.danjou.info/rainbow-mode.html -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Colourspace (was: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.) 2010-11-10 9:54 ` Julien Danjou @ 2010-11-10 17:49 ` Lars Magne Ingebrigtsen 2010-11-10 19:09 ` Colourspace Julien Danjou 2010-11-18 18:49 ` Colourspace Ted Zlatanov 0 siblings, 2 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-10 17:49 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > I'm pretty sure there's a easy way to light or dark a color using its > HSV representation and increasing/decreasing it's saturation and value. > > I can dig a bit and come up with some code if you want. :) Yes, that would be great. And if there's a way to, er, ensure the "distance" between two colours -- one colour would be constant (the background colour), and one would be altered to have sufficient distance to be readable, but still retain something of its colour. It may be difficult to do generally (I mean, trying to make pink readable on a red background sounds hard), but it'd totally rock. :-) > [1] http://julien.danjou.info/rainbow-mode.html Nice. Are you pushing that to Emacs? Looks useful to me when fiddling with CSS files and the like. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colourspace 2010-11-10 17:49 ` Colourspace (was: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.) Lars Magne Ingebrigtsen @ 2010-11-10 19:09 ` Julien Danjou 2010-11-10 19:44 ` Colourspace Ted Zlatanov 2010-11-10 20:48 ` Colourspace Lars Magne Ingebrigtsen 2010-11-18 18:49 ` Colourspace Ted Zlatanov 1 sibling, 2 replies; 67+ messages in thread From: Julien Danjou @ 2010-11-10 19:09 UTC (permalink / raw) To: ding On Wed, Nov 10 2010, Lars Magne Ingebrigtsen wrote: > Yes, that would be great. And if there's a way to, er, ensure the > "distance" between two colours -- one colour would be constant (the > background colour), and one would be altered to have sufficient distance > to be readable, but still retain something of its colour. > > It may be difficult to do generally (I mean, trying to make pink > readable on a red background sounds hard), but it'd totally rock. :-) Fine, I'll give a try and see what I can do! >> [1] http://julien.danjou.info/rainbow-mode.html > > Nice. Are you pushing that to Emacs? Looks useful to me when fiddling > with CSS files and the like. I asked on emacs-devel, but it was refused. It has been added to the Emacs 24 packages.el, though. -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colourspace 2010-11-10 19:09 ` Colourspace Julien Danjou @ 2010-11-10 19:44 ` Ted Zlatanov 2010-11-10 19:56 ` Colourspace Julien Danjou 2010-11-10 20:48 ` Colourspace Lars Magne Ingebrigtsen 1 sibling, 1 reply; 67+ messages in thread From: Ted Zlatanov @ 2010-11-10 19:44 UTC (permalink / raw) To: ding On Wed, 10 Nov 2010 20:09:47 +0100 Julien Danjou <julien@danjou.info> wrote: JD> On Wed, Nov 10 2010, Lars Magne Ingebrigtsen wrote: >> Yes, that would be great. And if there's a way to, er, ensure the >> "distance" between two colours -- one colour would be constant (the >> background colour), and one would be altered to have sufficient distance >> to be readable, but still retain something of its colour. >> >> It may be difficult to do generally (I mean, trying to make pink >> readable on a red background sounds hard), but it'd totally rock. :-) JD> Fine, I'll give a try and see what I can do! In case it's helpful, here are the colors that most of my users liked for text background (the second one is the background). This was the starting point for the contrast data tables I mentioned. Color.BLACK, Color.WHITE Color.WHITE, Color.BLACK Color.RED.brighter(), Color.BLACK Color.LIGHT_GRAY, Color.BLACK Color.GREEN, Color.BLACK Color.YELLOW, Color.BLACK Color.PINK, Color.BLACK Color.BLUE, Color.YELLOW Color.ORANGE, Color.WHITE Color.MAGENTA, Color.WHITE Color.MAGENTA.brighter(), Color.WHITE Color.MAGENTA.darker(), Color.WHITE color_factory.getColor("burlywood"), Color.BLACK color_factory.getColor("violet"), Color.YELLOW.brighter() >>> [1] http://julien.danjou.info/rainbow-mode.html >> >> Nice. Are you pushing that to Emacs? Looks useful to me when fiddling >> with CSS files and the like. JD> I asked on emacs-devel, but it was refused. It has been added to the JD> Emacs 24 packages.el, though. IMO inclusion in Emacs 24's elpa.gnu.org is practically like inclusion in Emacs itself. It's actually better because pushing out an update is much easier for the package maintainer and installation/upgrade is much easier for the user. Chong Yidong is working with me on some way to do uploads to elpa.gnu.org. For now we have a VCS repository for the two of us and will take direct submissions. Ted ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colourspace 2010-11-10 19:44 ` Colourspace Ted Zlatanov @ 2010-11-10 19:56 ` Julien Danjou 2010-11-10 20:22 ` ELPA and Gnus (was: Colourspace) Ted Zlatanov 0 siblings, 1 reply; 67+ messages in thread From: Julien Danjou @ 2010-11-10 19:56 UTC (permalink / raw) To: Ted Zlatanov; +Cc: ding On Wed, Nov 10 2010, Ted Zlatanov wrote: > IMO inclusion in Emacs 24's elpa.gnu.org is practically like inclusion > in Emacs itself. It's actually better because pushing out an update is > much easier for the package maintainer and installation/upgrade is much > easier for the user. I tend to agree, but I dislike the fact that it draws a line in packages: distributed with Emacs and not distributed with Emacs. > Chong Yidong is working with me on some way to do uploads to > elpa.gnu.org. For now we have a VCS repository for the two of us and > will take direct submissions. That would be really really neat indeed. Currently there's rainbow mode but I've no clue how to synchronize my code but bothering you, which is not acceptable to me. :) Sorry for the off-topic. -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* ELPA and Gnus (was: Colourspace) 2010-11-10 19:56 ` Colourspace Julien Danjou @ 2010-11-10 20:22 ` Ted Zlatanov 2010-11-10 20:48 ` ELPA and Gnus Lars Magne Ingebrigtsen 0 siblings, 1 reply; 67+ messages in thread From: Ted Zlatanov @ 2010-11-10 20:22 UTC (permalink / raw) To: ding On Wed, 10 Nov 2010 20:56:03 +0100 Julien Danjou <julien@danjou.info> wrote: JD> On Wed, Nov 10 2010, Ted Zlatanov wrote: >> IMO inclusion in Emacs 24's elpa.gnu.org is practically like inclusion >> in Emacs itself. It's actually better because pushing out an update is >> much easier for the package maintainer and installation/upgrade is much >> easier for the user. JD> I tend to agree, but I dislike the fact that it draws a line in JD> packages: distributed with Emacs and not distributed with Emacs. That's a good thing. Emacs is already very bloated. We discussed distributing a snapshot of the packages with Emacs for users who don't have a network connection but that's a very rare case nowadays. But the intent is to eliminate that line; the only reason for a package to be distributed with Emacs should be to support its base functionality. >> Chong Yidong is working with me on some way to do uploads to >> elpa.gnu.org. For now we have a VCS repository for the two of us and >> will take direct submissions. JD> That would be really really neat indeed. Currently there's rainbow mode JD> but I've no clue how to synchronize my code but bothering you, which is JD> not acceptable to me. :) No, it's really OK to bug me. We'll announce something on emacs-devel when the status quo changes. Ted ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: ELPA and Gnus 2010-11-10 20:22 ` ELPA and Gnus (was: Colourspace) Ted Zlatanov @ 2010-11-10 20:48 ` Lars Magne Ingebrigtsen 2010-11-10 21:23 ` Ted Zlatanov 2010-11-11 9:06 ` Julien Danjou 0 siblings, 2 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-10 20:48 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > JD> I tend to agree, but I dislike the fact that it draws a line in > JD> packages: distributed with Emacs and not distributed with Emacs. > > That's a good thing. Emacs is already very bloated. I'm totally opposed to offloading things from Emacs, really. With the current development model, we're pretty sure that when an Emacs release comes, all the stuff pretty much works, because it's been through the strenuous QA process called "emacs-devel". I can go to any machine that has Emacs installed and say (for instance) `M-x grep', and I'm confident it'll work. It won't work the same across Emacs versions, but I don't have to download it on each machine, and I know that I'm not relying on a bit-rotted elpa archive. Any archive bit-rots, while something that's continually developed (like Emacs) suffers from that a lot less, because it's all just there. So as a user I hate the idea, and as a developer I like it even less. I just added a new command to Gnus that depends on org mode, and I did that because I know that org mode is in Emacs. If it weren't, I'd have hacked up something freestanding, and that's just code duplication. And it's not like the Emacs distribution is particularly large. It hasn't really grown much over the last decade, and disk sizes have soared, so it seems even more pointless now. Oh, and the way XEmacs bundled everything into packages was one of the reasons I hated using XEmacs, before Debian sorted that nonsense out and made the packages more or less go away. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: ELPA and Gnus 2010-11-10 20:48 ` ELPA and Gnus Lars Magne Ingebrigtsen @ 2010-11-10 21:23 ` Ted Zlatanov 2010-11-10 21:32 ` Lars Magne Ingebrigtsen 2010-11-11 9:06 ` Julien Danjou 1 sibling, 1 reply; 67+ messages in thread From: Ted Zlatanov @ 2010-11-10 21:23 UTC (permalink / raw) To: ding On Wed, 10 Nov 2010 21:48:10 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Any archive bit-rots, while something that's continually developed (like LMI> Emacs) suffers from that a lot less, because it's all just there. OK, but realize people that check Emacs out from a VCS are a small minority. Most users download a release. So how do you handle that other kind of bit rot? Do they download all of Emacs again because they need the updates to one package? And do you expect them to alpha- and beta-test all of Emacs to get one package updated? At least for elpa.gnu.org I expect the lag to be at most 1 day behind any package we support. I think that's reasonable. So bit-rot is not a real issue IMO. You should bring this up on emacs-devel. I'm sure the maintainers have opinions. LMI> So as a user I hate the idea, and as a developer I like it even less. I LMI> just added a new command to Gnus that depends on org mode, and I did LMI> that because I know that org mode is in Emacs. If it weren't, I'd have LMI> hacked up something freestanding, and that's just code duplication. Maybe bring this up on emacs-devel too. LMI> And it's not like the Emacs distribution is particularly large. It LMI> hasn't really grown much over the last decade, and disk sizes have LMI> soared, so it seems even more pointless now. Disk space is not an issue AFAIK. Ted ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: ELPA and Gnus 2010-11-10 21:23 ` Ted Zlatanov @ 2010-11-10 21:32 ` Lars Magne Ingebrigtsen 2010-11-11 13:19 ` Ted Zlatanov 0 siblings, 1 reply; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-10 21:32 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > OK, but realize people that check Emacs out from a VCS are a small > minority. Most users download a release. So how do you handle that > other kind of bit rot? Do they download all of Emacs again because they > need the updates to one package? And do you expect them to alpha- and > beta-test all of Emacs to get one package updated? No, as a happy Emacs user for oodles of years, I've mostly just used whatever version of Emacs that the distribution has included. (Well, ever since distributions started appearing.) (Except on my home machine, where I've tried to keep up a bit more with what's current, just because I've been curious, mostly. And hacking Emacs now and then. :-) elpa as a way to pull down packages meant for the next Emacs release would be nice (I had to install erc manually in previous Emacs iterations, for instance), but that's not what's envisioned, is it? As an Emacs-Backports repository, kind of. :-) > At least for elpa.gnu.org I expect the lag to be at most 1 day behind > any package we support. I think that's reasonable. So bit-rot is not a > real issue IMO. It's more a matter of taking responsibility. I mean, say w3 was in elpa. Would anybody step up to the plate and keep it up-to-date? With stuff that's in Emacs, people are doing that. I mean, I'm a lot more motivated to hack the Emacs version of browse-url than I would with something that kind of lives somewhere out there... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: ELPA and Gnus 2010-11-10 21:32 ` Lars Magne Ingebrigtsen @ 2010-11-11 13:19 ` Ted Zlatanov 2010-11-14 16:07 ` Lars Magne Ingebrigtsen 2010-11-15 15:43 ` Julien Danjou 0 siblings, 2 replies; 67+ messages in thread From: Ted Zlatanov @ 2010-11-11 13:19 UTC (permalink / raw) To: ding On Wed, 10 Nov 2010 22:32:03 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> elpa as a way to pull down packages meant for the next Emacs release LMI> would be nice (I had to install erc manually in previous Emacs LMI> iterations, for instance), but that's not what's envisioned, is it? LMI> As an Emacs-Backports repository, kind of. :-) I think I've confused everyone enough. Let's take this to emacs-devel and find out for sure. FWIW I'm not making any decisions about this, just suggestions. The Emacs maintainers have the final say AFAIK. On Thu, 11 Nov 2010 10:06:49 +0100 Julien Danjou <julien@danjou.info> wrote: JD> Who will be able to upload to ELPA? How do I fix packages? And if I JD> update a package that, let's say, depends on Emacs 24.2, how will Emacs JD> 24.1 user will do? Someone will have to fix it? But if I do not want to JD> fix it, who will fix it? We're just working this out; take it to emacs-devel to have a public discussion. I'm making suggestions as I said, but won't be making policies. But if we have the discussion there we'll have a more appropriate audience. Ted ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: ELPA and Gnus 2010-11-11 13:19 ` Ted Zlatanov @ 2010-11-14 16:07 ` Lars Magne Ingebrigtsen 2010-11-15 15:43 ` Julien Danjou 1 sibling, 0 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-14 16:07 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > But if we have the discussion there we'll have a more appropriate > audience. True. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: ELPA and Gnus 2010-11-11 13:19 ` Ted Zlatanov 2010-11-14 16:07 ` Lars Magne Ingebrigtsen @ 2010-11-15 15:43 ` Julien Danjou 1 sibling, 0 replies; 67+ messages in thread From: Julien Danjou @ 2010-11-15 15:43 UTC (permalink / raw) To: Ted Zlatanov; +Cc: ding On Thu, Nov 11 2010, Ted Zlatanov wrote: > We're just working this out; take it to emacs-devel to have a public > discussion. I'm making suggestions as I said, but won't be making > policies. But if we have the discussion there we'll have a more > appropriate audience. Done. -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: ELPA and Gnus 2010-11-10 20:48 ` ELPA and Gnus Lars Magne Ingebrigtsen 2010-11-10 21:23 ` Ted Zlatanov @ 2010-11-11 9:06 ` Julien Danjou 2010-11-14 16:07 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 67+ messages in thread From: Julien Danjou @ 2010-11-11 9:06 UTC (permalink / raw) To: ding On Wed, Nov 10 2010, Lars Magne Ingebrigtsen wrote: > I'm totally opposed to offloading things from Emacs, really. With the > current development model, we're pretty sure that when an Emacs release > comes, all the stuff pretty much works, because it's been through the > strenuous QA process called "emacs-devel". Clearly, I couldn't agree more with you Lars. What I'm a bit worried about too, is that I don't know how the full ELPA process is designed: Who will be able to upload to ELPA? How do I fix packages? And if I update a package that, let's say, depends on Emacs 24.2, how will Emacs 24.1 user will do? Someone will have to fix it? But if I do not want to fix it, who will fix it? -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: ELPA and Gnus 2010-11-11 9:06 ` Julien Danjou @ 2010-11-14 16:07 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-14 16:07 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > Who will be able to upload to ELPA? How do I fix packages? And if I > update a package that, let's say, depends on Emacs 24.2, how will Emacs > 24.1 user will do? Someone will have to fix it? But if I do not want to > fix it, who will fix it? I think we should do what Ted suggested and take the queries to emacs-devel... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colourspace 2010-11-10 19:09 ` Colourspace Julien Danjou 2010-11-10 19:44 ` Colourspace Ted Zlatanov @ 2010-11-10 20:48 ` Lars Magne Ingebrigtsen 2010-11-10 20:55 ` Colourspace Lars Magne Ingebrigtsen 1 sibling, 1 reply; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-10 20:48 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > I asked on emacs-devel, but it was refused. It has been added to the > Emacs 24 packages.el, though. What was the reason? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colourspace 2010-11-10 20:48 ` Colourspace Lars Magne Ingebrigtsen @ 2010-11-10 20:55 ` Lars Magne Ingebrigtsen 2010-11-11 8:59 ` Colourspace Julien Danjou 0 siblings, 1 reply; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-10 20:55 UTC (permalink / raw) To: ding Lars Magne Ingebrigtsen <larsi@gnus.org> writes: >> I asked on emacs-devel, but it was refused. It has been added to the >> Emacs 24 packages.el, though. > > What was the reason? Ok, I've read the thread. There were two competing packages, but none of them actually in Emacs, and then they were both just added to elpa without any explanation? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colourspace 2010-11-10 20:55 ` Colourspace Lars Magne Ingebrigtsen @ 2010-11-11 8:59 ` Julien Danjou 0 siblings, 0 replies; 67+ messages in thread From: Julien Danjou @ 2010-11-11 8:59 UTC (permalink / raw) To: ding On Wed, Nov 10 2010, Lars Magne Ingebrigtsen wrote: > Ok, I've read the thread. There were two competing packages, but none > of them actually in Emacs, and then they were both just added to elpa > without any explanation? The explanation are the one Ted provided on this list: no more packages in Emacs. :) -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colourspace 2010-11-10 17:49 ` Colourspace (was: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.) Lars Magne Ingebrigtsen 2010-11-10 19:09 ` Colourspace Julien Danjou @ 2010-11-18 18:49 ` Ted Zlatanov 1 sibling, 0 replies; 67+ messages in thread From: Ted Zlatanov @ 2010-11-18 18:49 UTC (permalink / raw) To: ding On Wed, 10 Nov 2010 18:49:56 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Julien Danjou <julien@danjou.info> writes: >> I'm pretty sure there's a easy way to light or dark a color using its >> HSV representation and increasing/decreasing it's saturation and value. >> >> I can dig a bit and come up with some code if you want. :) LMI> Yes, that would be great. And if there's a way to, er, ensure the LMI> "distance" between two colours -- one colour would be constant (the LMI> background colour), and one would be altered to have sufficient distance LMI> to be readable, but still retain something of its colour. LMI> It may be difficult to do generally (I mean, trying to make pink LMI> readable on a red background sounds hard), but it'd totally rock. :-) I remembered a good resource for color matching: http://colorschemedesigner.com The source code is JavaScript and so you can look at http://colorschemedesigner.com/js/colorschemedesigner.js. It has the whitespace removed but is otherwise readable. There is a "Colorblind" menu which tells you the percentages of the population that have some type of it and lets you test color schemes quickly as if you had that type of color blindness. Ted ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-11-09 22:47 ` Lars Magne Ingebrigtsen 2010-11-09 23:02 ` Steinar Bang 2010-11-10 9:54 ` Julien Danjou @ 2010-11-10 13:14 ` Ted Zlatanov 2010-11-19 16:13 ` Julien Danjou 3 siblings, 0 replies; 67+ messages in thread From: Ted Zlatanov @ 2010-11-10 13:14 UTC (permalink / raw) To: ding On Tue, 09 Nov 2010 23:47:19 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Ted Zlatanov <tzz@lifelogs.com> writes: >> There's also external and inline stylesheets. Let's say I parse those >> out and get the inheritance right, can you go from there? LMI> I'm not sure it's worth it... reading Gwene feeds with Gnus is more LMI> pleasant that reading them via a web browser, and part of that is that LMI> it's plainer text. Most of the CSS things are just visual noise. :-) OK, you're probably right since no one else has asked for CSS parsing. So I'll drop this unless there's demand. On Wed, 10 Nov 2010 10:54:06 +0100 Julien Danjou <julien@danjou.info> wrote: JD> On Tue, Nov 09 2010, Lars Magne Ingebrigtsen wrote: >> So I wonder whether it's easy to write a function (or whether someone >> already has written) that would take two colours -- in this instance, >> "blue" (say #0000ff) and black, and transform the blue into a colour >> "light enough" to be read on a black background. (And the opposite with >> a white background, of course.) JD> In rainbow-mode[1], I use luminance computing to determine if the JD> background is light or dark. JD> (defun rainbow-color-luminance (red green blue) JD> "Calculate the luminance of color composed of RED, BLUE and GREEN." JD> (floor (+ (* .2126 red) (* .7152 green) (* .0722 blue)) 256)) JD> If it's > 128, you can assume the color is dark. JD> I'm pretty sure there's a easy way to light or dark a color using its JD> HSV representation and increasing/decreasing it's saturation and value. JD> I can dig a bit and come up with some code if you want. :) JD> [1] http://julien.danjou.info/rainbow-mode.html I know the Sanselan Java library has lots of good code to manipulate colors. You may find it useful as a reference point. <aside> Well, there's a lot of research done on this in the context of painting and photography, but also UI research. I had to look into it for some GUI work just last year; there are several approaches depending on how you balance the need for the colors to look good together, contrast well, and reveal fine detail. The eye has very nonlinear sensitivity (each of the three types of cone cells has its own response curve) so you need to consult data tables and a simple HSV, RGB, etc. model as you suggest will not work. But even then things depend on the ambient light! And color-blind people, who usually just see color differently, are surprisingly common. My solution (in our codebase) was to find good colors manually. I was not happy with any of the existing solutions. So in my solution each color gets two data points: one for good contrast and one for good harmony (e.g. for constructing gradients). I did this for many points in the color space and then could approximate any requested color. When an approximation was wrong I added another data point. Finally, I allowed people to customize the data table. </aside> Ted ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-11-09 22:47 ` Lars Magne Ingebrigtsen ` (2 preceding siblings ...) 2010-11-10 13:14 ` [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added Ted Zlatanov @ 2010-11-19 16:13 ` Julien Danjou 2010-11-21 4:40 ` Lars Magne Ingebrigtsen 3 siblings, 1 reply; 67+ messages in thread From: Julien Danjou @ 2010-11-19 16:13 UTC (permalink / raw) To: ding On Tue, Nov 09 2010, Lars Magne Ingebrigtsen wrote: > So I wonder whether it's easy to write a function (or whether someone > already has written) that would take two colours -- in this instance, > "blue" (say #0000ff) and black, and transform the blue into a colour > "light enough" to be read on a black background. (And the opposite with > a white background, of course.) Well, I spent all my spare time since one week working on that, and I can say: that's not easy. Color is a very interesting subject, with a lot of research going on, and this one did not seems to have really researched yet. :-) Here's my journey. First, I've done experimentation based on luminance, but it's not enough obviously. You have also to consider color distance, because colors can have almost the same luminance but can be very different in chroma. Then, I've then done experimentation based on color distance in a HSV or HSL representation (yay 3D math), but that was no good enough too. After digging on the Internet, I found and implemented the CIEDE2000[1] formula, having some good results. With CIEDE2000 and luminance from the CIE L*a*b* representation of colors, I know have something which can barely says if 2 colors are almost the same to the human eyes. But unfortunately, the various Delta E formula does not really care about spatial disposition of images (or text), which does not mean this as a very reliable criteria. Because blue and yellow are very distinctive colors, but I can't read small text in yellow on a blue background. There's things like S-CIELAB which take spatial into accounts, but I don't think that's realisable for know in our case. So basically, so far, my code can eliminate a lot of colors that are really close and filter out very bad things like light grey on white, but it can't assure that you will be able to read the text correctly. I'll clean the code now and publish it online ASAP, since I think the CIEDE2000 implementation in elisp can *maybe* interest some people someday. So you'll be able to give it a try and look how it works. (If anybody knows a color expert, please, forward this mail to him/her. :-) [1] http://en.wikipedia.org/wiki/Color_difference#CIEDE2000 -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-11-19 16:13 ` Julien Danjou @ 2010-11-21 4:40 ` Lars Magne Ingebrigtsen 2010-11-21 13:55 ` Julien Danjou 0 siblings, 1 reply; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-21 4:40 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > So basically, so far, my code can eliminate a lot of colors that are > really close and filter out very bad things like light grey on white, > but it can't assure that you will be able to read the text correctly. It sounds good; when it's published I'll try reinstating the colour stuff in shr and give it a whirl. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added. 2010-11-21 4:40 ` Lars Magne Ingebrigtsen @ 2010-11-21 13:55 ` Julien Danjou 2010-11-21 18:38 ` Colour manipulation (was: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.) Lars Magne Ingebrigtsen 0 siblings, 1 reply; 67+ messages in thread From: Julien Danjou @ 2010-11-21 13:55 UTC (permalink / raw) To: ding On Sun, Nov 21 2010, Lars Magne Ingebrigtsen wrote: > It sounds good; when it's published I'll try reinstating the colour > stuff in shr and give it a whirl. I've published things here: http://git.naquadah.org/?p=~jd/color-el.git;a=summary Here's a snippet you can use to test it after loading color.el --8<---------------cut here---------------start------------->8--- (with-current-buffer (switch-to-buffer-other-window (get-buffer-create "*color test*")) (erase-buffer) (dotimes (i 100) (let* ((entry (cons (nth (random (length (x-defined-colors))) (x-defined-colors)) (nth (random (length (x-defined-colors))) (x-defined-colors)))) (color1 (apply 'rgb->lab (mapcar (lambda (x) (/ x 65535.0)) (x-color-values (car entry))))) (color2 (apply 'rgb->lab (mapcar (lambda (x) (/ x 65535.0)) (x-color-values (cdr entry))))) (luminance-ratio (/ (abs (- (car color1) (car color2))) (+ (car color1) (car color2)))) (distance (ciede2000 color1 color2))) (insert (propertize (format "%s distance %f luminance-ratio %f: %s and %s\n" (if (and (> distance 6) (> luminance-ratio 0.09)) "GOOD! :-)" "BAD") distance luminance-ratio (car entry) (cdr entry)) 'face `(:background ,(car entry) :foreground ,(cdr entry)))))))) --8<---------------cut here---------------end--------------->8--- `ciede2000' returns the distance between 2 colors. I don't know what the JND[1] threshold value for this algorithm, but 6 does not seems too bad. For the luminance of a color, the value is stored in the L component of the Lab format, so it's the car of what 'rgb->lab returned. I compute a ratio, but feel free to invent something better! I think both color distance and luminance have to be checked. I tried several check threshold, with special case if the background is darker than the text, but did not found anything very effective. Feel free to try to find something and to ask me question if you need. :) [1] Just Noticeable Difference -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Colour manipulation (was: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.) 2010-11-21 13:55 ` Julien Danjou @ 2010-11-21 18:38 ` Lars Magne Ingebrigtsen 2010-11-21 18:55 ` Colour manipulation Julien Danjou 0 siblings, 1 reply; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-21 18:38 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > I've published things here: > http://git.naquadah.org/?p=~jd/color-el.git;a=summary Wow. That's very mathy! :-) To bikeshed a bit, color.el is kinda very general name. Perhaps color-calc.el or something would be better... and the Greek characters in the source code is probably not very distribution-friendly. Could you fix those things, and then check it into the Gnus repository? > Here's a snippet you can use to test it after loading color.el My use case would be that I have a set background colour (eg., "black"), and then the CSS says "text-color: blue". I then want to modify the latter to be a colour that is visible enough to read. How would I do that? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-21 18:38 ` Colour manipulation (was: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.) Lars Magne Ingebrigtsen @ 2010-11-21 18:55 ` Julien Danjou 2010-11-21 19:02 ` Lars Magne Ingebrigtsen ` (2 more replies) 0 siblings, 3 replies; 67+ messages in thread From: Julien Danjou @ 2010-11-21 18:55 UTC (permalink / raw) To: ding On Sun, Nov 21 2010, Lars Magne Ingebrigtsen wrote: > To bikeshed a bit, color.el is kinda very general name. Perhaps > color-calc.el or something would be better... and the Greek characters > in the source code is probably not very distribution-friendly. > > Could you fix those things, and then check it into the Gnus repository? Sure I can. It's not meant to be distributed as it is anyway. I suggest you try to use it before I spend some time making it Gnus-distributable. :) >> Here's a snippet you can use to test it after loading color.el > > My use case would be that I have a set background colour (eg., "black"), > and then the CSS says "text-color: blue". I then want to modify the > latter to be a colour that is visible enough to read. How would I do > that? Hum the easiest way would be to convert RGB to Lab and then change L, a or b. To have a good understanding of how colors are represented in Lab, just take a look at the Wikipedia[1] page, the image are pretty explicit. There's no easy way to know by how much you should increase L, a or b, or what would be the best choice. FWIW L is always between 0 and 100, and there's a good chance that just changing it to 0 or 100 (depending on the other color L value) would give for sure a good result. One has to try. I did not write any lab->rgb function, but that's totally doable if needed. :) [1] http://en.wikipedia.org/wiki/Lab_color_space -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-21 18:55 ` Colour manipulation Julien Danjou @ 2010-11-21 19:02 ` Lars Magne Ingebrigtsen 2010-11-21 19:26 ` Julien Danjou 2010-11-21 19:57 ` Frank Schmitt 2010-11-22 19:47 ` Ted Zlatanov 2 siblings, 1 reply; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-21 19:02 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: >> To bikeshed a bit, color.el is kinda very general name. Perhaps >> color-calc.el or something would be better... color-lab.el would be punnier. >> My use case would be that I have a set background colour (eg., "black"), >> and then the CSS says "text-color: blue". I then want to modify the >> latter to be a colour that is visible enough to read. How would I do >> that? > > Hum the easiest way would be to convert RGB to Lab and then change L, a > or b. > > To have a good understanding of how colors are represented in Lab, just > take a look at the Wikipedia[1] page, the image are pretty explicit. I'm always interested in avoiding learning new things. :-) > There's no easy way to know by how much you should increase L, a or b, > or what would be the best choice. > > FWIW L is always between 0 and 100, and there's a good chance that just > changing it to 0 or 100 (depending on the other color L value) would > give for sure a good result. One has to try. It's all Greek to me... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-21 19:02 ` Lars Magne Ingebrigtsen @ 2010-11-21 19:26 ` Julien Danjou 2010-11-21 19:42 ` Lars Magne Ingebrigtsen ` (2 more replies) 0 siblings, 3 replies; 67+ messages in thread From: Julien Danjou @ 2010-11-21 19:26 UTC (permalink / raw) To: ding On Sun, Nov 21 2010, Lars Magne Ingebrigtsen wrote: > It's all Greek to me... Okay, I'll try to write you something this week. :-) -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-21 19:26 ` Julien Danjou @ 2010-11-21 19:42 ` Lars Magne Ingebrigtsen 2010-11-22 14:49 ` Julien Danjou 2010-11-22 15:37 ` Julien Danjou 2 siblings, 0 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-21 19:42 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > Okay, I'll try to write you something this week. :-) Great. :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-21 19:26 ` Julien Danjou 2010-11-21 19:42 ` Lars Magne Ingebrigtsen @ 2010-11-22 14:49 ` Julien Danjou 2010-11-24 2:27 ` Katsumi Yamaoka 2010-11-22 15:37 ` Julien Danjou 2 siblings, 1 reply; 67+ messages in thread From: Julien Danjou @ 2010-11-22 14:49 UTC (permalink / raw) To: ding On Sun, Nov 21 2010, Julien Danjou wrote: > On Sun, Nov 21 2010, Lars Magne Ingebrigtsen wrote: > >> It's all Greek to me... > > Okay, I'll try to write you something this week. :-) I did not finished yet, but here's an example of what I am able to do with my code: http://naquadah.org/~jd/color-corrector.html The 2 colors on the left are randomly chosen. The 2 colors on the right are either the same if the the color couple is considered visible, or 2 new adjusted colors if the function thinks they are not visible. (The code also has an option to adjust only the foreground color, in case the background color tested would be the frame background color. We would not want to change it I think. This is obviously not shown on that HTML test page.) -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-22 14:49 ` Julien Danjou @ 2010-11-24 2:27 ` Katsumi Yamaoka 2010-11-24 5:45 ` Katsumi Yamaoka ` (2 more replies) 0 siblings, 3 replies; 67+ messages in thread From: Katsumi Yamaoka @ 2010-11-24 2:27 UTC (permalink / raw) To: ding I got the following error when rendering html articles by shr: Debugger entered--Lisp error: (domain-error "sqrt" -0.5714420332765948) sqrt(-0.5714420332765948) color-lab-ciede2000((99.65739623101277 0.0035381660032918205...)) shr-color-visible("NavajoWhite" "#ffffff" t) This is because `(expt 25 7)' returns a minus value in my system[1], (expt 25 7) => -338935319 and changing those two in `color-lab-ciede2000' into `(expt 25 7.0)' does the trick. (expt 25 7.0) => 6103515625.0 Maybe all the arguments passed to math calculations, that may return a large value, should be floating point numbers. [1] most-positive-fixnum => 536870911 ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-24 2:27 ` Katsumi Yamaoka @ 2010-11-24 5:45 ` Katsumi Yamaoka 2010-11-24 6:39 ` Lars Magne Ingebrigtsen 2010-11-24 8:52 ` Julien Danjou 2010-11-24 6:39 ` Lars Magne Ingebrigtsen 2010-11-24 8:37 ` Julien Danjou 2 siblings, 2 replies; 67+ messages in thread From: Katsumi Yamaoka @ 2010-11-24 5:45 UTC (permalink / raw) To: ding Katsumi Yamaoka wrote: > I got the following error when rendering html articles by shr: Another error I got is: Debugger entered--Lisp error: (wrong-type-argument stringp nil) xw-color-values(nil nil) x-color-values(nil) rgb->normalize(nil) shr-color-visible("NavajoWhite" nil t) shr-color-check("rgb(19,") shr-insert-color-overlay("rgb(19, 19, 20)" 259 271) An html body that reproduces this is: --8<---------------cut here---------------start------------->8--- <#part type="text/html" disposition=inline> <html> <span style="color: rgb(19, 19, 20);"> foo bar baz </span> </html> --8<---------------cut here---------------end--------------->8--- The causes are SPCs in rgb numbers. So, a workaround is: --8<---------------cut here---------------start------------->8--- --- shr.el~ 2010-11-24 00:31:48 +0000 +++ shr.el 2010-11-24 05:43:38 +0000 @@ -502,7 +502,8 @@ (defun shr-insert-color-overlay (color start end) (when color - (when (string-match " " color) + (when (and (not (string-match "\\`rgb([^\)]+)\\'" color)) + (string-match " " color)) (setq color (car (split-string color)))) (let ((overlay (make-overlay start end))) (overlay-put overlay 'face (cons 'foreground-color --8<---------------cut here---------------end--------------->8--- ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-24 5:45 ` Katsumi Yamaoka @ 2010-11-24 6:39 ` Lars Magne Ingebrigtsen 2010-11-24 8:43 ` Julien Danjou 2010-11-24 8:52 ` Julien Danjou 1 sibling, 1 reply; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-24 6:39 UTC (permalink / raw) To: ding Katsumi Yamaoka <yamaoka@jpl.org> writes: > <span style="color: rgb(19, 19, 20);"> [...] > The causes are SPCs in rgb numbers. So, a workaround is: Please apply. But a more long-term fix to this would be to write an actual CSS parser. It shouldn't be particularly difficult, I hope. Does anybody have a description of the syntax? I mean color: white; color: white !important; color: rgb(19, 19, 20); are all valid, but how should this really be tokenized? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-24 6:39 ` Lars Magne Ingebrigtsen @ 2010-11-24 8:43 ` Julien Danjou 2010-11-24 20:37 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 67+ messages in thread From: Julien Danjou @ 2010-11-24 8:43 UTC (permalink / raw) To: ding On Wed, Nov 24 2010, Lars Magne Ingebrigtsen wrote: > I mean > > color: white; > color: white !important; > color: rgb(19, 19, 20); > > are all valid, but how should this really be tokenized? The color format is described here: http://www.w3.org/TR/2010/PR-css3-color-20101028/#colorunits That's CSS 3, but after a quick check it seems it's retro-compatible with older CSS. So we would be good with that. The !important flag is allowed on any line, see CSS 1 spec[1]. It's not color related at all. [1] http://www.w3.org/TR/REC-CSS1/ -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-24 8:43 ` Julien Danjou @ 2010-11-24 20:37 ` Lars Magne Ingebrigtsen 2010-11-24 20:48 ` Lars Magne Ingebrigtsen 2010-11-24 21:18 ` Julien Danjou 0 siblings, 2 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-24 20:37 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > [1] http://www.w3.org/TR/REC-CSS1/ http://www.w3.org/TR/REC-CSS1/#appendix-b I think this is the relevant bits: declaration : property ':' expr prio? | /* empty */ /* Prevents syntax errors... */ ; prio : IMPORTANT_SYM /* !important */ ; expr : term [ operator term ]* ; term : unary_operator? [ NUMBER | STRING | PERCENTAGE | LENGTH | EMS | EXS | IDENT | hexcolor | URL | RGB ] ; /* There is a constraint on the color that it must ** have either 3 or 6 hex-digits (i.e., [0-9a-fA-F]) ** after the "#"; e.g., "#000" is OK, but "#abcd" is not. */ hexcolor : HASH | HASH_AFTER_IDENT ; Urr. How does that make color: rgb(0, 1, 2); valid? Anyway, it looks like a pretty easy syntax to parse. I'll change `shr-parse-style' to do it "properly". -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-24 20:37 ` Lars Magne Ingebrigtsen @ 2010-11-24 20:48 ` Lars Magne Ingebrigtsen 2010-11-24 21:18 ` Julien Danjou 1 sibling, 0 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-24 20:48 UTC (permalink / raw) To: ding Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Anyway, it looks like a pretty easy syntax to parse. I'll change > `shr-parse-style' to do it "properly". Actually, the only thing I had to do was drop "!important", really... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-24 20:37 ` Lars Magne Ingebrigtsen 2010-11-24 20:48 ` Lars Magne Ingebrigtsen @ 2010-11-24 21:18 ` Julien Danjou 2010-11-24 21:27 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 67+ messages in thread From: Julien Danjou @ 2010-11-24 21:18 UTC (permalink / raw) To: ding <#secure method=pgpmime mode=sign> On Wed, Nov 24 2010, Lars Magne Ingebrigtsen wrote: > Urr. How does that make > > color: rgb(0, 1, 2); > > valid? You're reading CSS 1, and we're at CSS 3 nowadays. :) -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-24 21:18 ` Julien Danjou @ 2010-11-24 21:27 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-24 21:27 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > You're reading CSS 1, and we're at CSS 3 nowadays. :) Oh, right. :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-24 5:45 ` Katsumi Yamaoka 2010-11-24 6:39 ` Lars Magne Ingebrigtsen @ 2010-11-24 8:52 ` Julien Danjou 1 sibling, 0 replies; 67+ messages in thread From: Julien Danjou @ 2010-11-24 8:52 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: ding On Wed, Nov 24 2010, Katsumi Yamaoka wrote: > The causes are SPCs in rgb numbers. So, a workaround is: > > --- shr.el~ 2010-11-24 00:31:48 +0000 > +++ shr.el 2010-11-24 05:43:38 +0000 > @@ -502,7 +502,8 @@ > > (defun shr-insert-color-overlay (color start end) > (when color > - (when (string-match " " color) > + (when (and (not (string-match "\\`rgb([^\)]+)\\'" color)) > + (string-match " " color)) > (setq color (car (split-string color)))) > (let ((overlay (make-overlay start end))) > (overlay-put overlay 'face (cons 'foreground-color I've change that, since it forgot to exclude hsl() colors too. Until we have a proper CSS parser, it just returns the hexadecimal part of a string like "#aabbcc !important". That should do the trick. :) -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-24 2:27 ` Katsumi Yamaoka 2010-11-24 5:45 ` Katsumi Yamaoka @ 2010-11-24 6:39 ` Lars Magne Ingebrigtsen 2010-11-24 8:37 ` Julien Danjou 2 siblings, 0 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-24 6:39 UTC (permalink / raw) To: ding Katsumi Yamaoka <yamaoka@jpl.org> writes: > Maybe all the arguments passed to math calculations, that may return > a large value, should be floating point numbers. Yes, that sounds like a good idea. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-24 2:27 ` Katsumi Yamaoka 2010-11-24 5:45 ` Katsumi Yamaoka 2010-11-24 6:39 ` Lars Magne Ingebrigtsen @ 2010-11-24 8:37 ` Julien Danjou 2 siblings, 0 replies; 67+ messages in thread From: Julien Danjou @ 2010-11-24 8:37 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: ding On Wed, Nov 24 2010, Katsumi Yamaoka wrote: > This is because `(expt 25 7)' returns a minus value in my system[1], > > (expt 25 7) => -338935319 > > and changing those two in `color-lab-ciede2000' into `(expt 25 7.0)' > does the trick. > > (expt 25 7.0) => 6103515625.0 > > Maybe all the arguments passed to math calculations, that may return > a large value, should be floating point numbers. Good catch indeed. I'm on 64 bits system so I missed that. I've changed all expt calls to use floating point numbers, like you said. -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-21 19:26 ` Julien Danjou 2010-11-21 19:42 ` Lars Magne Ingebrigtsen 2010-11-22 14:49 ` Julien Danjou @ 2010-11-22 15:37 ` Julien Danjou 2010-11-22 15:59 ` Lars Magne Ingebrigtsen 2 siblings, 1 reply; 67+ messages in thread From: Julien Danjou @ 2010-11-22 15:37 UTC (permalink / raw) To: ding On Sun, Nov 21 2010, Julien Danjou wrote: > Okay, I'll try to write you something this week. :-) Lars, I've pushed code and (re)added support for <font> and <span>. Now you can start insulting me, but not too loudly. I'm so tired I'd re-configure my X server in 1 bit color right now. :) Cheers, -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-22 15:37 ` Julien Danjou @ 2010-11-22 15:59 ` Lars Magne Ingebrigtsen 2010-11-23 1:38 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-22 15:59 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > Lars, I've pushed code and (re)added support for <font> and <span>. > > Now you can start insulting me, but not too loudly. > I'm so tired I'd re-configure my X server in 1 bit color right now. :) I had a peek at <x1-dePP7+rLi58o6VUTNI5Z3FQTtOI@gwene.org> which uses a #000080; colour, and I use a black background, so it used to be totally unreadable to me. With your work here, it's perfectly legible. That's wonderful, and means that I should probably get started with doing CSS parsing for real in shr.el. Great work! -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-22 15:59 ` Lars Magne Ingebrigtsen @ 2010-11-23 1:38 ` Lars Magne Ingebrigtsen 2010-11-23 9:15 ` Julien Danjou 2010-11-23 9:48 ` Julien Danjou 0 siblings, 2 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-23 1:38 UTC (permalink / raw) To: ding I've now made `shr-descend' do color CSS items instead of special-casing the <span> and <font> tags. I think that's the right place to do CSS stuff -- it should be expanded to do background-color and the other (few) CSS things we were interested in. A cascading inheritance thing should be added, since it only does inline CSS at the present. By the way, compiling gives me this warning: shr-color.el:180:1:Warning: the following functions are not known to be defined: rainbow-hue-to-rgb, rainbow-hsl-to-rgb-fractions Those functions from rainbow should probably just be copied over to color-lab, I guess. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-23 1:38 ` Lars Magne Ingebrigtsen @ 2010-11-23 9:15 ` Julien Danjou 2010-11-23 23:50 ` Lars Magne Ingebrigtsen 2010-11-23 9:48 ` Julien Danjou 1 sibling, 1 reply; 67+ messages in thread From: Julien Danjou @ 2010-11-23 9:15 UTC (permalink / raw) To: ding On Tue, Nov 23 2010, Lars Magne Ingebrigtsen wrote: > shr-color.el:180:1:Warning: the following functions are not known to be > defined: rainbow-hue-to-rgb, rainbow-hsl-to-rgb-fractions > > Those functions from rainbow should probably just be copied over to > color-lab, I guess. Sorry, I wanted to make this work yesterday and was a bit in a hurry, so I did not had time to test compiling. I've just fixed all that warning. (PS: I almost copied half the code of rainbow-mode in shr-color. At least that's a first step, rainbow-mode (for Emacs 24) would just be 10 lines long. ;)) -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-23 9:15 ` Julien Danjou @ 2010-11-23 23:50 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-23 23:50 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > (PS: I almost copied half the code of rainbow-mode in shr-color. At > least that's a first step, rainbow-mode (for Emacs 24) would just be 10 > lines long. ;)) :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-23 1:38 ` Lars Magne Ingebrigtsen 2010-11-23 9:15 ` Julien Danjou @ 2010-11-23 9:48 ` Julien Danjou 2010-11-23 23:52 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 67+ messages in thread From: Julien Danjou @ 2010-11-23 9:48 UTC (permalink / raw) To: ding On Tue, Nov 23 2010, Lars Magne Ingebrigtsen wrote: > I've now made `shr-descend' do color CSS items instead of special-casing > the <span> and <font> tags. I think that's the right place to do CSS > stuff -- it should be expanded to do background-color and the other > (few) CSS things we were interested in. But now it misses the <font color="red"> handling. Can I re-add it, or did you removed it on purpose? -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-23 9:48 ` Julien Danjou @ 2010-11-23 23:52 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-23 23:52 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > But now it misses the <font color="red"> handling. Can I re-add it, or > did you removed it on purpose? Oh, right. No, I didn't think -- I just imagined that that tag used styles as normal with <font style="color: red;"> so it would just work automatically, but that would be too easy. :-) I'll resurrect shr-tag-img again. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-21 18:55 ` Colour manipulation Julien Danjou 2010-11-21 19:02 ` Lars Magne Ingebrigtsen @ 2010-11-21 19:57 ` Frank Schmitt 2010-11-22 19:47 ` Ted Zlatanov 2 siblings, 0 replies; 67+ messages in thread From: Frank Schmitt @ 2010-11-21 19:57 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > I did not write any lab->rgb function, but that's totally doable if > needed. :) But it is a bit of a mess, as you have to go via CIE-XYZ first. I did this in C++ some time ago. lab->rgb: double var_Y = (lab.l + 16.0) / 116.0; double var_X = lab.a / 500.0 + var_Y; double var_Z = var_Y - lab.b / 200.0; if ( pow(var_Y,3) > 0.008856 ) var_Y = pow(var_Y,3); else var_Y = (var_Y - 0.137931034482758620689655172413793103448275862068965517241379) / 7.787; if ( pow(var_X,3) > 0.008856 ) var_X = pow(var_X,3); else var_X = (var_X - 0.137931034482758620689655172413793103448275862068965517241379) / 7.787; if ( pow(var_Z,3) > 0.008856 ) var_Z = pow(var_Z,3); else var_Z = (var_Z - 0.137931034482758620689655172413793103448275862068965517241379) / 7.787; double var_R = var_X * 3.0800930820000003 + var_Y * -1.5372 + var_Z * -0.54289063799999993; double var_G = var_X * -0.92091038300000005 + var_Y * 1.8758 + var_Z * 0.045186444999999999; double var_B = var_X * 0.052941179000000005 + var_Y * -0.2040 + var_Z * 1.1508933099999998; double r = pow(var_R, 0.45454545454545453) * 255; if (r<0) rgb.red = 0; else if (r>255) rgb.red = 255; else rgb.red = (UINT8)r; double g = pow(var_G, 0.45454545454545453) * 255; if (g<0) rgb.green = 0; else if (g>255) rgb.green = 255; else rgb.green = (UINT8)g; double b = pow(var_B, 0.45454545454545453) * 255; if (b<0) rgb.blue = 0; else if (b>255) rgb.blue = 255; else rgb.blue = (UINT8)b; rgb->lab double var_R = rgb.red / 255.0; double var_G = rgb.green / 255.0; double var_B = rgb.blue / 255.0; if (var_R > 0.04045) var_R = pow(((var_R + 0.055) / 1.055), 2.4); else var_R = var_R / 12.92; if (var_G > 0.04045) var_G = pow(((var_G + 0.055) / 1.055), 2.4); else var_G = var_G / 12.92; if (var_B > 0.04045) var_B = pow(((var_B + 0.055) / 1.055), 2.4); else var_B = var_B / 12.92; //Includes division by reference white //Observer. = 2°, Illuminant = D65 double var_X = var_R * 0.43389060149189346 + var_G * 0.37623491535766512 + var_B * 0.18990604648226667; double var_Y = var_R * 0.2126 + var_G * 0.7152 + var_B * 0.0722; double var_Z = var_R * 0.017725448417108273 + var_G * 0.10947530835851327 + var_B * 0.87295537411717172; if (var_X > 0.008856) var_X = pow(var_X, 0.333333333333333333333333333333333333333333333333333333333333); else var_X = (7.787 * var_X) + (0.137931034482758620689655172413793103448275862068965517241379); if (var_Y > 0.008856 ) var_Y = pow(var_Y, 0.333333333333333333333333333333333333333333333333333333333333); else var_Y = (7.787 * var_Y) + (0.137931034482758620689655172413793103448275862068965517241379); // 16.0/116 if (var_Z > 0.008856) var_Z = pow(var_Z, 0.333333333333333333333333333333333333333333333333333333333333); else var_Z = (7.787 * var_Z) + (0.137931034482758620689655172413793103448275862068965517241379); lab.l = (float)((116 * var_Y) - 16); lab.a = (float)(500 * (var_X - var_Y)); lab.b = (float)(200 * (var_Y - var_Z)); -- Have you ever considered how much text can fit in eighty columns? Given that a signature typically contains up to four lines of text, this space allows you to attach a tremendous amount of valuable information to your messages. Seize the opportunity and don't waste your signature on bullshit that nobody cares about. ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-21 18:55 ` Colour manipulation Julien Danjou 2010-11-21 19:02 ` Lars Magne Ingebrigtsen 2010-11-21 19:57 ` Frank Schmitt @ 2010-11-22 19:47 ` Ted Zlatanov 2010-11-23 9:10 ` Julien Danjou 2 siblings, 1 reply; 67+ messages in thread From: Ted Zlatanov @ 2010-11-22 19:47 UTC (permalink / raw) To: ding On Sun, 21 Nov 2010 19:55:23 +0100 Julien Danjou <julien@danjou.info> wrote: JD> There's no easy way to know by how much you should increase L, a or b, JD> or what would be the best choice. ...so maybe it should be adjustable by the user? JD> FWIW L is always between 0 and 100, and there's a good chance that just JD> changing it to 0 or 100 (depending on the other color L value) would JD> give for sure a good result. One has to try. JD> I did not write any lab->rgb function, but that's totally doable if JD> needed. :) JD> [1] http://en.wikipedia.org/wiki/Lab_color_space Have you provided anything for colorblind people? Or is that not a priority? (if the latter, I'll give it a try) Ted ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-22 19:47 ` Ted Zlatanov @ 2010-11-23 9:10 ` Julien Danjou 2010-11-23 14:52 ` Ted Zlatanov 2010-11-24 1:09 ` Greg Troxel 0 siblings, 2 replies; 67+ messages in thread From: Julien Danjou @ 2010-11-23 9:10 UTC (permalink / raw) To: Ted Zlatanov; +Cc: ding On Mon, Nov 22 2010, Ted Zlatanov wrote: > Have you provided anything for colorblind people? Or is that not a > priority? (if the latter, I'll give it a try) Not at all. But I can give it a try, I just know nothing about colour blindness, what issue I should try to fix, and how. :) Any hint appreciated, while I read the Wikipedia page. -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-23 9:10 ` Julien Danjou @ 2010-11-23 14:52 ` Ted Zlatanov 2010-11-23 15:54 ` Julien Danjou 2010-11-24 1:09 ` Greg Troxel 1 sibling, 1 reply; 67+ messages in thread From: Ted Zlatanov @ 2010-11-23 14:52 UTC (permalink / raw) To: ding On Tue, 23 Nov 2010 10:10:51 +0100 Julien Danjou <julien@danjou.info> wrote: JD> On Mon, Nov 22 2010, Ted Zlatanov wrote: >> Have you provided anything for colorblind people? Or is that not a >> priority? (if the latter, I'll give it a try) JD> Not at all. But I can give it a try, I just know nothing about colour JD> blindness, what issue I should try to fix, and how. :) JD> Any hint appreciated, while I read the Wikipedia page. BTW, the source code for color-lab.el is beautiful. I like to see Unicode used properly like this, in code and identifiers. I am surprised and glad that Emacs is happy with it all. I'm not personally colorblind, just interested in helping people with that disability. So I can't test things too much without a conversion tool. Still, it seems that color-lab.el will quickly become the standard place for color formulas in Emacs so I think we should anticipate this common need instead of fixing it later. I posted a link to the color designer page at http://colorschemedesigner.com that lets you see any colors as a colorblind person would. The source code is JavaScript and probably easy to obtain. That kind of conversion tool is valuable. Here are some more links: http://jfly.iam.u-tokyo.ac.jp/color/ http://www.vischeck.com/info/ (LOTS of good links, check out Daltonize too) Vischeck came from open-source software and they may be willing to license their algorithm to the FSF. I would recommend to let users customize a color vision profile as part of color-lab (see my original long explanation of my work with colors in GUI design). Maybe just a list of colors and their contrasting pairs (with a reasonable set of defaults for each of the various kinds of colorblindness), from which we can approximate what will look good anywhere in the colorspace, will be sufficient. The algorithms are nice to have but not essential to the original requirement. Let me know if you need help or ideas going forward. Ted ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-23 14:52 ` Ted Zlatanov @ 2010-11-23 15:54 ` Julien Danjou 2010-11-23 16:15 ` Ted Zlatanov ` (2 more replies) 0 siblings, 3 replies; 67+ messages in thread From: Julien Danjou @ 2010-11-23 15:54 UTC (permalink / raw) To: Ted Zlatanov; +Cc: ding On Tue, Nov 23 2010, Ted Zlatanov wrote: > BTW, the source code for color-lab.el is beautiful. I like to see > Unicode used properly like this, in code and identifiers. I am > surprised and glad that Emacs is happy with it all. It works perfectly, and I'm even happier than you can imagine, because using Unicode symbols is just easier when you re-read your work with some math paper on your side. Reading things like DeltaLPrime just makes things harder for your brain. :) > I'm not personally colorblind, just interested in helping people with > that disability. So I can't test things too much without a conversion > tool. Still, it seems that color-lab.el will quickly become the > standard place for color formulas in Emacs so I think we should > anticipate this common need instead of fixing it later. I agree. :) > I posted a link to the color designer page at > http://colorschemedesigner.com that lets you see any colors as a > colorblind person would. The source code is JavaScript and probably > easy to obtain. That kind of conversion tool is valuable. Here are > some more links: > > http://jfly.iam.u-tokyo.ac.jp/color/ > http://www.vischeck.com/info/ (LOTS of good links, check out Daltonize too) > > Vischeck came from open-source software and they may be willing to > license their algorithm to the FSF. That would be great. I don't think we even need the whole algorithm because they are using S-CIELAB on images, something we can't do (but we should to do better processing!). So even without the S-CIELAB part, but with some color substitution algorithm we could do some good job. > I would recommend to let users customize a color vision profile as part > of color-lab (see my original long explanation of my work with colors in > GUI design). Maybe just a list of colors and their contrasting pairs > (with a reasonable set of defaults for each of the various kinds of > colorblindness), from which we can approximate what will look good > anywhere in the colorspace, will be sufficient. The algorithms are nice > to have but not essential to the original requirement. That sounds like an option indeed. I'll probably use that if I can't do something better. Now, what I have in mind… I think the only colour blindness types we should consider are all forms of dichromacy. In that case, since we use RGB (hehe), dropping one of the 3 components (depending of the dichromacy type) and using the same computing could work. If I simulate protanopia with the following code and then correct it, this is what I got: --8<---------------cut here---------------start------------->8--- (let* ((fg "#ffaabb") (bg "#aaffbb") (fg-cb (mapcar (lambda (x) (/ x 256)) (x-color-values fg))) (bg-cb (mapcar (lambda (x) (/ x 256)) (x-color-values bg)))) (shr-color-check ;; No red color blindness (apply 'format "#00%02X%02X" (cdr fg-cb)) (apply 'format "#00%02X%02X" (cdr bg-cb)))) ==> ("#3effce" "#0096a6") --8<---------------cut here---------------end--------------->8--- I simulate it by setting red to 0, and let the code correct the color. It generates 2 new colors: #3effce #0096a6, which are 2 different blues. Even #3effce without the red component (#00ffce) seems visible. If I use 2 different reds like #ff0000 and #bb0000 it generates black and grey: #000000 and #5e5e5e. The grey is probably viewed as #005e5e which is some green-blue, and should be visible. This is probably not perfect, but is this good enough? Any color blind people in there? :) -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-23 15:54 ` Julien Danjou @ 2010-11-23 16:15 ` Ted Zlatanov 2010-11-23 18:32 ` Colour blindness correction (was: Colour manipulation) Julien Danjou 2010-11-23 23:50 ` Colour manipulation Lars Magne Ingebrigtsen 2010-11-26 20:17 ` Adam Sjøgren 2 siblings, 1 reply; 67+ messages in thread From: Ted Zlatanov @ 2010-11-23 16:15 UTC (permalink / raw) To: ding On Tue, 23 Nov 2010 16:54:34 +0100 Julien Danjou <julien@danjou.info> wrote: JD> On Tue, Nov 23 2010, Ted Zlatanov wrote: >> I would recommend to let users customize a color vision profile as part >> of color-lab (see my original long explanation of my work with colors in >> GUI design). Maybe just a list of colors and their contrasting pairs >> (with a reasonable set of defaults for each of the various kinds of >> colorblindness), from which we can approximate what will look good >> anywhere in the colorspace, will be sufficient. The algorithms are nice >> to have but not essential to the original requirement. JD> That sounds like an option indeed. I'll probably use that if I can't do JD> something better. JD> Now, what I have in mind… JD> I think the only colour blindness types we should consider are all forms JD> of dichromacy. In that case, since we use RGB (hehe), dropping one of JD> the 3 components (depending of the dichromacy type) and using the same JD> computing could work. JD> If I simulate protanopia with the following code and then correct it, JD> this is what I got: JD> (let* ((fg "#ffaabb") JD> (bg "#aaffbb") JD> (fg-cb (mapcar (lambda (x) (/ x 256)) (x-color-values fg))) JD> (bg-cb (mapcar (lambda (x) (/ x 256)) (x-color-values bg)))) JD> (shr-color-check JD> ;; No red color blindness JD> (apply 'format "#00%02X%02X" (cdr fg-cb)) JD> (apply 'format "#00%02X%02X" (cdr bg-cb)))) JD> ==> ("#3effce" "#0096a6") JD> I simulate it by setting red to 0, and let the code correct the color. JD> It generates 2 new colors: #3effce #0096a6, which are 2 different blues. JD> Even #3effce without the red component (#00ffce) seems visible. JD> If I use 2 different reds like #ff0000 and #bb0000 it generates black JD> and grey: #000000 and #5e5e5e. The grey is probably viewed as #005e5e JD> which is some green-blue, and should be visible. JD> This is probably not perfect, but is this good enough? Any color blind JD> people in there? :) You can test at http://colorschemedesigner.com/ The colors you mentioned looked OK to me and yes, killing the red is probably a good way to fix it for most people (maybe it's as simple as a custom set of RGB adjustment constants for general use?). You may want to take the discussion to emacs-devel to find both more opinions and more testers. There may be someone that knows about existing similar work for Emacs Lisp; I already searched but didn't find any. Ted ^ permalink raw reply [flat|nested] 67+ messages in thread
* Colour blindness correction (was: Colour manipulation) 2010-11-23 16:15 ` Ted Zlatanov @ 2010-11-23 18:32 ` Julien Danjou 0 siblings, 0 replies; 67+ messages in thread From: Julien Danjou @ 2010-11-23 18:32 UTC (permalink / raw) To: Ted Zlatanov; +Cc: ding, emacs-devel On Tue, Nov 23 2010, Ted Zlatanov wrote: > On Tue, 23 Nov 2010 16:54:34 +0100 Julien Danjou <julien@danjou.info> wrote: > > JD> On Tue, Nov 23 2010, Ted Zlatanov wrote: >>> I would recommend to let users customize a color vision profile as part >>> of color-lab (see my original long explanation of my work with colors in >>> GUI design). Maybe just a list of colors and their contrasting pairs >>> (with a reasonable set of defaults for each of the various kinds of >>> colorblindness), from which we can approximate what will look good >>> anywhere in the colorspace, will be sufficient. The algorithms are nice >>> to have but not essential to the original requirement. > > JD> That sounds like an option indeed. I'll probably use that if I can't do > JD> something better. > > JD> Now, what I have in mind… > > JD> I think the only colour blindness types we should consider are all forms > JD> of dichromacy. In that case, since we use RGB (hehe), dropping one of > JD> the 3 components (depending of the dichromacy type) and using the same > JD> computing could work. > > JD> If I simulate protanopia with the following code and then correct it, > JD> this is what I got: > JD> (let* ((fg "#ffaabb") > JD> (bg "#aaffbb") > JD> (fg-cb (mapcar (lambda (x) (/ x 256)) (x-color-values fg))) > JD> (bg-cb (mapcar (lambda (x) (/ x 256)) (x-color-values bg)))) > JD> (shr-color-check > JD> ;; No red color blindness > JD> (apply 'format "#00%02X%02X" (cdr fg-cb)) > JD> (apply 'format "#00%02X%02X" (cdr bg-cb)))) > > JD> ==> ("#3effce" "#0096a6") > > JD> I simulate it by setting red to 0, and let the code correct the color. > JD> It generates 2 new colors: #3effce #0096a6, which are 2 different blues. > JD> Even #3effce without the red component (#00ffce) seems visible. > > JD> If I use 2 different reds like #ff0000 and #bb0000 it generates black > JD> and grey: #000000 and #5e5e5e. The grey is probably viewed as #005e5e > JD> which is some green-blue, and should be visible. > > JD> This is probably not perfect, but is this good enough? Any color blind > JD> people in there? :) > > You can test at http://colorschemedesigner.com/ > > The colors you mentioned looked OK to me and yes, killing the red is > probably a good way to fix it for most people (maybe it's as simple as a > custom set of RGB adjustment constants for general use?). You may want > to take the discussion to emacs-devel to find both more opinions and > more testers. There may be someone that knows about existing similar > work for Emacs Lisp; I already searched but didn't find any. Good idea. I'm following up to emacs-devel as well, so maybe there some people willing to help. Having at least a function to simulate blindness like on http://colorschemedesigner.com/ would be helpful to enhance shr-color-check. -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-23 15:54 ` Julien Danjou 2010-11-23 16:15 ` Ted Zlatanov @ 2010-11-23 23:50 ` Lars Magne Ingebrigtsen 2010-11-24 8:32 ` Julien Danjou 2010-11-26 20:17 ` Adam Sjøgren 2 siblings, 1 reply; 67+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-23 23:50 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > I simulate it by setting red to 0, and let the code correct the color. > It generates 2 new colors: #3effce #0096a6, which are 2 different blues. > Even #3effce without the red component (#00ffce) seems visible. Hm... interesting. So if we have <p style="background: red; color: green;"> then this could auto-correct this to make it readable? Sounds wonderful. Unfortunately, I'm not colour-blind, so I can't really test... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-23 23:50 ` Colour manipulation Lars Magne Ingebrigtsen @ 2010-11-24 8:32 ` Julien Danjou 0 siblings, 0 replies; 67+ messages in thread From: Julien Danjou @ 2010-11-24 8:32 UTC (permalink / raw) To: ding On Wed, Nov 24 2010, Lars Magne Ingebrigtsen wrote: > Hm... interesting. So if we have > > <p style="background: red; color: green;"> > > then this could auto-correct this to make it readable? Sounds > wonderful. Yes, it would. I just need to check that it works with either someone colour blind or with some function transforming colors to color blind equivalent. :) -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-23 15:54 ` Julien Danjou 2010-11-23 16:15 ` Ted Zlatanov 2010-11-23 23:50 ` Colour manipulation Lars Magne Ingebrigtsen @ 2010-11-26 20:17 ` Adam Sjøgren 2 siblings, 0 replies; 67+ messages in thread From: Adam Sjøgren @ 2010-11-26 20:17 UTC (permalink / raw) To: ding On Tue, 23 Nov 2010 16:54:34 +0100, Julien wrote: > It works perfectly, and I'm even happier than you can imagine, because > using Unicode symbols is just easier when you re-read your work with > some math paper on your side. Reading things like DeltaLPrime just makes > things harder for your brain. :) Because programmer's penchant for incomprehensible variable naming is only surpassed by mathematician's knack for naming things so inexplicably opaquely that nobody can follow... :-), Adam -- "I'm always interested in avoiding learning new Adam Sjøgren things." asjo@koldfront.dk ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: Colour manipulation 2010-11-23 9:10 ` Julien Danjou 2010-11-23 14:52 ` Ted Zlatanov @ 2010-11-24 1:09 ` Greg Troxel 1 sibling, 0 replies; 67+ messages in thread From: Greg Troxel @ 2010-11-24 1:09 UTC (permalink / raw) To: Julien Danjou; +Cc: Ted Zlatanov, ding [-- Attachment #1: Type: text/plain, Size: 810 bytes --] Julien Danjou <julien@danjou.info> writes: > Any hint appreciated, while I read the Wikipedia page. IIRC there are multiple forms, some of which are defects in cone types and some in the later signal processing. The approach I'd try is to have a variable that can be set to various tokens to indicate them, and do some sort of folding of colors according to the particular problem before doing the distance-in-color-space calculations. I can no longer remember where I read this, but in some color theory reading there was a credible claim that there's a neural coding to luminance and red/green and yellow/blue and that some colorblindness is a neural problem in those pathways rather then a cone defect. See http://www.handprint.com/HP/WCL/color2.html and search for "In 1949 D.B. Judd specified". [-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --] ^ permalink raw reply [flat|nested] 67+ messages in thread
end of thread, other threads:[~2010-11-26 20:17 UTC | newest] Thread overview: 67+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <E1PArgx-0006dS-00@quimby.gnus.org> 2010-10-26 23:58 ` [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added Lars Magne Ingebrigtsen 2010-10-27 0:15 ` Katsumi Yamaoka 2010-10-27 0:22 ` Katsumi Yamaoka 2010-10-27 0:28 ` Lars Magne Ingebrigtsen 2010-10-27 0:43 ` Katsumi Yamaoka 2010-10-27 18:06 ` Ted Zlatanov 2010-10-29 23:18 ` Lars Magne Ingebrigtsen 2010-11-09 22:25 ` Ted Zlatanov 2010-11-09 22:47 ` Lars Magne Ingebrigtsen 2010-11-09 23:02 ` Steinar Bang 2010-11-10 9:54 ` Julien Danjou 2010-11-10 17:49 ` Colourspace (was: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.) Lars Magne Ingebrigtsen 2010-11-10 19:09 ` Colourspace Julien Danjou 2010-11-10 19:44 ` Colourspace Ted Zlatanov 2010-11-10 19:56 ` Colourspace Julien Danjou 2010-11-10 20:22 ` ELPA and Gnus (was: Colourspace) Ted Zlatanov 2010-11-10 20:48 ` ELPA and Gnus Lars Magne Ingebrigtsen 2010-11-10 21:23 ` Ted Zlatanov 2010-11-10 21:32 ` Lars Magne Ingebrigtsen 2010-11-11 13:19 ` Ted Zlatanov 2010-11-14 16:07 ` Lars Magne Ingebrigtsen 2010-11-15 15:43 ` Julien Danjou 2010-11-11 9:06 ` Julien Danjou 2010-11-14 16:07 ` Lars Magne Ingebrigtsen 2010-11-10 20:48 ` Colourspace Lars Magne Ingebrigtsen 2010-11-10 20:55 ` Colourspace Lars Magne Ingebrigtsen 2010-11-11 8:59 ` Colourspace Julien Danjou 2010-11-18 18:49 ` Colourspace Ted Zlatanov 2010-11-10 13:14 ` [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added Ted Zlatanov 2010-11-19 16:13 ` Julien Danjou 2010-11-21 4:40 ` Lars Magne Ingebrigtsen 2010-11-21 13:55 ` Julien Danjou 2010-11-21 18:38 ` Colour manipulation (was: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.) Lars Magne Ingebrigtsen 2010-11-21 18:55 ` Colour manipulation Julien Danjou 2010-11-21 19:02 ` Lars Magne Ingebrigtsen 2010-11-21 19:26 ` Julien Danjou 2010-11-21 19:42 ` Lars Magne Ingebrigtsen 2010-11-22 14:49 ` Julien Danjou 2010-11-24 2:27 ` Katsumi Yamaoka 2010-11-24 5:45 ` Katsumi Yamaoka 2010-11-24 6:39 ` Lars Magne Ingebrigtsen 2010-11-24 8:43 ` Julien Danjou 2010-11-24 20:37 ` Lars Magne Ingebrigtsen 2010-11-24 20:48 ` Lars Magne Ingebrigtsen 2010-11-24 21:18 ` Julien Danjou 2010-11-24 21:27 ` Lars Magne Ingebrigtsen 2010-11-24 8:52 ` Julien Danjou 2010-11-24 6:39 ` Lars Magne Ingebrigtsen 2010-11-24 8:37 ` Julien Danjou 2010-11-22 15:37 ` Julien Danjou 2010-11-22 15:59 ` Lars Magne Ingebrigtsen 2010-11-23 1:38 ` Lars Magne Ingebrigtsen 2010-11-23 9:15 ` Julien Danjou 2010-11-23 23:50 ` Lars Magne Ingebrigtsen 2010-11-23 9:48 ` Julien Danjou 2010-11-23 23:52 ` Lars Magne Ingebrigtsen 2010-11-21 19:57 ` Frank Schmitt 2010-11-22 19:47 ` Ted Zlatanov 2010-11-23 9:10 ` Julien Danjou 2010-11-23 14:52 ` Ted Zlatanov 2010-11-23 15:54 ` Julien Danjou 2010-11-23 16:15 ` Ted Zlatanov 2010-11-23 18:32 ` Colour blindness correction (was: Colour manipulation) Julien Danjou 2010-11-23 23:50 ` Colour manipulation Lars Magne Ingebrigtsen 2010-11-24 8:32 ` Julien Danjou 2010-11-26 20:17 ` Adam Sjøgren 2010-11-24 1:09 ` Greg Troxel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).