Open davelab6 opened 5 years ago
Dave, The first part of your message is clear. There is a problem with the spec that doesn’t allow the changes in type to be properly recorded in the format, for important typographic functionality based on those changes in type. It can easily be illustrated with extremo, Amstelvar Or any well designed var with an opsz.
The values for weight and width for the stack-op-sizes below, (regardless of Parametric or OStew), cannot be accurately recorded over the range of opsz if they have to be orthogonal. Make no mistake about it, this problem is firmly entrenched in optical size not being understood by the implementarians, going beyond the issues of OS/2 values being "solved" by parametric axes. [image: Screen Shot 2019-02-19 at 4.48.12 AM.png]
I do not believe filing issues regarding shortcomings of the OpenType 1.8.x format can be addressed anymore by anything other than a competing implementation that's more powerful, and loses nothing, i.e. the framework we proposed with an implementation that matches.
The second part, from Eben, is just a matter of taste. I show you above what I think is the proper weight for 144pt with other sizes of the same weight.
Upon what someone bases “intuition” when one's never seen the weight Change of an optical size axis with a 132 point range, is odd.
But, there are sliders and if you or he thinks Extremo should have another weight ramp, I'm all slide-ears. [image: Screen Shot 2019-02-19 at 4.48.29 AM.png] Is this better?
Or this? [image: Screen Shot 2019-02-19 at 4.48.50 AM.png] Cheers!
I'm going to file a few issues regarding shortcomings of the OpenType 1.8.x format that I believe an OpenType 1.9.x format can address.
First up: Parametric Weight is superior to OS/2 Weight, and should be available as "the" weight axis in OT 1.9.
Upon reviewing Roboto Extremo at https://github.com/TypeNetwork/Roboto-Extremo/ commit d7095e2 Eben Sorkin made an off hand comment which testifies to this: