Script applicability for TN's proposed ytas, ytde, ytlc, ytuc axes

[PeterCon]

In the overview doc for the Type Network proposal, the ytas, ytde, ytlc and ytuc axes are described as "four Latin axes [that] apply to glyphs and parts of glyphs specific to the Latin script". But the Script field in the proposal summary for each of those axes states,

Script or language considerations: Can be used for all scripts.

Using ytas as an example, perhaps a better statement for that axis might be along these lines:

Script or language considerations: This axis is primarily intended for Latin
script and other similar scripts that have ascender elements, but may also be
used with other scripts.

Typically, this would apply to bicameral scripts in which lowercase letters
generally have a smaller body height than uppercase letters -- that is, that
have an "x height" distinct from "cap height" -- but also have some lowercase
letters with strokes that ascend above the "x height".

It could also be used for other scripts that have a typical body height for letters
with some letters having strokes that ascend above that height. For example, in
Thai script, most letters have the same body height as ko kay "ก", but some
letters, such as po plaa "ป", have an ascending stroke.

Thoughts?

[tiroj]

Good suggestion. My only concern is with the use of the term 'body height', which has a technical meaning in type as equivalent to the em (inherited from metal type but still in fairly common use). But at the moment I can't think of a better term for what you mean.

[sberlow]

I agree, good suggestion.

[dberlow]

I think it is only good to use the Latin y values for other world scripts if the other world script's alignments are the same as the Latin, and stay that way throughout the variation font's space.

[sberlow]

@dberlow
Here is @PeterCon's suggested revision.

Script or language considerations: This axis is primarily intended for Latin
script and other similar scripts that have ascender elements, but may also be
used with other scripts.

Typically, this would apply to bicameral scripts in which lowercase letters
generally have a smaller body height than uppercase letters -- that is, that
have an "x height" distinct from "cap height" -- but also have some lowercase
letters with strokes that ascend above the "x height".

It could also be used for other scripts that have a typical body height for letters
with some letters having strokes that ascend above that height. For example, in
Thai script, most letters have the same body height as ko kay "ก", but some
letters, such as po plaa "ป", have an ascending stroke.

[dberlow]

I explained what the explanation needs to be, and why. If that is not that explanation, and I think the one given is not, then I would say all y trans, as proposed, should only be used for Latin. This also depends on acceptance of the non-Latin alignments, and discussion of one without the other doesn’t really interest me or our audience nearly as much as a complete framework does.

[davelab6]

This also depends on acceptance of the non-Latin alignments

Those haven't been proposed yet, so they can't have been accepted/denied?

[dberlow]

And...?

…

Sent from my iPad

On Jan 3, 2018, at 12:48 PM, Dave Crossland ***@***.***> wrote: This also depends on acceptance of the non-Latin alignments Those haven't been proposed yet, so they can't have been accepted/denied? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[davelab6]

And...?

Well, if discussion of one without the other doesn’t really interest you compared to a complete framework, and this can't be resolved until a complete framework is available, we better get started on publishing one ;)

However, I don't think that is required. I agree the current text,

Script or language considerations: Can be used for all scripts.

, is not ideal: Not all 8 axes are universal. 4 are to me obviously about the totality of the font's glyphs (ytra) and the other 4 are to me obviously latin specific (those 4 as Peter listed.)

Here then is a proposal that adds your explanation Peter's suggestion:

Script or language considerations: This axis is primarily intended for Latin script and other similar scripts that have ascender elements, but may also be used with other scripts.

Typically, this would apply to bicameral scripts in which lowercase letters generally have a smaller body height than uppercase letters -- that is, that have an "x height" distinct from "cap height" -- but also have some lowercase letters with strokes that ascend above the "x height".

It could also be used for other scripts that have a typical body height for letters with some letters having strokes that ascend above that height, where their alignments are the same as the Latin, and stay that way throughout the variation font's space.

For example, in Thai script, most letters have the same body height as ko kay "ก", but some letters, such as po plaa "ป", have an ascending stroke. These could be designed to be aligned with the Latin "n" x-height and "d" ascender, and stay that way throughout the variation font's space.

I propose that this be added to the ytas, ytde, ytlc and ytuc axes proposals.

[tiroj]

Can I suggest 'core height' instead of 'body height' to avoid overloading the latter term and risking confusion? Core is related to body (corpus), but doesn't have the inherited technical meaning of body in typography. Yes, it's a novel term, but the concept of core as distinct from ascenders or descenders seems pretty intuitive.

[dberlow]

