Small caps as a variable font axis in Glyphs?

jeremy tribby

Does anyone know how to add small caps as an axis in the GX file produced by Glyphs? There's a font superfamily I'm working on (Barlow - https://tribby.com/projects/barlow) and I'd like to keep small caps in the same VF file

Georg Seifert

You mean that you can 'scale' down the uppercase to look like small caps. Usually, small caps are accessed by an Opentype feature and that is still true in variation fonts.

AbrahamLee

I'm not even sure what a small caps axis would look like...

Mark Simonson

I suppose you could use it to vary the height of the small caps, for example going from the x-height to nearly as tall as the caps. You'd still have to implement them using the {smcp} feature.

Jens Kutilek

I guess you could add an axis with two non-interpolating ranges: 1st range lowercase, 2nd range small caps in place of lowercase. That way you could swap LC against SC without using an OT feature.

It should be possible by the OT spec, not sure if it makes sense, or if its possible in Glyphs.

Hrant Հրանդ Փափազեան Papazian

Axes that are actually just toggles will be needed.

AbrahamLee

Hrant H. Papazian said:

Axes that are actually just toggles will be needed.

This could be used when switching between the standard style and a more decorative style. On that thought, would it be reasonable for such a function to be used for switching between sans/serif variants of a font super family so that everything could really be contained within a single file?

Hrant Հրանդ Փափազեան Papazian

People have proposed that sort of thing for bundling Roman and Italic; your suggestion is even more dramatic. It certainly sounds convenient, I just don't know how much trickier that would make production, and whether file/download sizes would become an issue.

I was thinking of less dramatic things, like having a monospaced option built in.

Georg Seifert

Aren’t ‘switching axis’ called stylistic sets?

jeremy tribby

But doesn't a stylistic set switch between glyphs, not interpolate between them? Can a stylistic set include interpolation or any kind of scaling? What I am imagining is a GX file that can take information from my existing four masters, along with some metadata about my desired scale and maybe vertical interpolation, and be able to render smallcaps without adding masters (all with the goal of keeping the GX file size as small as possible)

Georg Seifert

I thought they where asking for not interpolating 'switch' axis.

Adam Twardoch

IMO, variation fonts should be extended to allow "variation composites" (kind of like the Glyphs smart components, but native to the font format). One might still need separate glyph ids for small cap or superscript glyphs because one wants to define kerning against the base glyphs. But it also might be possible to avoid that. 

But if your font has an alphanumerical set of glyphs with thr "opsz" (optical size) axis, or, when lacking, with the "wght" and "wdth" axes, then your font has everything to produce optical size variations of the appropriate glyphs. 

And small caps or superscript/subscript glyphs are nothing else than pre-scaled smaller-size variants of some already  existing glyphs. 

If I have the letters or figures with the "opsz" or "wght+wdth" axes, then, as a user, I can choose a smaller optical size or a slightly bolder and wider variation, and then use a smaller point size -- and I get small caps. With an even smaller size (both point and variation), I get the forms for superscripts and subscripts, which I then need to shift up or down. I can do it already via CSS, but I have to manually probe the right axis values, downscaling factors and possibly letterspacing. 

The OT Variation mechanism should support this natively, so the relation on the axes, the downscaling factors and the up/down shifting can be predefined in the font. This should be hooked up into an extended feature selection mechanism, thus eliminating the need for the user's trial-and-error. 

For 99% of the fonts, it doesn't make sense to do this differently (i.e. draw your small caps or superscripts differently than what results from the optical size variation).

Ideally, this should be done without the need to use separate glyph ids. Then, something like superscript and subscript could be achieved for *all* glyphs correctly, without ever the need to duplicate them. What remains is kerning, for which the current GPOS mechanism is indeed inefficient.

But we do have the staircase kerning in OpenType, currently limited to the MATH table. If that mechanism were allowed for general use, it'd solve most problems as well. 

Adam Twardoch

Another thing that should be added is meta-axes. As a font maker, if I draw my "wght" and "wdth" axes, I should have the possibility to define an "opsz" meta-axis that just uses different combinations of "wdth" and "wght", without the need to draw those variations explicitly. That would work for most sanserif fonts, for example. And I could add a "cont" (contrast) axis, and define the "opsz" meta-axis as one that traverses the right combinations of "wght+wdth+cont". 

Of course I could still draw an "opsz" axis explicitly if I so choose. 

Kent Lew

What I am imagining is a GX file that can take information from my existing four masters, along with some metadata about my desired scale and maybe vertical interpolation, and be able to render smallcaps without adding masters

I have been thinking for some time that this sort of facility would have been a smart addition to the OT Font Variations specification: Basically the ability to point a GSUB rule to a position within the interpolation matrix rather than just a separate glyph outline. For things like small caps and superiors/inferiors, as Jeremy and Adam point out.

Perhaps in version 2.0.

Deleted Account

Adam has left the reservation, meta axis are proposed in Amstelvar, and they have been smacked in da head with an OS2x4. Making by mixing mixed axis like width, weight and optical size gets you to a dead end with a nice view. Referring to other sizes of a font is not possible within a variation.

But Mr. Tribby is almost there. Having the variable height inside the variable font, makes small caps possible, along with truer optical sizing, (where the baseline shifts down for taller uppercase bodies at smaller sizes), better matching capabilities to international scripts via Latin with flexible body sizing on the em, caps and lower case that can be the same height, any height, and of course, small caps.

You stay on the reservation when this is all accessible from somewhere else in the same variation space and size as everything else, and then gsub. As a bonus this also addresses one of the oldest bugaboos of typography among users, captured in the question "Why are fonts different sizes at the same size?"

Such a variation font can take on the same height as any other font at any given size. As a double bonus every single font now existing in the opentype format has the information inside of it already if you need to match it, in the vertical metrics.

Of course the interesting data compression thing about this, is that all you are adding is a "vertical transparency axis" to some glyphs, not a lot of space is used for all the glyphs you get out of that, if those glyphs and alignment functions are what the font needs. I don't mean to suggest this method should be mandatory for all fonts in the future. On the other hand however, some system fonts should have never left home without it.

So, separate opaque and transparent axes, for x and y, as demonstrated in Amstelvar, attack this issue with pleasant vengeance. I have no idea how to do this in Glyphs, but I am sure it's no less possible. 

jeremy tribby

After reading so many comments on different ideas about what a small caps axis could even be, I think what I want is a function with some axes, not an axis. Essentially I want VF spec to allow X.sc to point to a function, where an original glyph is being copied, and applied changes to vertical/horizontal interpolation, height, and width --  pseduo-CSS would be something like font-style: smallcaps(20,40,70%,90%) or whatever. Rather than copying and pasting a glyph, decomposing it, running it through RMX tools to do the scaling, exporting as new glyph adding to GX file size.

Dave Crossland

Jeremy, please take a close look at Amstelvar. I'm happy to walk you through it on a Google Hangout sometime

Adam Twardoch

I’ll point out that today, OpenType Font Variations work on the notion that each dynamically created instance is a separate “font” in terms of the text layout process. When text layout is performed, the input text is split (itemized) into “runs” which have the same “font”, size, script, languagesystem and writing direction. I’ve described it in more detail in http://typedrawers.com/discussion/comment/28084/#Comment_28084 

This is important because during text layout, there is no interaction (especially: positioning interaction) between different runs. So if you use a small-caps variation axis, and you type in “Tᴇʟꜱ” (this is faked using Unicode characters, but the point is that “T” is an uppercase letter and then “ᴇʟꜱ” would be uppercase letters scaled and sized down via the hypothetical small-caps axis), there is no way to get kerning in the “Tᴇ” pair, because those two glyphs belong to different runs. This is already a limitation in static fonts between different Unicode scripts, but with variable fonts, the limitation is even larger, because conceptually, there is no way to specify the amount of kerning that would be applied between glyphs coming from different dynamic instances of a font. 

How would you express such a thing? I mean, you wouldn’t have a kerning pair between “TE”, and you wouldn’t have a kerning pair between “ᴛᴇ” either, so there wouldn’t even be anything to “interpolate”. 

The only implemented solution that can work around these kinds of situations is the “MATH” table staircase kerning (but that’s only used within the math layout, and it’s hard to tell whether it’s viable for general use).

In the other thread I’ve mentioned above, I’ve written how the current GPOS model is completely inadequate for scenarios when you try to mix dynamic instances of a variable font. And this limitation cannot be overcome by some simple “fix” or some small extension to the current model — see the “TE” kerning problem I’ve just outlined. 

Deleted Account

Building on what Dave said, we added a y transparent uppercase axis to Amstelvar, meaning, the caps have full adjustability of height down to the lower case x height, with another axis that extends the cap height almost to the bottom of the em.

Combined with Full adjustability to the width, weight, and contrast, this y transparent axis gives us the ability to define instances within the space that fulfill the design requirements for all the features of a stylistic instance that contain uppercase congruent contours.

Small caps do not have to be done this way, someone else can just make an axis where weight height contrast and width does everything from caps to small caps in one axis. But blended and combined from these other axes, y transparent u.c. enables the blending and instancing of not only features, but for instances to use with other scripts, with the Latin being the modified script.

We did is this to demonstrate our interest, and the interest of others as was expressed in Berlin, to better use all that design space, and hopefully to get beyond what Adam points out where the OS have the runs. Registering axes where instances represent change to a glyph's opentype feature, or change to a Unicode glyph ID, is what we are proposing to use.

Amstelvar demonstrates feature axis with "magic figures" and with the uppercase I described above, and now that the phases of the moon are Unicode, Zycon has demonstrated the changes to the unicode along an axis for darn near 25 years.

John Hudson

...now that the phases of the moon are Unicode, Zycon has demonstrated the changes to the unicode along an axis for darn near 25 years.

Well, no. Addition of static moon phases — or clock faces — to Unicode actually complicates glyph display of temporal change, precisely because doing clever things at the glyph level doesn't change the underlying character.

Registering axes where instances represent change to a glyph's opentype feature, or change to a Unicode glyph ID, is what we are proposing to use.

Not sure what you mean by 'Unicode glyph ID'. Unicode deals only in characters. OT variations (and OTL) deal only in glyphs. There's only one interface between the two realms, and that's the cmap table.

An awful lot of software and standards rests on this division. Changing encoding from one Unicode to another is something that has to happen at the text level. Not only is it not possible in the glyph processing space of a font, it's something that software makers would consider a security issue because of the phishing potential whenever an underlying character code is represented by a glyph that looks like a different character. [This is one of the reasons why the 'diphthong' OTL feature was deprecated.]

Also not sure what you mean by 'change to a glyph's opentype feature'. Do you mean using GSUB to substitute different glyphs at discrete locations or ranges along an axis (that's possible in the GSUB-variations interaction model in the OT spec)? Or do you mean actually switching between different OTL features along an axis (that's not possible, although I suspect a functional equivalent could be implemented within the existing model).

Deleted Account

"...security issue because of the phishing potential..."

I never in my wildest imagination hoped to achieve so much. If it becomes a problem for our solution, I'll let you know.

I presented the phases of the moon problem to several people. Their suggestions basically center on making duplicate versions of the glyph and redefining the default in each glyph to the different glyph IDs the axis contains, until all the glyphs in the variable glyph, yawn... have their own axis, So, make multiple repeating axes where nothing changes except the default. 

Applying that solution to an entire case, is a different matter, shrinking rapidly from functional equivalence for the user, and worse. That is, keeping in mind that both the discrete phases of the moon, and the names we have for caps of different sizes are artificial boundaries that only count a little, and only for a little while longer.;)

