Some ideas for Context Free 3.0
Posted: Fri May 04, 2007 9:23 am
What should be the next round of feature additions to Context Free? What do you find hard that you wish was easier? Here are some of the things I am thinking about:
Stronger loop syntax: Instead of just having a single shape in a loop you could have a whole list of shapes, including other loops:
Continuations: Currently you can only pass color and shape transform from one shape to another, but with continuations you could wrap up a bunch of shape replacements and pass them to a shape. The receiving shape can execute them, pass them on to another shape, or wrap the continuation and some additional shapes up and pass them to another shape: Continuations could also be used to implement proportional spaced fonts:
Expressions: Anywhere you can have a number you can have an expression. Expressions can include various trig and math functions.
Parameterized rules: Rules can take numeric parameters that are like function parameters: The startshape line can have parameters that can be overridden by the user. You could create a movie based on parameterized frames instead of dividing shapes into frames.
Continuations would get there parameters resolved before they get wrapped up. Maybe it would be nice to support color changes and affine transforms as parameters in addition to numbers.
Maybe continuations are in the parameter list instead of the shape adjustment list. Then you could pass multiple continuations into a shape.
Polygons: Arbitrary polygons can be specified by having a list of VERTEX primitive shapes followed by one or more FILL and STROKE primitive shapes. The vertex list can be one or more distinct sets of vertices that can each be open or closed. You would be able to punch a hole in a polygon using either even-odd rules or nonzero rules.
Arcs: You could insert circles or arc segments into polygon vertex lists using a new ARC primitive shape, that takes start and end angles as parameters:
More than one color: Allow a shape to support more than one color. In addition to the current hue, sat, b adjustments there would be hue1, sat1, b1, hue2, sat2, b2, etc. You would be able to control which color is used to paint a given shape.
Virtual machine: Not really a feature, but an implementation change. The cfdg files would compile to byte-codes instead of raw shape lists. A virtual machine would then execute the startshape directive to produce a list of primitive shapes that are then rendered.
Stronger loop syntax: Instead of just having a single shape in a loop you could have a whole list of shapes, including other loops:
Code: Select all
rule grid5 {
5* {y 1} {
5* {x 1} CIRCLE {}
}
}
Code: Select all
rule grid5 {
5* {y 1} {
5* {x 1} CONTINUATION {}
}
}
rule foo {
grid5{ {CIRCLE {} SQUARE {s SQRT(2)/2 b 1}}
}
Code: Select all
rule Hello {
H{{e{{l{{l{{o{}}}}}}}}}
}
rule H {
H_glyph{}
CONTINUATION {x 0.95}
}
Parameterized rules: Rules can take numeric parameters that are like function parameters:
Code: Select all
rule grid<n> {
$n* {y 1} {
$n* {x 1} CONTINUATION {}
}
}
rule ring<n, r> {
$n* {r 360/$n} CONTINUATION{x $r}
}
rule foo {
grid<5>{ {CIRCLE {} SQUARE {s SQRT(2)/2 b 1}}
ring<20, 2.5> {x 2.5 y 2.5 z 1 {CIRCLE {b 1 s 0.2}}}
}
Continuations would get there parameters resolved before they get wrapped up. Maybe it would be nice to support color changes and affine transforms as parameters in addition to numbers.
Maybe continuations are in the parameter list instead of the shape adjustment list. Then you could pass multiple continuations into a shape.
Polygons: Arbitrary polygons can be specified by having a list of VERTEX primitive shapes followed by one or more FILL and STROKE primitive shapes. The vertex list can be one or more distinct sets of vertices that can each be open or closed. You would be able to punch a hole in a polygon using either even-odd rules or nonzero rules.
Arcs: You could insert circles or arc segments into polygon vertex lists using a new ARC primitive shape, that takes start and end angles as parameters:
Code: Select all
rule heart {
ARC<0, 180> {x 1}
ARC<0, 180> {x -1}
VERTEX {y -2}
CLOSE{}
FILL {b 1 sat 1}
}
Virtual machine: Not really a feature, but an implementation change. The cfdg files would compile to byte-codes instead of raw shape lists. A virtual machine would then execute the startshape directive to produce a list of primitive shapes that are then rendered.