🚀 go-pugleaf

Interesting comments, Glenn.

> Imagine two carpenters building a door.  One builds the frame, the other
> builds the door.  Neither one is on-site, and neither has met the other.
> They are both working from the "spec", or the blueprint.  How likely
> do you think it is that the door fits in the frame, that the latch lands
> squarely in the hole in the door frame, and that the hinges are set
> properly?  I wouldn't give it 1 chance in 100,000, even with experienced
> carpenters.

If I hired two carpenters, and gave them this task, and either one of
them couldn't perform, I'd fire that one and find another.  I expect
quality carpentry, and I expect quality PostScript.

But, the whole point is that this is something that we want to, indeed
must, get working.  Hence that spec had better be good, and the ability
to test against the spec is essential.

If we are going to push structuring conventions with the attitude
that it might work sort of if we follow these rules, we'll be lucky
to get anything working ever.  Rather, we are obligated to

   - Formulate rules that, if followed, will always `work'.  This
     is not the case yet, but we may not be that far off the mark.

   - Enforce those rules with testing procedures and compatibility
     suites.  This is such a simple step that it is a pity that it
     hasn't been taken.

Maybe I'll take some time off this summer and put together a PostScript
test suite.