So, I have an answer for Jeremy, as thankfully there's only one interface between the two realms, starting with tools and ending with products that rely on programmable variable Unicode and variable feature axes. That functionality is required in our tools, our fonts, our format, and in web applications, besides keeping down the file sizes and complexity of certain fonts. 

If you have an opportunity to present an alternate solution suite, for intra-style, on-the-fly, variable glyph and feature solutions, in addition to any way for glyphs in the variation space to build glyphs outside their style, please share. 

In any case, the y transparent cap height stands at the top of this slippery slope. That parameter (sCapHeight, e.g.), is in the specification of existing OT and TT fonts. Do you think that should be a registered axis or not?

Thanks.

John Hudson

In any case, the y transparent cap height stands at the top of this slippery slope. That parameter (sCapHeight, e.g.), is in the specification of existing OT and TT fonts. Do you think that should be a registered axis or not? 

Sure, in the same way that x-height, ascender height and descender depth will likely end up getting registered, and all of these have fairly obvious scale values related to 1000th of em, so will be relatively easy to define.

When I start thinking about all these featural aspects of letterforms that could have independent registered axes, though, I am struck that so far its all very Latin-centric, perpetuating the thinking that results in sCapHeight being a format standard data point while, e.g. Devanagari head line height is not. One solution would be to register structural adjustment axes for every writing system (or for groups of similar writing systems). Another solution is to try to define some higher level, generalised axes that apply across writing systems (in the way that weight, width, and optical size do — even if the way in which those axes apply to different scripts varies in design practice). The attraction of the latter approach is that we don't end up putting functionality into silos (as happened with OpenType Layout, such that some features are only accessible for certain scripts).

