bodington-developers

[Bodington-developers] CSS Processing

[Jon M. <jo...@te...>]

Comments on this welcome....

O.K. I've now got straight in my mind how to do the CSS stuff that I'm 
planning (for my own web site initally). It depends on XSLT 2.0 because 
the transforms need to do some maths and 2.0 allows you to define 
functions in the stylesheet thus avoiding the need for call outs to a 
potentially less portable code library. (Most important if a binary, 
i.e. non-Java transformer is preferred.) I'm testing with Saxon.

The process involves three different roles; designer, author, viewer.

The designer is the person who designs the web site and is knowledgable 
about CSS. The designer creates the basic structure of documents and 
tools but doesn't deal with aesthetics such as specific colour schemes.

The author is the creator and owner of documents created with tools 
provided by the designer who is allowed to change the appearance of 
their own or their group's documents and tools as seen by others within 
parameters defined by the designer.

The viewer can navigate through the documents of various authors and has 
options to alter the appearance for the purposes of accessibility and 
preference. The alterations will always attempt to preserve the 
essential differences between one author's documents and another's.

The web server will map *.css onto a url to a CGI script or servlet 
passing in the original path to the referenced css file. The script will 
find the original css file and a number of other files in a special 
sub-directory. In the special sub directory there may be a processed css 
file which is up to date. If that file is up-to-date it will be sent in 
place of the original css file. If it isn't up to date processing may be 
required to recreate the processed css file.


Step 0)
The designer creates one or more files that resemble standard CSS files. 
(Called designer CSS files.)
This is an optional step for designers who can't cope with XML files and 
will require some non-standard extensions to the CSS format to implement 
extra functionality.  (explained in the next step.)

Step 1)
An XML style file will represent what is essentially the designer CSS 
file but in a format that can be processed by XSLT. In addition to the 
normal content there will be a section that declares variables and the 
value part of any CSS declaration may be either a constant or reference 
a variable.  (Variable declarations will have default values.) The 
decision about whether to put a constant or a variable depends on the 
designer's wish to give the document author parameters which they can 
use to change the appearance of their documents. It is likely that 
colours will be added as variables, some font properties will be added 
as variables but dimensions are more likely to be constants. (Ideally it 
will also be possible to put arithmetic expressions in but that will 
have to wait for version 2.) This file is called the designer xml style 
file and it will only be generated if it is older than the designer css 
file.

Step 2)
The author xml style file is generated by XSLT. (Only if it doesn't yet 
exist or is older than the designer xml style file.) The XSLT file that 
does the work is passed an author data file as a parameter. The author 
data file is a simple XML file that names variables and defines values. 
It may only contain a foreground and background color for example. The 
transform substitutes variable values into the style declarations of the 
author xml style file. If the author data file lacks a definition for a 
particular variable then the default value is used. Outside the scope of 
the servlet/cgi script is the creation and editing of the author data 
file - however the designer xml style file lists all the variables and 
will have descriptions of them (in multiple languages) so another 
application can present a form to users where they can choose colors 
etc.  The number of these files generated = (num.  css files) * (num. 
different authoring areas)

Step 3)
The user xml style file is genereated by XSLT. (Only if it doesn't yet 
exist or is older than the author xml style file.) The XSLT file that 
does the work is passed a user preference file as a parameter. The user 
preference file is XML that describes things like colour preferences, 
preferences for line spacing etc. etc.  The transform looks at whole 
blocks of style, picking out specific declarations of interest and uses 
appropriate maths to bring the style sheet within constraints defined by 
the user's preferences while attempting to retain whatever individuality 
of the design it can.  The number of these files potentially generated = 
(num.  css files) * (num. different authoring areas) * (num. users with 
preferences) Users with default preferences are treated as a single user.

Step 4)
The user css style file is generated by XSLT. (Only if it doesn't exist 
or is older than the user xml style file.) I

My estimate is that a native code XSLT processor invoked from CGI can do 
all of the above in less than 250ms. A Java XSLT processor invoked from 
a Servlet will probably be faster since it's permanently loaded in 
memory and ready to run.

RGB to CSV
=========

