Preemptive - what not to suggest for expanding CFDG!

[chris]

In an abstract sense, the CFDG language is interesting -- and appropriately named -- for the reason that all design rules are context-free. (Search google for "context free grammar" if you want to learn more about that). With that in mind, we'd rather not add anything to the language that violates this principal.

For examples: passing variables to child shapes, limiting the number of times a certain rule can be used, positioning things absolutely, and declaring a specific color -- these are all context "sensitive" rules. By including those things CFDG isn't CF anymore.

One logical expansion of CFDG is to move to 3D (or even 4D/animations). I don't personally have an interest in it, but maybe someone will volunteer in the development forum. It shouldn't be particularly hard -- the big question will be how to output the files. Povray? Some other rendering software? I'm curious where this could go, but personally I don't wish to add it right now...and I suspect Mark and John don't wish to add it to the Context Free program.

That said, add your suggestions here!

-Chris

[David Spitzley]

Ok, here's what I've come up with so far:

1) red, green, and blue attributes which can be used akin to brightness. The colors would compound as per brightness(i.e. a call to BLOB{b .5}, where BLOB contains CIRCLE{b .75} results in a CIRCLE plotted with brightness .375). Either color will need to trump brightness, vice versa, or brightness could simply be applied uniformly to the three color values (so b .5 applied to a shape which includes red .8 and no mention of blue or green would have red .4, blue .5, green .5

2) An Equilateral triangle object

3) A Right triangle object

4) Ability to set size separately for x and y; this would allow a square to be squashed into a rectangle, or a circle into an ellipse.

[MtnViewJohn]

If we add color I think the best way is to add hue and saturation to the existing brightness. I have a screen saver (http://www.ozonehouse.com/Spirex/index.html) that does random colors and when I worked in RBG space they were often muddy and ugly. Things looked much better when I switched to HSB space.

[bigelectricat]

how about providing the option to do anti-aliased rendering? it would smooth out the edges especially of rotated objects.

[bigelectricat]

another suggestion: being able to assign different fonts (helvetica, times, etc.) and font style (italic, bold, etc.)

[mtnviewmark]

how about providing the option to do anti-aliased rendering? it would smooth out the edges especially of rotated objects.

See the new F.A.Q. entry: Does it anti-alias?.

[yevgen]

Well, I can explain why I made my version of CFDG 'not-absolutely-CF'. Imagine you write a program to draw Xmas-tree with candles. No matter how the branches are located, the candles have to stick in upright position. That's why I extended the syntax a bit to allow absolute values for parameters, e.g. SQUARE {r =0}. Also I've added built-in RECT (empty square) and LINE rules. Anyway, I try to keep backward compatibility with CFDG (I appreciate bug reports on this, as well as any feedback!). My version now supports [kind of] scaling, as well as some other new features. Had not time to thorously test it yet. It's still at korsh.com/cfdg .

[bigdrip681]

it would be cool to have the program export as a PNG without the white background I.E. Transparent. Other than that this is an awesome program! And deceptively addictive once you get the hang of it

[Robert]

What about having the ability to export the files to post script? THis way we could open them in a program like Adobe Illustrator.

[MtnViewJohn]

The output of Context Free often has over a million shapes. Your hard disk would quickly fill up and Illustrator would choke. Even simple images have tens of thousands of shapes.

[logic]

In an abstract sense, the CFDG language is interesting -- and appropriately named -- for the reason that all design rules are context-free. (Search google for "context free grammar" if you want to learn more about that). With that in mind, we'd rather not add anything to the language that violates this principal.

For examples: passing variables to child shapes,
[snipped]

If you call them "parameters", only use them for predication and consider the resulting rules to be separate rules, then I don't see how this violates the principle. The basic idea is that no matter what the circumstances are, a rule always does the same thing, right?

Consider:

Code: Select all

rule CURVE(@segments, @anglepersegment)
{
  SQUARE { y 5 s 1 10 }
  (@segments > 0) CURVE(@segments - 1, anglepersegment) { y 10 r (@anglepersegment) }
}

If you think of CURVE(@segments, @anglepersegment) as being not a single rule that takes parameters but rather a class of rules that are generated based on two parameters, then clearly any one of those rules always does the same thing. For instance, the rule CURVE(5, 7) would have a body like:

Code: Select all

{
  SQUARE { y 5 s 1 7 }
  CURVE(4, 7) { y 10 r 7 }
}

..while the (final) rule CURVE(0, 7) would have a simpler body:

Code: Select all

{
  SQUARE { y 5 s 1 7 }
}

Both of these rules always do the same thing, right? In what way is the principle violated? These rules do not have side-effects.

The syntax I have in mind is:

• All parameter names shall be prefixed by '@' (or some other character, or suffixed, or what have you) to disambiguate them from any parameters (some of which might not have been added yet at the time the rule was created).
• A "rule class" has a list of parameter names enclosed in parentheses directly following its name.
• Parameters have only numeric values.
• An infix expression may be specified at any place a number is expected, provided it is surrounded by parentheses.
  
  Example:

  Code: Select all

      rule RECTANGLE(@width, @height)
      {
        SQUARE { s (@width) (@height) }
      }

• If such an expression precedes a rule's name, then it is treated as a boolean which, if false, excludes that statement entirely from the generated rule. As in C, relational operators shall return 0 for false and 1 for true, and any non-zero value shall be considered true for the purposes of predication.
• When invoking another rule, if the name supplied is that of a rule class and not a single rule, then the designated number of parameters shall follow as a list, enclosed in parentheses, of expressions. These expressions need not themselves be enclosed in parentheses.
  
  For an example, see the "CURVE" rule class above.
• This could interact with the looping proposal, such that an expression followed by an asterisk, a transformation expression, and a call to another rule repeats that transformation/rule as many times as the expression denotes.
  
  Example:

  Code: Select all

      rule CURVE(@segments, @anglepersegment)
      {
        (@segments) * [y 10 r (@anglepersegment)] SQUARE [y 5 s 1 10]
      }

Is this really a violation of the principle of no context?

[MtnViewJohn]

No it doesn't violate the context free principle. It is just syntactic sugar for describing a family of rules. You can't do anything with parameterized rules that isn't already possible by writing out lots of similar rules by hand (or by Python script).

But implementing it would be a very large undertaking because it would require huge changes "under-the-hood". Context Free produces an image in 3 stages:

1. The CFDG file is parsed down to a compact set of data structures.
2. The rendering algorithm is run on these rules to produce a list of shapes.
3. And the shapes are then sent to a canvas object to produce an image.

Parsing a CFDG file produces a set of rules, each of which is composed of a list of shape replacements. The shape replacement is simply a number that encodes the shape name, a color delta, and an affine transform matrix that is constructed at parse time from the shape geometry adjustments (r, x, y, skew, etc.).

With parameterized rules the shape replacements would have to be parsed to a much more abstract level and the color change and affine transform would have to be computed at render time instead of parse time. This major change would have to be done before even starting on implementing parameters. So, it's a great idea and might happen sometime, but not within the next 6 months.

[LazyMoon]

it would be cool to have the program export as a PNG without the white background I.E. Transparent.

ContextFree can do that currently, you just have to set your background to be transparent.

background { a -1 }

[LazyMoon]

The output of Context Free often has over a million shapes. Your hard disk would quickly fill up and Illustrator would choke. Even simple images have tens of thousands of shapes.

How does this differ from SVG export?

[MtnViewJohn]

The same problem exists with SVG output. If your design produces too many shapes then your SVG viewer might choke.