<div><div dir="auto">5. If there is a slider UI, then it's easy: the opsz slider could have some "auto" toggle. If on, the slider gets disabled and follows point size, if off, the slider explicitly chooses the opsz value regardless of point size.</div><div dir="auto"><br></div><div dir="auto"><span style="color:rgb(0,0,0)">6. An fvar-instance-based UI could try to be clever and pick the style names that have an elided STAT opsz word, but there is no guarantee that STAT "particle names" (Rainer's term for the style phrases used in STAT, which FL7 calls axis instance names but I like particle) are coordinated with fvar instance names. </span><br></div><div dir="auto"><span style="color:rgb(0,0,0)"><br></span></div><div dir="auto"><span style="color:rgb(0,0,0)">FL7 makes it easy to coordinate them: you set the axis order, you write the particle names & locations, using parantheses to elide a name, and then you click one button and get a list of instances which is the permutation of those, with elisions and auto-naming of style-linking groups (nameID 1). </span></div><div dir="auto"><span style="color:rgb(0,0,0)"><br></span></div><div dir="auto"><span style="color:rgb(0,0,0)">But many fonts may not follow this model, so there won't be an obvious mapping of fvar instances and STAT particles. </span></div></div><div dir="auto"><br></div><div dir="auto"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)">7. So the question really is about an fvar-instance-based UI, </span><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)">backwards-compatible with traditional apps.</span><br></div><div dir="auto"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></span></div><div dir="auto"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)">I'm not saying the spec should make recommendations, but we should, because we know the caveats while some developers may not realize them. </span></div><div dir="auto"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></span></div><div dir="auto"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)">A.</span></div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 21 Aug 2020 at 16:58, Adam Twardoch <<a href="mailto:adam@twardoch.com">adam@twardoch.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div><div dir="ltr">1. Let's say a font has the wght axis with the STAT instances "Light", "(Regular)" (elided) and "Bold". It again has the opsz axis with the STAT instances "Small", "(Text)" and "Display".<br><div dir="auto"><br></div><div dir="auto">The fvar instances permute those, so: </div><div dir="auto">- Shall Light</div><div dir="auto">- Light</div><div dir="auto">- <span style="color:rgb(0,0,0)">Display </span>Light</div><div dir="auto">- Small</div><div dir="auto">- Regular (from elided fallback)</div><div dir="auto">- Display</div><div dir="auto">- Small Bold</div><div dir="auto">- Bold</div><div dir="auto">- Display Bold</div><div dir="auto"><br></div><div dir="auto"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)">2. Let’s say a desktop app implements behavior like CSS "font-optical-sizing: auto", i.e. the app automatically chooses an "opsz" value based on the font size (let’s disregard the question of specific units). </span><br></div><div dir="auto"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></span></div><div dir="auto"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)">3. Let's say the app implements a STAT-based style selection UI, with one drop-down per STAT axis. In this model, it seems that the opsz drop-down, should list Small, Text, Display AND should have an extra entry "Auto" which makes it work like "font-optical-sizing: auto". Do you agree? I think that's reasonable enough. Then, if any of the other opsz entries are chosen, opsz would be frozen at the associated STAT value.</span></div><div dir="auto"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></span></div><div dir="auto"><span style="border-color:rgb(0,0,0);color:rgb(0,0,0)">4. But what should be done in a model that lists fvar instances as styles? Every fvar instance IS tied to some opsz value. So would the recommended UX be that there is some kind of "checkbox" somewhere that basically says "Font size chooses optical size" or something, and THEN choosing the "Small" style vs. the "Display" style would have no visual effect? </span></div></div></div><div><div dir="ltr"><div><br clear="all"><div><br></div>-- <br><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>Adam Twardoch<br></div><div><a href="http://www.twardoch.com/" target="_blank">http://www.twardoch.com/</a></div></div></div></div></div><br><br></div>-- <br><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>Adam Twardoch<br></div><div><a href="http://www.twardoch.com/" target="_blank">http://www.twardoch.com/</a></div></div></div><br><br></blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Adam Twardoch<br></div><div><a href="http://www.twardoch.com/" target="_blank">http://www.twardoch.com/</a></div></div></div>