Nearly all user colour preference work will operate in 
Hue-Saturation-Value space, not Red-Green-Blue space. However, the 
standard Java HSV colour space (which Bodington currently uses) is not 
very good so I've devised a better method. (Probably reinvented but it 
only took a couple of days work.) The standard HSV space is cylindrical 
where H is the perpendicular distance from the axis to the colour point, 
H is the angle of that line from the red plane and V is the distance up 
the cylinder.  All of the bottom face is black. (which means that if V=0 
then the colour is black regardless of the values of H or S) However, 
the top face has white only at the center and has bright rainbow colours 
around the edge.  This means that if V is non-zero, V and H are kept 
constant and S is varied then not only does the perceived saturation 
change but the brightness does too. The method used to map the cube rgb 
space onto the cylinder is also dodgy since for certain values of H 
changing S distorts the perceived hue.

My method also maps to a cylinder but the top face of the cylinder is 
completely white.  This means that V==100% always produces white no 
matter what the value of H or S. It also means that if H and V are kept 
constant and S is varied, the perceived brightness and hue keep 
constant. This is acheived by two rotations of the rgb cube so that the 
white to black vector lines up with the z axis. Then the shape is 
distorted so that vectors which run from the z axis to the cube surface 
and which lie parallel to the x,y plane are stretched uniformly to unit 
length.  The resulting cylinder is squashed down the z axis to unit length.

Jon

Re: [Bodington-developers] CSS Processing

[Sean M. <se...@sm...>]

Yes, all fine Jon, BUT what about compliance with the critical and  
well known Hausdorff's Metric Top, you know:

Let (S,d) be a metric space, and let X be the collection of all  
nonempty bounded closed subsets of S. Let f:S * X -> R+ be defined by  
f(s,B) = inf _(b in B) d(s,b), and let g: X * X -> R+ be given by g 
(A,B) = sup_(a in A) f(a,B), and let delta(A,B) = max {g(A,B),g 
(B,A)}. You must concern yourself with (X, delta)! Your method  
clearly fails here! Pah!

And for anyone wanting to quibble with my counterexample, yes, I  
know, but I couldn't write the vector cross product adequately in  
this crap test format, so had to resort to *.

-s


On 6 Apr 2006, at 18:59, Jon Maber wrote:

> Nearly all user colour preference work will operate in Hue- 
> Saturation-Value space, not Red-Green-Blue space. However, the  
> standard Java HSV colour space (which Bodington currently uses) is  
> not very good so I've devised a better method. (Probably reinvented  
> but it only took a couple of days work.) The standard HSV space is  
> cylindrical where H is the perpendicular distance from the axis to  
> the colour point, H is the angle of that line from the red plane  
> and V is the distance up the cylinder.  All of the bottom face is  
> black. (which means that if V=0 then the colour is black regardless  
> of the values of H or S) However, the top face has white only at  
> the center and has bright rainbow colours around the edge.  This  
> means that if V is non-zero, V and H are kept constant and S is  
> varied then not only does the perceived saturation change but the  
> brightness does too. The method used to map the cube rgb space onto  
> the cylinder is also dodgy since for certain values of H changing S  
> distorts the perceived hue.
>
> My method also maps to a cylinder but the top face of the cylinder  
> is completely white.  This means that V==100% always produces white  
> no matter what the value of H or S. It also means that if H and V  
> are kept constant and S is varied, the perceived brightness and hue  
> keep constant. This is acheived by two rotations of the rgb cube so  
> that the white to black vector lines up with the z axis. Then the  
> shape is distorted so that vectors which run from the z axis to the  
> cube surface and which lie parallel to the x,y plane are stretched  
> uniformly to unit length.  The resulting cylinder is squashed down  
> the z axis to unit length.

Re: [Bodington-developers] CSS Processing

[Jon M. <jo...@te...>]

I must bow to your superior mathologicity.

Many thanks for taking on this work package, good luck.....

Jon

Sean Mehan wrote:

