Demo VARC component designspace conditions

[davelab6]

In harfbuzz/boring-expansion-spec#104 @skef has proposed the benefits of VARC components having designspace conditions (like rvrn); tldr is that because VARC is processed after GSUB, rvrn cannot be used efficiently, so for example if you want an atom level variable component to change its contour topology, you have to rvrn away all glyphs that use it, currently.

I see that this could be useful for CJK stroke simplification in opsz, to avoid doing tricks with the contours, but @rsheeter pointed out (and I strongly agree) that the spec community will be wise to avoid adding anything to the standard based on speculation - we ought to require actual demonstrations of real-word use-cases. (The Amstelvar and Roboto Flex avar2 demo font projects are currently working through making such actual demos and may reveal avar3 requirements :)

I would be happy if we could make some examples within this project, even just in source form such that how it would be useful can be illustrated, in wait for future actual tooled-up running-code demos :)

[justvanrossum]

I've forwarded your question to the design team.

[YuxinBlack]

Do you mean enabling incompatible segments of the designspace to interpolate?

incompatible_segments_of_ds.mov

Or jump in the designspace with design tricks?

interpolatable_ds_with_jump.mov

[skef]

@YuxinBlack Conceptually the feature is about neither of these, but it's (among other things) a different way of approaching the latter.

The idea is that a given component or not can be included, or one version of a component can be included in some cases but a different component in other cases, based on condition sets (as specified in the feature variations part of the spec, and already extended with "condition values", which I don't need to go into here).

So, in your second case, instead of playing design tricks with intermediate masters, you would just include the middle stem at the points of the design space where it should be visible and not where it shouldn't be. In other cases you might include one component appropriate for larger sizes and a simplified component for lower optical sizes.

@davelab6 also found this related subject: https://commons.wikimedia.org/wiki/File:CJK_SO-stroke_reduction.svg

Anyway, harfbuzz/boring-expansion-spec#104 (comment) has the motivation and the design which provides the idea in a few paragraphs.

[skef]

BTW, since

1. the primary goal of VARC is saving file space and
2. the sort of "design tricks" illustrated in the second video above will generally require a different interpolable component master at some non-typical point in design space,

it would also be worth just comparing the file cost of the tricks versus only including the component being hidden where its needed. The implementation of such tricks adds design complexity to a font, and if they also typically take up more file space that's already an argument for conditional components.

[BlackFoundry]

If we consider Variable Components as small one-glyph variable fonts; it is worth considering the full current possibilities of VF to be ported to Variable Components.

The example of the first videos could be implemented by a 'rvrn' feature at the glyph level: its components composition would be conditional to the designspace location. We have 4 components for the first range of the axis, then 5 for the second range. To make it possible we could imagine to make 2 additional components: one assembling the 4, the other assembling 5, and switching components if a given condition is met.

Another possibility could be to make a component activation (and visibility) conditional to the local glyph-designspace, and/or to the global font-designspace.