Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Lars Magne Ingebrigtsen]

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

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Katsumi Yamaoka]

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.

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Katsumi Yamaoka]

Katsumi Yamaoka wrote:
> If a mail contains text/plain and text/plain parts as
                          html ;-)
> multipart/alternative, now both are displayed similarly.

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Lars Magne Ingebrigtsen]

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

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Katsumi Yamaoka]

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".  :-)

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Ted Zlatanov]

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

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Lars Magne Ingebrigtsen]

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

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Ted Zlatanov]

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

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Lars Magne Ingebrigtsen]

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

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Steinar Bang]

>>>>> 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.

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Julien Danjou]

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

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Ted Zlatanov]

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

Colourspace (was: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.)

[Lars Magne Ingebrigtsen]

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

Re: Colourspace

[Julien Danjou]

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

Re: Colourspace

[Ted Zlatanov]

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

Re: Colourspace

[Julien Danjou]

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

ELPA and Gnus (was: Colourspace)

[Ted Zlatanov]

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

Re: ELPA and Gnus

[Lars Magne Ingebrigtsen]

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

Re: Colourspace

[Lars Magne Ingebrigtsen]

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

Re: Colourspace

[Lars Magne Ingebrigtsen]

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

Re: ELPA and Gnus

[Ted Zlatanov]

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

Re: ELPA and Gnus

[Lars Magne Ingebrigtsen]

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

Re: Colourspace

[Julien Danjou]

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

Re: ELPA and Gnus

[Julien Danjou]

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

Re: ELPA and Gnus

[Ted Zlatanov]

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

Re: ELPA and Gnus

[Lars Magne Ingebrigtsen]

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

Re: ELPA and Gnus

[Lars Magne Ingebrigtsen]

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

Re: ELPA and Gnus

[Julien Danjou]

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

Re: Colourspace

[Ted Zlatanov]

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

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Julien Danjou]

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

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Lars Magne Ingebrigtsen]

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

Re: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.

[Julien Danjou]

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

Colour manipulation (was: [gnus git] branch master updated: =1= shr.el (shr-tag-div): Added.)

[Lars Magne Ingebrigtsen]

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

Re: Colour manipulation

[Julien Danjou]

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

Re: Colour manipulation

[Lars Magne Ingebrigtsen]

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

Re: Colour manipulation

[Julien Danjou]

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

Re: Colour manipulation

[Lars Magne Ingebrigtsen]

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

Re: Colour manipulation

[Frank Schmitt]

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.

Re: Colour manipulation

[Julien Danjou]

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

Re: Colour manipulation

[Julien Danjou]

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

Re: Colour manipulation

[Lars Magne Ingebrigtsen]

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

Re: Colour manipulation

[Ted Zlatanov]

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

Re: Colour manipulation

[Lars Magne Ingebrigtsen]

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

Re: Colour manipulation

[Julien Danjou]

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

Re: Colour manipulation

[Julien Danjou]

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

Re: Colour manipulation

[Julien Danjou]

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

Re: Colour manipulation

[Ted Zlatanov]

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

Re: Colour manipulation

[Julien Danjou]

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

Re: Colour manipulation

[Ted Zlatanov]

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

Colour blindness correction (was: Colour manipulation)

[Julien Danjou]

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

Re: Colour manipulation

[Lars Magne Ingebrigtsen]

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

Re: Colour manipulation

[Lars Magne Ingebrigtsen]

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

Re: Colour manipulation

[Lars Magne Ingebrigtsen]

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

Re: Colour manipulation

[Greg Troxel]

[-- 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 --]

Re: Colour manipulation

[Katsumi Yamaoka]

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

Re: Colour manipulation

[Katsumi Yamaoka]

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---

Re: Colour manipulation

[Lars Magne Ingebrigtsen]

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

Re: Colour manipulation

[Lars Magne Ingebrigtsen]

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

Re: Colour manipulation

[Julien Danjou]

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

Re: Colour manipulation

[Julien Danjou]

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

Re: Colour manipulation

[Julien Danjou]

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

Re: Colour manipulation

[Julien Danjou]

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

Re: Colour manipulation

[Lars Magne Ingebrigtsen]

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

Re: Colour manipulation

[Lars Magne Ingebrigtsen]

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

Re: Colour manipulation

[Julien Danjou]

<#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

Re: Colour manipulation

[Lars Magne Ingebrigtsen]

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

Re: Colour manipulation

[Adam Sjøgren]

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