> Yes, all fine Jon, BUT what about compliance with the critical and  
> well known Hausdorff's Metric Top, you know:
>
> Let (S,d) be a metric space, and let X be the collection of all  
> nonempty bounded closed subsets of S. Let f:S * X -> R+ be defined by  
> f(s,B) = inf _(b in B) d(s,b), and let g: X * X -> R+ be given by g 
> (A,B) = sup_(a in A) f(a,B), and let delta(A,B) = max {g(A,B),g 
> (B,A)}. You must concern yourself with (X, delta)! Your method  
> clearly fails here! Pah!
>
> And for anyone wanting to quibble with my counterexample, yes, I  
> know, but I couldn't write the vector cross product adequately in  
> this crap test format, so had to resort to *.
>
> -s
>
>
> On 6 Apr 2006, at 18:59, Jon Maber wrote:
>
>> Nearly all user colour preference work will operate in Hue- 
>> Saturation-Value space, not Red-Green-Blue space. However, the  
>> standard Java HSV colour space (which Bodington currently uses) is  
>> not very good so I've devised a better method. (Probably reinvented  
>> but it only took a couple of days work.) The standard HSV space is  
>> cylindrical where H is the perpendicular distance from the axis to  
>> the colour point, H is the angle of that line from the red plane  and 
>> V is the distance up the cylinder.  All of the bottom face is  black. 
>> (which means that if V=0 then the colour is black regardless  of the 
>> values of H or S) However, the top face has white only at  the center 
>> and has bright rainbow colours around the edge.  This  means that if 
>> V is non-zero, V and H are kept constant and S is  varied then not 
>> only does the perceived saturation change but the  brightness does 
>> too. The method used to map the cube rgb space onto  the cylinder is 
>> also dodgy since for certain values of H changing S  distorts the 
>> perceived hue.
>>
>> My method also maps to a cylinder but the top face of the cylinder  
>> is completely white.  This means that V==100% always produces white  
>> no matter what the value of H or S. It also means that if H and V  
>> are kept constant and S is varied, the perceived brightness and hue  
>> keep constant. This is acheived by two rotations of the rgb cube so  
>> that the white to black vector lines up with the z axis. Then the  
>> shape is distorted so that vectors which run from the z axis to the  
>> cube surface and which lie parallel to the x,y plane are stretched  
>> uniformly to unit length.  The resulting cylinder is squashed down  
>> the z axis to unit length.
>
>
>

Re: [Bodington-developers] CSS Processing

[Antony C. <an...@sm...>]

We will be holding a 3 day seminar in HSV processing here in late June  
- to register, click on the link below:
http://www.whatthefeckishetalkingabout.com/

On 6 Apr 2006, at 19:37, Jon Maber wrote:

> I must bow to your superior mathologicity.
>
> Many thanks for taking on this work package, good luck.....
>
> Jon
>
> Sean Mehan wrote:
>
>> Yes, all fine Jon, BUT what about compliance with the critical and   
>> well known Hausdorff's Metric Top, you know:
>>
>> Let (S,d) be a metric space, and let X be the collection of all   
>> nonempty bounded closed subsets of S. Let f:S * X -> R+ be defined by  
>>  f(s,B) = inf _(b in B) d(s,b), and let g: X * X -> R+ be given by g  
>> (A,B) = sup_(a in A) f(a,B), and let delta(A,B) = max {g(A,B),g  
>> (B,A)}. You must concern yourself with (X, delta)! Your method   
>> clearly fails here! Pah!
>>
>> And for anyone wanting to quibble with my counterexample, yes, I   
>> know, but I couldn't write the vector cross product adequately in   
>> this crap test format, so had to resort to *.
>>
>> -s
>>
>>
>> On 6 Apr 2006, at 18:59, Jon Maber wrote:
>>
>>> Nearly all user colour preference work will operate in Hue-  
>>> Saturation-Value space, not Red-Green-Blue space. However, the   
>>> standard Java HSV colour space (which Bodington currently uses) is   
>>> not very good so I've devised a better method. (Probably reinvented   
>>> but it only took a couple of days work.) The standard HSV space is   
>>> cylindrical where H is the perpendicular distance from the axis to   
>>> the colour point, H is the angle of that line from the red plane   
>>> and V is the distance up the cylinder.  All of the bottom face is   
>>> black. (which means that if V=0 then the colour is black regardless   
>>> of the values of H or S) However, the top face has white only at   
>>> the center and has bright rainbow colours around the edge.  This   
>>> means that if V is non-zero, V and H are kept constant and S is   
>>> varied then not only does the perceived saturation change but the   
>>> brightness does too. The method used to map the cube rgb space onto   
>>> the cylinder is also dodgy since for certain values of H changing S   
>>> distorts the perceived hue.
>>>
>>> My method also maps to a cylinder but the top face of the cylinder   
>>> is completely white.  This means that V==100% always produces white   
>>> no matter what the value of H or S. It also means that if H and V   
>>> are kept constant and S is varied, the perceived brightness and hue   
>>> keep constant. This is acheived by two rotations of the rgb cube so   
>>> that the white to black vector lines up with the z axis. Then the   
>>> shape is distorted so that vectors which run from the z axis to the   
>>> cube surface and which lie parallel to the x,y plane are stretched   
>>> uniformly to unit length.  The resulting cylinder is squashed down   
>>> the z axis to unit length.
>>
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the live  
> webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers

