Looks really cool! I'd love to see an open grammar definition format for all kinds of tools, both command-line and GUI.
I've worked on parsing TrueType files, and they have some really "interesting" grammars. For example, they have lookup tables that define offsets at the beginning of the file. Also, a format flag at the beginning of a table might define the structure of the rest of the table.
It seems that once you decide you want to be able to parse all of this, you're grammar will turn into a Turing-complete language. Have you considered this? Where do you stop?
Fonts have been notorious for being ill-defined, and this can wreak havoc on applications that do not handle them properly. I would be very interested in seeing some font related bffts surface for the purposes of font validation and analysis.
I have concerns about Turing-completeness, and am interested in maintaining the declarative nature of bffts. The grammar is has drifted from that goal, and I am not entirely sure how to bring it back.
I understand your concern for keeping the format declarative, but I'm not entirely sure you can handle TTF files that way, as you'll run into walls very quickly.
For example, to know the number of entries in the `loca` table, you have to parse the `numGlyphs` field from the `maxp` table. The `maxp` table doesn't have to come first...
That sounds positively diabolical. I'll have to think through this one some more, but off hand I wonder if something can be done with Binspector's slot/signal mechanism to detect when all the necessary pieces are in place. Something to ponder.
I've worked on parsing TrueType files, and they have some really "interesting" grammars. For example, they have lookup tables that define offsets at the beginning of the file. Also, a format flag at the beginning of a table might define the structure of the rest of the table.
It seems that once you decide you want to be able to parse all of this, you're grammar will turn into a Turing-complete language. Have you considered this? Where do you stop?