_____

As to the rest: it always takes me a while to understand what it is you're trying to do — a process that usually involves sitting down with you and talking it through —, so I'm far from sharing alternate solutions. I'm just mindful of interoperability and maintaining the character/glyph distinction. And maybe you are too: it's hard to tell from what you've written here, because e.g. 'Unicode glyph ID' doesn't mean anything to me.

Nick Shinn

Small-cap height should vary against lower case x-height, as default behaviour.

In other words, if a user changes the lower case x-height, then the small cap height should vary accordingly.

That’s because the main use of small caps is in contrast to lower case, in mixed-case settings, and this relationship is very sweet, as determined by the type designer.

However, if changing small-cap height were to affect lower case x-height, that would be problematic. 

John Hudson

In other words, if a user changes the lower case x-height, then the small cap height should vary accordingly.
...
However, if changing small-cap height were to affect lower case x-height, that would be problematic. 

Nick raises what's already becoming an issue with regard to axis interaction: how will a font behave — and, for that matter, how should a variable font UI behave — if two separate axes affect glyphs in similar and possibly interdependent ways? In Nick's example, it is easy enough to conceive how an x-height axis could also affect smallcap glyphs, but less easy to figure out what should happen if the font also contains a smallcap height axis, i.e. if the font contains two axes both of which affect the smallcap height. This isn't simply an issue of determining what should happen once the user or a programmatic function starts adjusting along these axes, but also of determining what can happen, given the particular mathematics used in OT variation space.