Re: [Bodington-developers] CSS Processing

[Owen D. <owe...@ou...>]

better to use HSI - Hue, Saturation, Intensty (aka IHS or HSB - Hue, 
Saturation, Brightness). This colour space can be visualised as two cones 
sandwiched together at their bases. The apex of the bottom cone represents 
[I min] (black) and the apex of the top cone represents [I max] (white). The 
line connecting the two represents the greyscale values (I). At each point 
along this line, H is undefined and S is 0. When I is 0, the horizontal 
plane of the colour space is greatest, because this is the plane where the 
bases of both cones meet. Therefore, S max is greater on this plane than 
anyhwere else in the colour space, thus the most vibrant colours are on this 
plane. Conversely, as you tend towards full brightness or minimum 
brightness, S max is reduced, until it eventually reaches 0. This means that 
as colours become lighter or darker, they automatically become less 
saturated. Furthermore, Jon's initial gripe with S does not apply, because 
adjusting saturation has no impact on H or I. This is a much more intutive 
way of representing colour than HSV. You simply think of it as a slider for 
brightness, a slider for saturation and one for hue, with brightness being 
the only variable that alters either of the other two (namely saturation). 
The Java Advanced Imageing (JAI) API has a class called IHSColorSpace 
(http://java.sun.com/products/java-media/jai/forDevelopers/jai-apidocs/javax/media/jai/IHSColorSpace.html) 
which conveniently manages colour space transformation from/to RGB.

btw, microsoft and CSS3 use the HSI colour space. apple use HSV. Photoshop 
etc. use both.

Anthony, I think you made a typo on that link because it's broken ;-)

owen

----- Original Message ----- 
From: "Antony Corfield" <an...@sm...>
To: <bod...@li...>
Sent: Friday, April 07, 2006 11:04 AM
Subject: Re: [Bodington-developers] CSS Processing


> We will be holding a 3 day seminar in HSV processing here in late June  - 
> to register, click on the link below:
> http://www.whatthefeckishetalkingabout.com/
>
> On 6 Apr 2006, at 19:37, Jon Maber wrote:
>
>> I must bow to your superior mathologicity.
>>
>> Many thanks for taking on this work package, good luck.....
>>
>> Jon
>>
>> Sean Mehan wrote:
>>
>>> Yes, all fine Jon, BUT what about compliance with the critical and 
>>> well known Hausdorff's Metric Top, you know:
>>>
>>> Let (S,d) be a metric space, and let X be the collection of all 
>>> nonempty bounded closed subsets of S. Let f:S * X -> R+ be defined by 
>>> f(s,B) = inf _(b in B) d(s,b), and let g: X * X -> R+ be given by g 
>>> (A,B) = sup_(a in A) f(a,B), and let delta(A,B) = max {g(A,B),g  (B,A)}. 
>>> You must concern yourself with (X, delta)! Your method   clearly fails 
>>> here! Pah!
>>>
>>> And for anyone wanting to quibble with my counterexample, yes, I   know, 
>>> but I couldn't write the vector cross product adequately in   this crap 
>>> test format, so had to resort to *.
>>>
>>> -s
>>>
>>>
>>> On 6 Apr 2006, at 18:59, Jon Maber wrote:
>>>
>>>> Nearly all user colour preference work will operate in Hue- 
>>>> Saturation-Value space, not Red-Green-Blue space. However, the 
>>>> standard Java HSV colour space (which Bodington currently uses) is 
>>>> not very good so I've devised a better method. (Probably reinvented 
>>>> but it only took a couple of days work.) The standard HSV space is 
>>>> cylindrical where H is the perpendicular distance from the axis to 
>>>> the colour point, H is the angle of that line from the red plane   and 
>>>> V is the distance up the cylinder.  All of the bottom face is   black. 
>>>> (which means that if V=0 then the colour is black regardless   of the 
>>>> values of H or S) However, the top face has white only at   the center 
>>>> and has bright rainbow colours around the edge.  This   means that if V 
>>>> is non-zero, V and H are kept constant and S is   varied then not only 
>>>> does the perceived saturation change but the   brightness does too. The 
>>>> method used to map the cube rgb space onto   the cylinder is also dodgy 
>>>> since for certain values of H changing S   distorts the perceived hue.
>>>>
>>>> My method also maps to a cylinder but the top face of the cylinder   is 
>>>> completely white.  This means that V==100% always produces white   no 
>>>> matter what the value of H or S. It also means that if H and V   are 
>>>> kept constant and S is varied, the perceived brightness and hue   keep 
>>>> constant. This is acheived by two rotations of the rgb cube so   that 
>>>> the white to black vector lines up with the z axis. Then the   shape is 
>>>> distorted so that vectors which run from the z axis to the   cube 
>>>> surface and which lie parallel to the x,y plane are stretched 
>>>> uniformly to unit length.  The resulting cylinder is squashed down 
>>>> the z axis to unit length.
>>>
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
>> language
>> that extends applications into web and mobile media. Attend the live 
>> webcast
>> and join the prime developer group breaking into this new coding 
>> territory!
>> http://sel.as-us.falkag.net/sel? cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Bodington-developers mailing list
>> Bod...@li...
>> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers 

