-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Script applicability for TN's proposed ytas, ytde, ytlc, ytuc axes #24
Comments
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. |
I agree, good suggestion. |
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. |
@dberlow Script or language considerations: This axis is primarily intended for Latin Typically, this would apply to bicameral scripts in which lowercase letters It could also be used for other scripts that have a typical body height for letters |
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.
|
Those haven't been proposed yet, so they can't have been accepted/denied? |
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.
|
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,
, 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:
I propose that this be added to the ytas, ytde, ytlc and ytuc axes proposals. |
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. |
Thanks for your patience. I have this to offer. ytas 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 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 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 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. |
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. |
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:
Otherwise OK. |
How about,
|
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?) |
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.
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. |
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). |
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 |
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? |
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>
.
|
Okay, we're on the same page. Now just thrashing out to the last jot. |
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,
Using ytas as an example, perhaps a better statement for that axis might be along these lines:
Thoughts?
The text was updated successfully, but these errors were encountered: