One implementation problem with generic polygon primitives is that it makes the amount of data in a finished shape variable. This would require some trickiness to implement, such as stuffing all unique polygons in all rules into a table on the side and then only keeping a table index in the finished shape data structure.
But I like the idea of having PATH and FILL primitives instead. PATH would simply draw a line from the end-point of the last line, like a line-to operation. The first PATH in a rule would act like move-to.
Code: Select all
rule LineTri {
PATH { y 10 }
PATH { y 10 r -60 s 0.5 }
PATH { y 10 r 60 s 0.5 }
PATH { y 10 s 0.5 }
}
The next PATH after a FILL would be a move-to, like the first PATH in a rule. Note that I show the rotate inside the LINE primitive affects the x and y parameters. Currently, rotates happen after translates, so I'm not sure this is the way to go. But until we have a way to specify translation in polar coordinates I see no reason to let the rotate parameter go to waste. What else could it possibly mean inside a PATH primitive? Specifying a size of zero is equivalent to a move-to.
FILL draws a line just like PATH. Then it draws a closing line back to the first point in the PATH and fills the closed path.
Code: Select all
rule FillTri {
PATH { y 1 s 0 }
PATH { y 1 r -60 s 0 }
FILL { y 1 r 60 s 0 }
}
You should be able to control whether the line segment joints are round, mitered, or beveled and whether the line endcaps are round or square. You should be able to control whether the fill rule is even-odd or non-zero winding (or no fill).