Re: [Bodington-developers] CSS Processing

[Jon M. <jo...@te...>]

Owen,

the model you suggest _is_ much better than the usual HSV because, as 
you say, it solves one of my big gripes, but the difference with that 
and my model is the scaling of the saturation value.  In my model a 
color with a non-zero saturation and non-zero brightness which is 
adjusted to zero brightness retains it's (relative) saturation value and 
if the brightness is later transformed to a greater than zero value the 
saturation is preserved (as is the hue.)  The key thing about my model 
(which perhaps you'd call Hue, percentage Saturation[percentage in the 
sense of relative to the maximum possible saturation possible for the 
given intensity and hue], Intensity) is that any single value can be 
slid from 0 to 100% (or 0 to 360 degrees) without changing the valid 
ranges of the other two values whereas in the HSI (double conical model) 
the range of allowed saturation values depends on the intensity and so 
saturation has to be clipped.

The cylindrical model can be easily mapped onto the double-conical one 
but the reverse is not true because the black and the white points don't 
allow hue or saturation values. This means that any transform that is 
implemented in the double conical space can be implemented in 
cylindrical space but there are transforms in the cylindrical space that 
can't be implemented in double conical space.

I've produced a little Java app to play with the colour space and 
speaking subjectively I like the way colours change as a single slider 
is wizzed up and down. I'll have a go at changing it into an applet and 
stick it on a web page. Then people can ignore the talk and the maths 
and judge it on purely aesthetic grounds.

Jon


Owen Davies wrote:

