Page 1 of 1

bug: startshape FILL

Posted: Thu Jan 19, 2017 6:54 pm
by kipling
While golfing a design in the gallery, curiosity led me to try the shortest possible valid cfdg

Code: Select all

startshape FILL
What happened was the thing I least expected. (insert appropriate clickbait link)
Variations with

Code: Select all

startshape FILL[...]
also are incorrect - the shape count is correct, but not the drawing.
With explicit clipping it is happy:

Code: Select all

startshape FILL[sat 1 b .5]
CF::Size=[s 1]
So the obvious guess is that it fails to find a bounding box in the case where the shape list only has FILLs in it.
Obviously this "bug" is not at all critical - there is no practical reason for wanting this to work.

Re: bug: startshape FILL

Posted: Fri Jan 20, 2017 3:23 pm
by MtnViewJohn
It should do better. While checking this out I discovered valid cfdg input that causes Context Free to hang. Do you get the error message "Invalid UTF-8 encoding: ASCII null character" if you have startshape FILL with no line feed at the end?

Re: bug: startshape FILL

Posted: Fri Jan 20, 2017 11:20 pm
by kipling
No, not from within the macOS Context Free.app window that is.

Re: bug: startshape FILL

Posted: Fri Jan 20, 2017 11:22 pm
by kipling
This also doesn't work, except that it momentarily draws the screen black before redrawing it white

Code: Select all

startshape A
shape A{
	FILL[]
	FILL[z 1]
	}
This supports my guess earlier.

Re: bug: startshape FILL

Posted: Sat Jan 21, 2017 3:39 pm
by MtnViewJohn
The bug is that the code that filters out shapes that are too small or infinitely large is supposed to always draw FILL shapes. But if there is nothing but FILLs then it filters them out too. You are right that this is caused by the lack of a bounding box.

I also discovered that the cfdg parser handles end-of-file incorrectly in some cases and can hang or report weird errors.