It looks like you're new here. Sign in or register to get started.
Mark Simonson said:
I wonder if a numeric input field without a slider might be a better UI for variable fonts.
Dave Crossland said:
That's what https://typetools.typenetwork.com offers
María Ramos said:
I mean the type designer should be able to define how long the steps should be in each variable font. In your example the step would be 50 units, so for every 50 units, there is a font variant the user can choose. The step could be 30 units or less if the design space allows for more fine-tuning.
My original question was something like... why do we have 800 units (possible chosen variants) in a variable font (weight axis range 100–900) when more than 500 of them do not show any noticeable difference to the user?
Simon Cozens said:In a variable font, there are infinite options for the font user by default; you are talking about taking them away and restricting them to a smaller subset.
Alex Visi said:#0500FE is indistinguishable from #0500FF, but I haven’t seen anyone asking to ban one of them. Choice (even if it’s so granular you feel it’s “fake”) is never a problem, but restrictions are.
KP Mawhood said:
By way of analogy, 255 variants for each RGB colour is more than sufficient for most use cases, even though it misses the granularity to fully cover ~16.7m colours.
KP Mawhood said:I don't see why smaller iterations (steps of 50) would change the overall degree of variation presented by the slider, which could be accessed in a separate panel (e.g. paragraph style options). Big numbers confuse, that's why we simplify.
Florian Pircher said:Also, 0–255 for each RGB component does fully cover 16.777.216 different colors.
Florian Pircher said: So why impose such a restriction? There is no benefit to the font designer/vendor in limiting what axis positions are accessible by font users. Envisioning potential benefits for font users is a nice thought, but as discussed above, you cannot foresee all possible use cases. There are already use cases, again outlined above (legacy documents, animation …), that suffer from such a restriction.
John Hudson said:if different fonts have different steps, it becomes impossible to specify text and know what you are going to get if you change fonts. So e.g. if text is specified at a weight of 535, that could clip either up or down depending on how a particular font has its idiosyncratic steps defined.
María Ramos said:
... If you change a variable font with specific values to another variable font, the values change and you need to set those again. In desktop apps, I think they change to a default value.
John Hudson said:There are always going to be situations in which less data is more practically useful than more data, and where selectively constraining displayed data is helpful to the user. But the way to do that is to provide better interaction experiences, not to handicap the underlying data.
Peter Constable said:
Maria initially described her concern as variable fonts providing too-fine distinctions most of which are, in practice, not useful distinctions. But I think it's would be better to characterize that as a human user interface issue rather than an issue inherent to the font capability itself. … Is the best thing for those users that a font designer impose (say) 50 unit steps --- one size for all customers? (Btw, that can already be done using an avar table.)
John Hudson said:Think of it like resolution. If the font specifies that a wght axis has 20 discrete steps instead of a near-continuum of fractional values between 1 and 1000, that is a lower resolution. Yes, the underlying data of the default instance and delta sets in the gvar table is the same, but the font is only allowing access to part of that data, rather than to all of it.
John Hudson said:Does requiring ‘advanced users’ to figure out ways around the handicapping of access to the font data make more sense than having better interaction tools to simplify how all users engage with the font data?
John Hudson said:We could have font-specific axis scale resolution, and still have lousy UI for working with variable fonts, and that UI would have to be able to handle juggling fonts with different step values.
María Ramos said:Many questions and doubts when handling units for axis... It just seems there is not enough thought on how to handle this and make variable fonts easier to use and also work better. …The support of variable fonts is still an ongoing process, if we are proposing improvements is better now than later. …Good to create debate around all these things. At least think about it, what are the pros and cons. And I am thinking of the pros and cons for the font user not for us as font developers or software engineers.
Many questions and doubts when handling units for axis... It just seems there is not enough thought on how to handle this and make variable fonts easier to use and also work better.
The support of variable fonts is still an ongoing process, if we are proposing improvements is better now than later.
Florian Pircher said:An advanced user mode is an issue for the same reason: Once an advanced user touches a document, all other users must be able to see and edit the same document in their simplified interface, but that is not possible.
Dave Crossland said:
If stepped avars became common, I'm sure that user tools to redefine avar data on the fly would become common too.
KP Mawhood said:How did the team decide on the variants for each axes (e.g. 25–135 for thin stroke)?
John Hudson said:Except the masters don’t actually exist in an OT variable font, other than the default instance outlines.
…rather a management of influence to achieve details elsewhere.