> better to use HSI - Hue, Saturation, Intensty (aka IHS or HSB - Hue, 
> Saturation, Brightness). This colour space can be visualised as two 
> cones sandwiched together at their bases. The apex of the bottom cone 
> represents [I min] (black) and the apex of the top cone represents [I 
> max] (white). The line connecting the two represents the greyscale 
> values (I). At each point along this line, H is undefined and S is 0. 
> When I is 0, the horizontal plane of the colour space is greatest, 
> because this is the plane where the bases of both cones meet. 
> Therefore, S max is greater on this plane than anyhwere else in the 
> colour space, thus the most vibrant colours are on this plane. 
> Conversely, as you tend towards full brightness or minimum brightness, 
> S max is reduced, until it eventually reaches 0. This means that as 
> colours become lighter or darker, they automatically become less 
> saturated. Furthermore, Jon's initial gripe with S does not apply, 
> because adjusting saturation has no impact on H or I. This is a much 
> more intutive way of representing colour than HSV. You simply think of 
> it as a slider for brightness, a slider for saturation and one for 
> hue, with brightness being the only variable that alters either of the 
> other two (namely saturation). The Java Advanced Imageing (JAI) API 
> has a class called IHSColorSpace 
> (http://java.sun.com/products/java-media/jai/forDevelopers/jai-apidocs/javax/media/jai/IHSColorSpace.html) 
> which conveniently manages colour space transformation from/to RGB.
>
> btw, microsoft and CSS3 use the HSI colour space. apple use HSV. 
> Photoshop etc. use both.
>
> Anthony, I think you made a typo on that link because it's broken ;-)
>
> owen
>
> ----- Original Message ----- From: "Antony Corfield" 
> <an...@sm...>
> To: <bod...@li...>
> Sent: Friday, April 07, 2006 11:04 AM
> Subject: Re: [Bodington-developers] CSS Processing
>
>
>> We will be holding a 3 day seminar in HSV processing here in late 
>> June  - to register, click on the link below:
>> http://www.whatthefeckishetalkingabout.com/
>>
>> On 6 Apr 2006, at 19:37, Jon Maber wrote:
>>
>>> I must bow to your superior mathologicity.
>>>
>>> Many thanks for taking on this work package, good luck.....
>>>
>>> Jon
>>>
>>> Sean Mehan wrote:
>>>
>>>> Yes, all fine Jon, BUT what about compliance with the critical and 
>>>> well known Hausdorff's Metric Top, you know:
>>>>
>>>> Let (S,d) be a metric space, and let X be the collection of all 
>>>> nonempty bounded closed subsets of S. Let f:S * X -> R+ be defined 
>>>> by f(s,B) = inf _(b in B) d(s,b), and let g: X * X -> R+ be given 
>>>> by g (A,B) = sup_(a in A) f(a,B), and let delta(A,B) = max 
>>>> {g(A,B),g  (B,A)}. You must concern yourself with (X, delta)! Your 
>>>> method   clearly fails here! Pah!
>>>>
>>>> And for anyone wanting to quibble with my counterexample, yes, I   
>>>> know, but I couldn't write the vector cross product adequately in   
>>>> this crap test format, so had to resort to *.
>>>>
>>>> -s
>>>>
>>>>
>>>> On 6 Apr 2006, at 18:59, Jon Maber wrote:
>>>>
>>>>> Nearly all user colour preference work will operate in Hue- 
>>>>> Saturation-Value space, not Red-Green-Blue space. However, the 
>>>>> standard Java HSV colour space (which Bodington currently uses) is 
>>>>> not very good so I've devised a better method. (Probably 
>>>>> reinvented but it only took a couple of days work.) The standard 
>>>>> HSV space is cylindrical where H is the perpendicular distance 
>>>>> from the axis to the colour point, H is the angle of that line 
>>>>> from the red plane   and V is the distance up the cylinder.  All 
>>>>> of the bottom face is   black. (which means that if V=0 then the 
>>>>> colour is black regardless   of the values of H or S) However, the 
>>>>> top face has white only at   the center and has bright rainbow 
>>>>> colours around the edge.  This   means that if V is non-zero, V 
>>>>> and H are kept constant and S is   varied then not only does the 
>>>>> perceived saturation change but the   brightness does too. The 
>>>>> method used to map the cube rgb space onto   the cylinder is also 
>>>>> dodgy since for certain values of H changing S   distorts the 
>>>>> perceived hue.
>>>>>
>>>>> My method also maps to a cylinder but the top face of the 
>>>>> cylinder   is completely white.  This means that V==100% always 
>>>>> produces white   no matter what the value of H or S. It also means 
>>>>> that if H and V   are kept constant and S is varied, the perceived 
>>>>> brightness and hue   keep constant. This is acheived by two 
>>>>> rotations of the rgb cube so   that the white to black vector 
>>>>> lines up with the z axis. Then the   shape is distorted so that 
>>>>> vectors which run from the z axis to the   cube surface and which 
>>>>> lie parallel to the x,y plane are stretched uniformly to unit 
>>>>> length.  The resulting cylinder is squashed down the z axis to 
>>>>> unit length.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
>>> language
>>> that extends applications into web and mobile media. Attend the live 
>>> webcast
>>> and join the prime developer group breaking into this new coding 
>>> territory!
>>> http://sel.as-us.falkag.net/sel? 
>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>> _______________________________________________
>>> Bodington-developers mailing list
>>> Bod...@li...
>>> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
>> language
>> that extends applications into web and mobile media. Attend the live 
>> webcast
>> and join the prime developer group breaking into this new coding 
>> territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Bodington-developers mailing list
>> Bod...@li...
>> https://lists.sourceforge.net/lists/listinfo/bodington-developers 
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>

Re: [Bodington-developers] CSS Processing

[Jon M. <jo...@te...>]

O.K. here's an end to the math's. How about some pretty picture's instead?

http://www.jonmaber.co.uk/colour/SwatchApplet.html

Play with the slider's and watch the pretty colour's. It''s really nice.

Jon'than

Re: [Bodington-developers] CSS Processing

[Jon M. <jo...@ci...>]

O.K. here's an end to the math's. How about some pretty picture's instead?

http://www.jonmaber.co.uk/colour/SwatchApplet.html

Play with the slider's and watch the pretty colour's. It''s really nice.

Jon'than

Re: [Bodington-developers] CSS Processing

[Antony C. <an...@sm...>]

Just revisiting this as we still have the problem of 2 methods for  
setting colour in UI - one using style.css and the other using Bod  
code.

