dberlow
commented
4 years ago Dave,
Our 2016 demo glyphs or Chinese were executed exactly as we agreed, and as far as I’m concerned, exactly as best suited for showing the possibilities of this tech to Open Minds.
The variations in YTCH and XTCH are separated for uses Chinese have never had in composition, including flexibility in x and y for minor variation between gutters and lines, or major variation to other scripts.
As implemented, glyphs are in, and remain in the center of the em. When the variation is done the glyphs are still in the center. So, the middle from which cjk may be composed, is computable at 1/2 the pt size in x, and 1/2 the pt size in y. Could that be simpler? If I can’t move the baseline in vars, I can’t see how else such a demo could be done?
The base table is ignored by devs, and the y axes cannot under ANY circumstances be registered? So, you want me to do what exactly? Go back to the 2016 Amstelvar and add and document the merger of theses two axes? I’d like to address these anonymous natives first. Sure the two axes can be tied together, but what kind of designer needs that to get it, and how many would think the glyphs are just scaling in the em if it was only presented with XTCH and YTCH blended together...
So these glyphs, imho, are perfect. All that’s missing is the use of either baseline shift, (on the other script in use with Chinese), or use of the base table to shift either the Chinese, the other script it’s matching, or both. If you don’t have a base table is just primary school math.
So, were you explaining this correctly to the natives?
Cheers.
davelab6
When showing the Chinese alignment axes in amstelvar alpha to native designers, the reaction was never positive. It may be that a UI with a "bonding" blend of x and y in lockstep would be better.
However, I understand the equivalent of "x height" in Hanzi/Kanji is "central density" ("zhonggong" in Mandarin)
In the same way that a Latin "true x height" axis would need to be blended, and YTLC is not "truly" scaling the x height because it's isolating the lowercase transparency; a Chinese transparency axis may need to scale from the center rather than the (0,0) origin.
It may also be needed to simply shift the Chinese glyphs up/down, with a "y shift" (YSHF) axis. (This seems similar to the discussion of a TRAK axis, in that one would hope for typesetting engines to provide a way to baseline shift per script in style sheets or character/paragraph styles, perhaps according to unicode ranges or regex, but these are not a widely available as unregistered axis support....)