designspace deferred string replacements

[mhosken]

In supporting the designspace function, I notice that it is really hard to modify the various magic strings that come back from the designspace procesing. One can't simply modify the string, since the string is lazily and late evaluated. The problem arises because so many of the variables from the designspace instance can have spaces in them.

So I've added a str_replace() that gets deferred so that the inside values are expanded. Currently it just calls str.replace. I'm wondering if it needs to call re.sub instead. Which would folk prefer? or maybe we need some kind of deferred_eval.

I think defer_map(lambda x:x.replace(' ', '-'), '${NAME}.ttf') for the target attribute is a mouthful too much. str_replace('${NAME}.ttf', ' ', '-') is bad enough (and probably too bad too). Other alternatives include: '${NAME/ /-}.ttf' ala bash or '${NAME_D}.ttf' as in a magic set of variables with _D suffix for dash.

[mhosken]

How about this? We structure a fieldname as:

• 'N:' prefix
• element (NAME, FILENAME, STYLE, AXIS etc.)
• '_' separator
• modifier (DASH, BASE, axisname)

The list of elements is the set of attributes in a designspace instance: FAMILYNAME, STYLENAME, FILENAME, NAME, POSTSCRIPTFONTNAME, STYLEMAPFAMILYNAME, STYLEMAPSTYLENAME. There is a special element named AXIS that references the various dimensions in the location element in the instance.

For most elements (all but AXIS), the modifier is, in effect, a function to run over the result:

• DASH - convert spaces to '-': x.replace(' ', '-')
• BASE - os.path.basename

For the AXIS element, the modifier is the name of the axis for which the xvalue should be returned: ${D:AXIS_WEIGHT}. Notice that this will be a string exactly as found in the designspace file so may be 300.000000.

All possible field names and values would be calculated before expansion. Thankfully, there aren't that many (8 x 2 + 5ish). But in due course these could be lazily evaluated if this were necessary due to some other weird modifier being added to the approach.

[jvgaultney]

Is there an assumption on which Axes would be supported? Probably should include the common axes (AXIS_WEIGHT, AXIS_WIDTH, AXIS_CUSTOM).

[bobh0303]

N: or D: prefix? Propose DS: instead.

[mhosken]

AXIS_ whatever is listed as a dimension in the location element of the instance (or else whatever is in the axis/@name for all the axes/axis elements). So whatever you put in the designspace file is what you can ask for. I can go with DS: prefix.

[bobh0303]

Fixed -- see 53ae7b8