Thanks for your patience.

I have this to offer.

ytas
Script or language considerations: This axis is primarily intended for Latin script and other scripts that may have ascender elements intended to remain aligned relative to the Latin ascenders throughout the variable space.

Typically, this would apply to scripts in which some letters generally have a smaller core height than the ascender that is being aligned with the Latin ascender.

Generally, as axes registration unfolds, scripts needing Latin-independet alignments, will have them registered.

ytde
Script or language considerations: This axis is primarily intended for Latin script and other scripts that may have descender elements intended to remain aligned relative to the Latin descenders throughout the variable space.

Typically, this would apply to scripts in which some letters generally have a core height above the descender being aligned with the Latin descender.

Generally, as axes registration unfolds, scripts needing Latin-independet alignments, will have them registered.

ytlc
Script or language considerations: This axis is primarily intended for Latin script and other scripts that may have a case, or character group intended to remain aligned relative to the Latin lowercase throughout the variable space.

Typically, this would apply to scripts in which some letters generally have a core height the same or close to the Latin lowercase in the font.

Generally, as axes registration unfolds, scripts needing Latin-independet alignments, will have them registered.

ytuc
Script or language considerations: This axis is primarily intended for Latin script and other scripts that may have a case, or character group intended to remain aligned relative to the Latin Uppercase throughout the variable space.

Typically, this would apply to scripts in which some letters generally have a core height the same or close to the Latin Uppercase in the font.

Generally, as axes registration unfolds, scripts needing Latin-independet alignments, will have them registered.

[tiroj]

I think David's concept of linking application of these axes to Latin alignment is reasonable in the absence of any mechanism to differentiate the behaviour of the axes at the script or language system level.

[PeterCon]

Couple of comments:

I would say "variation space" rather than "variable space".

I don't think the description of one tag in the registry should make any predictions about future registrations. So, I would leave out the last paragraph:

Generally, as axes registration unfolds, scripts needing Latin-independet alignments, will have them registered.

Otherwise OK.

[davelab6]

How about,

In future, we may see proposals for registering similar axes for scripts needing Latin-independent alignments.

[PeterCon]

No. For the same reason that I wouldn't want the description for 'wght' to say something like, "In the future, there may be a registration for a "grade" axis that is like weight but never affecting glyph advance widths." If it is felt that an axis is primarily intended for Latin, then it should be sufficient to just say that.

(But I still wonder: couldn't these axes be used in, say, a Cyrillic-only font that doesn't have any Latins?)

[tiroj]

I agree that the line about future possibilities doesn't belong in the registered axis description, but something about this could be included in the preamble information for the proposal, so that reviewers can understand what the current proposed axes cover and do not.

(But I still wonder: couldn't these axes be used in, say, a Cyrillic-only font that doesn't have any Latins?)

Yes, although David's wording does say 'Latin script or other scripts'. Maybe 'European bicameral scripts'? That covers Latin, Cyrillic, Greek, and at least some styles of Armenian and Georgian.

[PeterCon]

Certainly, including that in the Overview.md or in the Overview field of the General Technical Information section of individual proposal summary forms would be reasonable and useful: those are intended for providing background info useful for reviewers of the proposal that wouldn't belong in the registry documentation (if an axis ends up being registered).

[dberlow]

John,

"... so that reviewers can understand what the current proposed axes cover and do not."

I agree with the sentiment, but I think the best way to do that is to Register xopq and xtra for all scripts, right now, and ytlc for Latin and Co., thrashed out to the last jot, as those are agreed by all to be the sources of wght and wdth. Then, leverage those documented definitions to unambiguously define wght and wdth across all scripts.

Then. people might not only understand what the current proposed axes cover and do no, but also set the stage for a framework people understand too.

thanks

[tiroj]

Register xopq and xtra for all scripts, right now

To clarify: you mean register just these two axes, and have them apply to all scripts, right? i.e. not register individual x-opaque and x-transparent axes for each script?

[dberlow]

Once for all, yes. I mean register just these two axes once.

…

On Fri, Jan 5, 2018 at 1:43 PM, John Hudson ***@***.***> wrote: Register xopq and xtra for all scripts, right now To clarify: you mean register just these two axes, and have them apply to all scripts, right? i.e. not register individual x-opaque and x-transparent axes for each script? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB3ajilSLSR4yg0iN-LjN9gagjr2ZsVZks5tHm1UgaJpZM4RI0w4> .

[tiroj]

Okay, we're on the same page. Now just thrashing out to the last jot.