So what's wrong with version 1.2?

[MtnViewJohn]

But if '*x 2' means the same as 'size 2 1' then why bother? I was thinking it would be a way to decouple translation from the size adjustment so that you could control the size of primitive shapes separately from their spacing apart. This code:

Code: Select all

rule SquareLine {
    SQUARE {}
    SquareLine { x 3 s 0.95 *x 1.1765 }
}

would produce a line of shrinking squares that are evenly spaced.

It occurs to me now that I was wrong earlier when I said

What we could do is apply the scaling concept to size, rotation, skew, x, and y (but not flip). This modifies the adjustment before it gets multiplied into the transform matrix and is lost.

Implementing scaling for size, rotation, or skew would require a huge change to the implementation. Currently Context Free parses the adjustments for each shape into affine transforms and multiplies them all together into a single affine transform matrix. But scaling isn't a parse-time affect, it is a render-time affect. Each shape rule will get rendered hundreds or thousands of times and the scaling factors will be different for each render. But the adjstments that we want to scale are gone at render-time. They have disappeared into the affine transform matrix and we can't get them back. This is basically the same problem that we have with implementing size, rotation, or skew limits.

The only way that we can to size, rotation, or skew scaling is if we give up on producing an affine transform matrix during the parse stage and just record all of the adjustments. Alas, because of the 'foo [x 0.5 s 0.9 x 0.5]' syntax the number of ligitimate adjustments can be unbounded. And I thought I was so clever. But this is not really an impossible task. If limiting and/or scaling of size, rotation, or skew is deemed important then we can do it.

Adding scaling or limiting to x and y translation wouldn't require such a drastic step. It is very easy to extract and manipulate the translation part of an affine transform matrix.

[lagroue]

But if '*x 2' means the same as 'size 2 1' then why bother? I was thinking it would be a way to decouple translation from the size adjustment so that you could control the size of primitive shapes separately from their spacing apart. This code:

Code: Select all

rule SquareLine {
    SQUARE {}
    SquareLine { x 3 s 0.95 *x 1.1765 }
}

would produce a line of shrinking squares that are evenly spaced.

It occurs to me now that I was wrong earlier when I said

What we could do is apply the scaling concept to size, rotation, skew, x, and y (but not flip). This modifies the adjustment before it gets multiplied into the transform matrix and is lost.

Implementing scaling for size, rotation, or skew would require a huge change to the implementation. Currently Context Free parses the adjustments for each shape into affine transforms and multiplies them all together into a single affine transform matrix. But scaling isn't a parse-time affect, it is a render-time affect. Each shape rule will get rendered hundreds or thousands of times and the scaling factors will be different for each render. But the adjstments that we want to scale are gone at render-time. They have disappeared into the affine transform matrix and we can't get them back. This is basically the same problem that we have with implementing size, rotation, or skew limits.

The only way that we can to size, rotation, or skew scaling is if we give up on producing an affine transform matrix during the parse stage and just record all of the adjustments. Alas, because of the 'foo [x 0.5 s 0.9 x 0.5]' syntax the number of ligitimate adjustments can be unbounded. And I thought I was so clever. But this is not really an impossible task. If limiting and/or scaling of size, rotation, or skew is deemed important then we can do it.

Adding scaling or limiting to x and y translation wouldn't require such a drastic step. It is very easy to extract and manipulate the translation part of an affine transform matrix.

Having "*x 2" equivalent with "size 2 1" had only a consistency purpose, should scale be implemented for other parameters.

I understand the difficulties behind.

You know what ? Scale parameters are not a requested feature - they just are a topic of discussion on the grammar itself, some kind of mind experience.

"flip 0" is a shortcut for "size 1 -1" and the theorical "*y -1" :
- there is theorical room for scale parameters
- actual parameters have scale equivalents
- there's no problem with redundancy when its purpose is to make things clearer.

All of this helps us being confident that good grammar design decisions have been taken.

About that, I'm still wondering when Chris, who designed cfdg first, decides to join the battleground ? (proper English ? not quite sure...)

But ! But what ? You're reading this ? You're not rushing coding the fantastic new hue control we just can't wait playing with ?

[MtnViewJohn]

I'm glad that scaling is off the table. I was only bluffing about being able to do it.

Maybe Chris is too appalled to speak because I added the 'hue =x' feature despite it not being in the spirit of context free. The sad thing is that the feature is necessary of we have the color limit feature.

The new hue target features are basically done. Mark and I will get out a new experimental release before Mark disappears for a week. It is pretty much going to be exactly as you suggested except that 'hue 0.30|' increases 30% toward the target hue and 'hue -0.30|' decreased 30% toward the target hue.

There is no normalization of hue to keep it in the interval [0,360). You could write '|hue =720 hue =-360' and wrap three times around the color wheel before approaching 720. If the current hue is 330 and you write 'hue 60' the current hue becomes 390, not 30.

But what happens if you write 'hue 0.30|' and the target hue is less than the current hue? I just added 360 to the target hue until it was greater. Same for 'hue -0.30|' in the other direction. I don't know if that was the right thing to do. It seems kind of lame.

Maybe 'hue 0.30|' should always take you closer to the target hue and 'hue -0.30|' takes you farther away. Kind of like what you first suggested, only computed over the interval (-infinity,+infinity) instead of [0,360).

[MtnViewJohn]

I talked to Mark about this:

But what happens if you write 'hue 0.30|' and the target hue is less than the current hue? I just added 360 to the target hue until it was greater. Same for 'hue -0.30|' in the other direction. I don't know if that was the right thing to do. It seems kind of lame.

He says that this is actually the right way to handle target hue and that this can be made consistent by always normalizing hue to the interval [0,360). This would make my example of cycling three times around the color wheel with 'hue =-360 |hue = 720' meaningless. (Remember, Mark hates rainbows. ) But I guess that the supposed benefits of not normalizing hue are actually all dumb and that normalizing hue is the best way to have a consistent set of hue controls.

[lagroue]

You're not alone being helpless - I'm even more since my own husband is totally out of the business !

(and he does love rainbow - at least when they're sung, somewhere, over the )