Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

D. Epar ted

About

Username
D. Epar ted
Joined
Visits
2,773
Last Active
Roles
Member, Type Person
Points
604
Invited by
Admin James Puckett
Posts
719
  • Re: Plex; IBM's new font identity model

    I’d like to commend all of the designers and developers of this font for a bunch of stuff, but raising the corporate bar to include serifs, is all that’s possible under the circumstances. Thanks!
  • Re: Specific diacritic designs depending on language

    That’s all great but the infrastructure of line layout and variables were intended to be implemented together, not Separated by 25 years and artificial barriers of the technologies that grew in between. So it’s always interesting to see what’s going wrong just because of the past politics, and how little has changed in “round two.”

    In any case, if the system cannot deal with the indescrete nature of some typography, it can hardly be considered “whole”, and even if I can only do something with JavaScript, if it is based on axes that help users to better typography, then it must be more wholesome than doing nothing.
  • Re: [OTVar] Changing tracking/HVAR

    John’s points touch on an interesting set of issues related to but not of VUID and VOTF. Variable components are one issue. We’ve provided an example of that in Decovar. There are two sets of masters because of the disconnect we think there is between nested variable components and variable glyphs. I’m not sure John’s proposal to change the font format will solve that, but because it is common enough, and John isn’t, I just assume so. By common enough, I think a lot of people recognize the need to build glyphs from variable components, and by uncommon enough, Johns experience in this is great.

    It’s importent to write though, that our Google Font projects were not focused back on these issues yet. Nor was our proposal scoped to allow any request for change to the font format. Just the fundamental axes we thought obviously need to be added. These were specified, in some cases, to make the need for format change, or at least further discussion, more obvious. The Overhanging obviousness we are heading to, is that there needs to be little, or better, no difference, between the font format and the design format. As that is something that could take years, we do what we can, now.

    So, we agree that the assembly of glyphs from variation space is one issue. Having discovered for ourselves in Decovar, the variable component side of things, and more, we also stand by all of the proposal and I expect that later change to the format will make some of it much more clear. Ahead of that clarity, we think, demonstrate and progress on our need to go into variation space for parts, and for whole glyphs. So, I’m not sure why one thing there would be Important Enough to change the font format while the other thing there is Not Important Enough to register as an axis.
  • Re: A List Apart considers user interfaces for variable fonts

    Peter:;“E.g., one could imagine a font that doesn't have an optical size axis, but does have contrast, x-height,....”

    It’s been demonstrated. Those is are not registered axes though, so forget mixing, much less saving a user’s opsz. And without the selection mantra officially registered either, good luck with Ui intelligence. Most users also understand primary and secondary colors, and colors are easier to sample and compare than type, because they are not defined relatively by the artist or color company, like the current OT spec mostly ignores actual typographic parameters. In addition, color does not get bent out of shape by OS and apps making up their own laws to govern its appearance, or by their adoption of rendering that makes some colors easy, and other colors nearly impossible to use.

    You are probably right though, all this has to be done, done Right, and not just for Latin colors. Good luck!
  • Re: [OTVar] Axes Proposals: variationsguide.typenetwork.com

    Peter,

    Well, I thought about it, when I gave yopq negative values. Because it is y stem weight that makes counters flip vertically, I didn’t give ytra a negative range. Could be wrong, easy to fix.