blackfoundrycom / variable-components-spec Goto Github PK

Not every font using smart components will be variable... I think a flag should control whether VarIdx values are present.

This also means the font should work without fvar.

In component transformations, we define ScaleX and ScaleY. Ideally only one should value be required when x and y scale are the same.

There are three options (the default scale factor is 1.0):

1. Each value needs to be specified if it's different from the default. So when x == y and x != default, both need to be specified (this is the current situation, as implented by rcjktools).

2. If ScaleY is missing, it should default to whatever ScaleX is. Downside: need two values if x != default and y == default

3. If ScaleY is missing, it should default to whatever ScaleX is if a certain flag has been set, else default to 1.0.

Option 3 is most compact, but perhaps it is trying too hard to solve a relatively rare case. It may not be worth the added complexity.

I'm leaning towards option 2.

Here and elsewhere you use "base glyph", which is not a term used in the OT 'glyf' chapter when discussing composites. It would help if you clarified. In this particular instance, it's not clear if what is meant is the glyph ID of the composite being assembled or of a component used in the composite.

I gather "the designspace" in this case is that of the composite, not the global designspace?

See also the last section of https://github.com/BlackFoundryCom/variable-components-spec/blob/main/variable-components-spec.md#how-to-process-varc-data

The current design and implementation (at https://github.com/BlackFoundryCom/rcjk-tools/) do not do this.

If a component base glyph implements variations for a global axis (say wght), the current design requires to set the value wght explicitly from the component reference.

If the wght value does not need to be changed by the component reference, this will require some redundant data.

It appears that the model GlyphsApp uses for Smart Components would benefit from implicitly passing down global axis values. I don't think Smart Component references can influence/overwrite global axis values.

Nice to see this proposal.

I wanted to check you are aware of another OpenType format proposal relating to components, namely my own colr-gradients-spec/Rotated components suggestion to add component transforms to the COLRv1 format. The idea behind it is that COLRv0 layers are already rather like components, and that, by allowing transforms in each included glyph layer, we can make COLRv1 a superset of the capabilities of old-style "glyf" composites. While making the colour Muybridge horse, I realized that there was a common case where the fallback b/w glyph references exactly the same glyph components as the COLR glyph layers, and so it seemed sensible to give COLR the same capabilities for transformation as glyf has, rather than force this case to perform all transforms in glyf to new transformed components, then layer those transformed composite glyphs in COLR. For good measure, I proposed flags to handle explicit rotation in degrees and @jfkthame added shear in degrees too. I imagined in the future controlling this rotation angle with an axis. Also, one day, I imagined this improved transform structure being incorporated into an updated glyf spec, to avoid people using the COLR apparatus unnecessarily — @behdad believes clients should be free to ignore COLR/CPAL tables entirely if they have no use for colour.

So that’s the background to COLRv1 transforms. The proposal seems to have met with approval from @PeterConstable and @rsheeter, among others, and is well on the way to being proposed as an update to OpenType.

You can probably already see the issue I am worrying about, namely that, with your variable component idea and good old glyf, it makes THREE different ways to represent composite glyphs. I don’t think this is a good outcome. So I wonder what your thoughts are. I guess we can think of:

• merging your component variations with the COLRv1 transform to use the same structure in both
• removing transforms from COLRv1 for now, while we come up with a unified transform structure

In any case I would be pleased if you would take a look through the COLRv1 transform discussion, and add some comments. It would be a shame to do things differently without a clear reason.

The global designspace location can affect the composite glyph, but it does not need to affect the designspace location of the base glyph directly.

Is this saying that the global designspace (GDS) location can affect the composite designspace location of components?

The OT 'glyf' chapter doesn't use the term "base glyph". Do you mean the first component in the composite description? (I'm guessing No.) Or is this saying that affects from the GDS location on a component do not affect the underlying glyph outline of the component (i.e., doesn't entail any effects on other uses of that glyph outline as a component)? Or, is this saying that the GDS location can affect the underlying outline of a component and that those effects will be seen in the composite?

In saying "doesn't need", it's not clear to me if you're saying, "In some cases, X might not happen" or rather "To achieve the design goal of the proposal, it is not a requirement that..."

How does our design of reusable axes affect the normalized range of an axis, and does it matter?

Normalized axis values are between -1.0 and +1.0, but can be limited based on the fvar user values:

• if min < default < max, then the range is -1.0 to +1.0
• if min == default and default < max, then the range is 0.0 to +1.0
• if min < default and default == max, then the range is -1.0 to 0.0

At the VarC level, we don't deal with user coordinates anymore, but we may need to specify how to clamp interpolated designspace coordinates.