I ran into these issues recently while trying to figure out — following discussions with David in Berlin — how to define a parametric weight axis that would use a per mille of em scale instead of the CSS/OS2 weight class scale of the existing registered 'wght' axis. There's an implied interdependence between those two axes if they both exist in a font, since changing weight on one axis produces a weight change that also corresponds to a movement on the other axis: a movement that has not actually been made. The likely solution to this, as to a number of other things in variable fonts, seems to be meta-axes. In this case, having a single weight adjustment axis within the glyph design space, with separate meta-axes to address that axis using different scales. There remains the question of how a UI should present this and what kind of responsive feedback it should provide to interdependent meta-axes, but at least the mathematics of transformations within the glyph space remain tidy.

At this rate, we're going to end up with three levels of axes: meta-axes, design space axes, and composite axes.

Deleted Account

Not sure what you mean. The TJRY axis may trajectorize us to multiple levels and flags for axes, which i'm sure users and applications would appreciate in the specification immensely. Documentation of levels and flags, along with that of each registered axis, should help clarify some of the mysteries of vars, if read. 

On the RATE axis, however, we have 440,000 years, at this pace, before we run out of axes.

This, "However, if changing small-cap height were to affect lower case x-height, that would be problematic."

i'm not sure why this is a problem. In its purely theoretical variable state, Latin uppercase has a positive indescrete height range from 0 to the top of the em, and a negative indiscreet depth range from 0 to however deep a reflected version of the caps may descend negatively. 

We have named one instance in this range as Small Caps, whose alignments by definition, are optically related to the height of the lowercase, and importantly, its alignments relate to nothing else. As type developers, it's our job to make the optical decision of what the lowercase and smallcaps should look like at each width and weight they are included with, and if we really want that relationship to work, we also make the decisions about the small cap parameters based on size of use. Small caps  are notoriously finicky about this.

Either way, the type developer makes the variable font, in our scenario, with a per style and size instance identified by feature tag, and when the user asks for small caps, they get the right thing for the current l.c., if they want something else in the spectrum of cap alignments, they specify a different feature tag, or a per Mille linked percentage of any of the existing tagged features in the axis, and... this does not effect the small caps/l.c. relationship. 

This leaves the user free to change the feature tag if they don't want to use small caps but doesn't really allow for the user to redefine the typographic feature the type designer has defined. Is that what users want?

Nick Shinn

i'm not sure why this is a problem. 

The scenario I imagined: a user wants small caps larger, relative to lower case x-height, to make acronyms such as “USA” more distinct in mixed case setting, but this action only makes the lower case x-height larger too, because the type designer has fixed the ratio between the two.

No, as you so nicely described it, it’s not a problem to make the relationship asymmetric.

Is that what users want?

More pertinently, is it what they expect?
And also, does it make the GUI overly complex?

The best way to decide these issues, as hands-on folk rather than theorists, is to try them out, which means experimenting with different designs of GUI and perhaps then defining the best as a standard, rather than making the GUI an “end of pipe” add-on, to be implemented willy-nilly by whomever. After all, consider how the OpenType feature controls in various applications are a dog’s breakfast with no consistency, which is not what users (or type designers) want.



 

Deleted Account

Nick: "The best way to decide these issues, as hands-on folk rather than theorists, is to try them out..."

Be bold.

Your example though, seems to use a "small cap" for lowercase substitution in mixed use, and a "small cap" substitution for uppercase, in acronym use, to create an imagined scenario where the adjustment of the small caps for that second use would effect the lowercase ht?

I'm not sure what variation issues lurk there, but if you want to call them both "small caps", no Ui, or axis is going to save your user. 

Nick Shinn

Yes, acronyms was a bad example.

A better example would be the first few words in a paragraph.