Re my example sign: The border widths were based on the estimated text stroke width of the destination and action message for the green and yellow panels, respectively; by coincidence, the border+gap on the yelloww panel nearly matches the border width on the green panel.
But doubled borders on bottom yellow "EXIT ONLY" panels are hardly vanilla provision--the more usual approach would be to run a black border (of the same width as the white border for the green background) out to the edge of the sign. We also don't attempt full scalability (unlike some other countries, e.g. Britain), so border width and corner radius are typically fixed without referring to the stroke width of the legend. The usual rule of thumb is 2" border with 12" corner radius for a sign having 16" UC/12" LC for primary destination legend.
The margin around the destination legend was set to ¾ the nominal text height; I'm aware that the side margins should be equal to the full text height.
This is fine, but actually the 3/4 spacing should apply across the whole sign except for the yellow panel, which implies 3/4 spacing between the top of the shield and the inner edge of the border. (Yellow panels are of fixed height and don't quite follow the usual spacing rules because of the downward-pointing arrow, which is usually 22" on a sign with 16" UC/12" LC primary destination legend and a yellow panel 36" high, inclusive of 2" black border.)
In any case, these are relatively low-level details and can be tackled at a later stage.
Re the project: My layout engine does not attempt to enforce specific metrics or proportions from the MUTCD or sign design manuals. Dimensions are largely driven by properties specified in the input. There may be, in the future, facilities to apply common properties to multiple elements to reduce redundancy in the input. The output is currently a report about the parsing and positioning process, plus SVG; when it goes beta, the primary output will be switched to SVG only. The source code will probably be made available when the featureset is stabilized.
I wish you the best of luck as you progress through development. I have actually considered something similar, which would accept sign design parameters encoded in a structured markup language and output finished signs in SVG. This could be used to make large numbers of relatively simple signs, which would be useful for making a pattern-accurate sign log of a rural Interstate highway. However, I eventually realized that the problem of positioning digits correctly in route shields was a bit more complex than simple optical centering, and that even with a large majority of signs being simply formatted, it would still be necessary to custom-build some signs using the CorelDRAW
scripts I already had in hand. I came to question whether a SVG-producing program would deliver any significant time savings above and beyond drawing each sign in hand in CorelDRAW
using my existing script suite, recycling elements from adjacent finished signs as necessary. I put this premise to the test by drawing several hundred signs on Columbus I-270 (using a photo sign inventory as a source). The results prompted me to stick with the CorelDRAW
scripts in the end, but this was more because the scripts were already in hand while the "sign autogenerator" would have required added development.