Jon what was the conclusion from this debate and your coding? Do we  
have something that can be worked in to the bodington code without too  
much effort (or may be have already)? Would this fit with (Matthew's?)  
re-factoring of facility css?

Antony




On 7 Apr 2006, at 14:29, Jon Maber wrote:

> Owen,
>
> the model you suggest _is_ much better than the usual HSV because, as  
> you say, it solves one of my big gripes, but the difference with that  
> and my model is the scaling of the saturation value.  In my model a  
> color with a non-zero saturation and non-zero brightness which is  
> adjusted to zero brightness retains it's (relative) saturation value  
> and if the brightness is later transformed to a greater than zero  
> value the saturation is preserved (as is the hue.)  The key thing  
> about my model (which perhaps you'd call Hue, percentage  
> Saturation[percentage in the sense of relative to the maximum possible  
> saturation possible for the given intensity and hue], Intensity) is  
> that any single value can be slid from 0 to 100% (or 0 to 360 degrees)  
> without changing the valid ranges of the other two values whereas in  
> the HSI (double conical model) the range of allowed saturation values  
> depends on the intensity and so saturation has to be clipped.
>
> The cylindrical model can be easily mapped onto the double-conical one  
> but the reverse is not true because the black and the white points  
> don't allow hue or saturation values. This means that any transform  
> that is implemented in the double conical space can be implemented in  
> cylindrical space but there are transforms in the cylindrical space  
> that can't be implemented in double conical space.
>
> I've produced a little Java app to play with the colour space and  
> speaking subjectively I like the way colours change as a single slider  
> is wizzed up and down. I'll have a go at changing it into an applet  
> and stick it on a web page. Then people can ignore the talk and the  
> maths and judge it on purely aesthetic grounds.
>
> Jon
>
>
> Owen Davies wrote:
>
>> better to use HSI - Hue, Saturation, Intensty (aka IHS or HSB - Hue,  
>> Saturation, Brightness). This colour space can be visualised as two  
>> cones sandwiched together at their bases. The apex of the bottom cone  
>> represents [I min] (black) and the apex of the top cone represents [I  
>> max] (white). The line connecting the two represents the greyscale  
>> values (I). At each point along this line, H is undefined and S is 0.  
>> When I is 0, the horizontal plane of the colour space is greatest,  
>> because this is the plane where the bases of both cones meet.  
>> Therefore, S max is greater on this plane than anyhwere else in the  
>> colour space, thus the most vibrant colours are on this plane.  
>> Conversely, as you tend towards full brightness or minimum  
>> brightness, S max is reduced, until it eventually reaches 0. This  
>> means that as colours become lighter or darker, they automatically  
>> become less saturated. Furthermore, Jon's initial gripe with S does  
>> not apply, because adjusting saturation has no impact on H or I. This  
>> is a much more intutive way of representing colour than HSV. You  
>> simply think of it as a slider for brightness, a slider for  
>> saturation and one for hue, with brightness being the only variable  
>> that alters either of the other two (namely saturation). The Java  
>> Advanced Imageing (JAI) API has a class called IHSColorSpace  
>> (http://java.sun.com/products/java-media/jai/forDevelopers/jai- 
>> apidocs/javax/media/jai/IHSColorSpace.html) which conveniently  
>> manages colour space transformation from/to RGB.
>>
>> btw, microsoft and CSS3 use the HSI colour space. apple use HSV.  
>> Photoshop etc. use both.
>>
>> Anthony, I think you made a typo on that link because it's broken ;-)
>>
>> owen
>>
>> ----- Original Message ----- From: "Antony Corfield"  
>> <an...@sm...>
>> To: <bod...@li...>
>> Sent: Friday, April 07, 2006 11:04 AM
>> Subject: Re: [Bodington-developers] CSS Processing
>>
>>
>>> We will be holding a 3 day seminar in HSV processing here in late  
>>> June  - to register, click on the link below:
>>> http://www.whatthefeckishetalkingabout.com/
>>>
>>> On 6 Apr 2006, at 19:37, Jon Maber wrote:
>>>
>>>> I must bow to your superior mathologicity.
>>>>
>>>> Many thanks for taking on this work package, good luck.....
>>>>
>>>> Jon
>>>>
>>>> Sean Mehan wrote:
>>>>
>>>>> Yes, all fine Jon, BUT what about compliance with the critical and  
>>>>> well known Hausdorff's Metric Top, you know:
>>>>>
>>>>> Let (S,d) be a metric space, and let X be the collection of all  
>>>>> nonempty bounded closed subsets of S. Let f:S * X -> R+ be defined  
>>>>> by f(s,B) = inf _(b in B) d(s,b), and let g: X * X -> R+ be given  
>>>>> by g (A,B) = sup_(a in A) f(a,B), and let delta(A,B) = max  
>>>>> {g(A,B),g  (B,A)}. You must concern yourself with (X, delta)! Your  
>>>>> method   clearly fails here! Pah!
>>>>>
>>>>> And for anyone wanting to quibble with my counterexample, yes, I    
>>>>> know, but I couldn't write the vector cross product adequately in   
>>>>>  this crap test format, so had to resort to *.
>>>>>
>>>>> -s
>>>>>
>>>>>
>>>>> On 6 Apr 2006, at 18:59, Jon Maber wrote:
>>>>>
>>>>>> Nearly all user colour preference work will operate in Hue-  
>>>>>> Saturation-Value space, not Red-Green-Blue space. However, the  
>>>>>> standard Java HSV colour space (which Bodington currently uses)  
>>>>>> is not very good so I've devised a better method. (Probably  
>>>>>> reinvented but it only took a couple of days work.) The standard  
>>>>>> HSV space is cylindrical where H is the perpendicular distance  
>>>>>> from the axis to the colour point, H is the angle of that line  
>>>>>> from the red plane   and V is the distance up the cylinder.  All  
>>>>>> of the bottom face is   black. (which means that if V=0 then the  
>>>>>> colour is black regardless   of the values of H or S) However,  
>>>>>> the top face has white only at   the center and has bright  
>>>>>> rainbow colours around the edge.  This   means that if V is  
>>>>>> non-zero, V and H are kept constant and S is   varied then not  
>>>>>> only does the perceived saturation change but the   brightness  
>>>>>> does too. The method used to map the cube rgb space onto   the  
>>>>>> cylinder is also dodgy since for certain values of H changing S    
>>>>>> distorts the perceived hue.
>>>>>>
>>>>>> My method also maps to a cylinder but the top face of the  
>>>>>> cylinder   is completely white.  This means that V==100% always  
>>>>>> produces white   no matter what the value of H or S. It also  
>>>>>> means that if H and V   are kept constant and S is varied, the  
>>>>>> perceived brightness and hue   keep constant. This is acheived by  
>>>>>> two rotations of the rgb cube so   that the white to black vector  
>>>>>> lines up with the z axis. Then the   shape is distorted so that  
>>>>>> vectors which run from the z axis to the   cube surface and which  
>>>>>> lie parallel to the x,y plane are stretched uniformly to unit  
>>>>>> length.  The resulting cylinder is squashed down the z axis to  
>>>>>> unit length.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>>>> language
>>>> that extends applications into web and mobile media. Attend the  
>>>> live webcast
>>>> and join the prime developer group breaking into this new coding  
>>>> territory!
>>>> http://sel.as-us.falkag.net/sel?  
>>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>>> _______________________________________________
>>>> Bodington-developers mailing list
>>>> Bod...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>>> language
>>> that extends applications into web and mobile media. Attend the live  
>>> webcast
>>> and join the prime developer group breaking into this new coding  
>>> territory!
>>> http://sel.as-us.falkag.net/sel? 
>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>> _______________________________________________
>>> Bodington-developers mailing list
>>> Bod...@li...
>>> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>> language
>> that extends applications into web and mobile media. Attend the live  
>> webcast
>> and join the prime developer group breaking into this new coding  
>> territory!
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Bodington-developers mailing list
>> Bod...@li...
>> https://lists.sourceforge.net/lists/listinfo/bodington-developers
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the live  
> webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Bodington-developers mailing list
> Bod...@li...
> https://lists.sourceforge.net/lists/listinfo/bodington-developers

Re: [Bodington-developers] CSS Processing

[Matthew B. <mat...@ou...>]

Antony Corfield wrote:
> Just revisiting this as we still have the problem of 2 methods for  
> setting colour in UI - one using style.css and the other using Bod  
> code.

Yeah. It makes the whole set of options in Bodington relating to setting
display preferences broken as only parts of the interface change. when
users change these settings.

> Jon what was the conclusion from this debate and your coding? Do we  
> have something that can be worked in to the bodington code without too  
> much effort (or may be have already)? Would this fit with (Matthew's?)  
> re-factoring of facility css?

All the refactoring did was move the code from facility into another
class so that Facility was 3000 lines smaller. The CSS generation code
itself is still just the same.

-- 
 Matthew Buckett