I think in general we could be able to express this kind of things. But how exactly a feature can be accomplished, I can't say that right now. We have to learn what needs to be done and then create the tools. This is why I want to create those plugin APIs, to define the ways how to extend metapolator. The question to answer any "Can I do X ..." request
for us is at which point in the system we need to do adjustments etc. Do we need a new parameter and a way to render it, Is it just a new operator for compound values, do we need a new MOM element to express
certain things. We need to learn how the system we are building works best.
*Will we be able to assign a relationship of one parameter to another? For example: It would be great to set the stem of the I and then use that stem again in the H but use the stem at say 96% for the R. How many levels deep could this go? I suspect that 10 or so would
cover all but 1-2% of design scenarios.*
Saying something should be at 96% will be possible and components will come. How much control we wan't to have over components in their context makes huge differences. At the moment, when borrowing the commonly used component concept, a component would not be changeable according to its context (like being used in an R glyph). But this could be build, I think. Another way would be to describe the stroke width directly. We'd need a pen like the penstroke pen in metafont for this (which we are planning, currently we have just a "metapolator" pen, which is similar, but not equal). But this would not be the same stem anymore, just the same parameters, or "StemWidthOf_I * 0.96" or so.
Depth would not be an issue, I think, as long as it's not infinite(a recursion). Maybe because of execution speed at some point, but not technically. No one programs 10 iterations by hand and then stops at 11. You just let the code get the references until everything is fetched.It would be great to be able to assign these relationship differently in different masters or states. Let’s use the stem example again. It would be great to assign it to 100% in the R (Same as the I) for a very thin weight but to a smaller % still in a very heavy weight.
This should be possible. But isn't this exactly what a master is all about, setting different parameters?It would be great to be able to lock a part of a component to another part for interpolation purposes. For example we might want a terminal to always grow larger from a baseline and never cross it. This might be solved by making sure of the relationship in all masters but it would be nice to be able to assign an absolute rule.
We can bind points to other points or baselines etc., that's included. We can do more complicated stuff, too. One problem I see is, that this kind of stuff is getting complex the more rules we apply. So I think we
need to develop tools/working styles/whatever to keep to complexity
The next question is how we can realize such hight level tools, like you describe it as an "absolute rule". I hope we will have a powerful enough plugin system eventually, that makes it possible to just add high level abstractions.A related idea - It would be great to allow movement of points but only within in a constrained space.
Like a threshold max and min? We can include this into the "Compound Types" for example. These ideas, we should collect them and with some knowledge think about how/where to include that the best. We should have detailed descriptions for such things, to make shure we understand each other.It would be nice to be able stack parameters in terms of priority. The simplest example is an angular serif and the distances between points. One might assign a set of values to each part but sat some point one of these values might conflict with another one. If we allow priority of one parametric assignment over another then higher priorities can be respected. This would allow the user to err without breaking the design.
Can this be done with "specificity", selectors have a sorting order encoded,http://en.wikipedia.org/wiki/Css#Specificity
? We do that. Or is it something else? I think it is close to what CPS already does.
But, I think, you can't make a working design without the power of creating a broken design.
To err is part of it.
* It would be great to allow for discontinuity. For example perhaps you are designing for very large and very small sizes. You might want to opt for one kind of terminal for the very small optical sizes. As you rise in size it may make sense to swap to a different one altogether. This would mean not having to have multiple metapolations for a family.*
You have to keep it somewhere. Maybe we could create two glyphs, but then one new type of swapping glyph, that knows the rules, when to swap. The swapping glyph would be at the code point of the final glyph, the two sources would maybe not get exported directly.
There are other ways to accomplish this, too, like a "display:none" for contours and then a
class that is used for switching (I like this approach more). Also, I think I remember that the latest version of superpolator has a swapping mechanism, too. This seems like a very useful thing.