I’m working on a variable font with two masters with weights from 100 to 900.
I’m exporting these styles:
All works fairly well except when I vary the weight to the max of 900 (testing with FontGoggles) with multiple combing glyphs:
At max the top of the commaabovecomb exceeds the upper extent of what I’m thinking might be called the body height (please let me know the correct metric terminology.)
In the past, with standard fonts, I’ve dealt with this by creating a ccmp for just this glyph combination and reducing the sizes for all the glyphs to fit within constraints.
I’m looking for feedback on other potential ways to solve this problem that are more acceptable. This is the only instance of glyphs that exceed bounds at heavier weights.
I’m probably not understanding the interrelationships between variable fonts and ccmp (or another method). In this specific case the issue is with C+caroncomb+commaabovecomb. Stacking the 900 weight glyphs takes too much vertical space and increasingly clips the top of the commaabovecomb as the weight increases. In the past, with non-VF, I vertically shrank all three components to fit. But, that was for static regular/bold/italic. I thought that by taking the composite character (made up of components) and scaling them to fit (at 900) that VF might interpolate the composite between 100 and 900. It appears my assumption is wrong as the ccmp doesn’t seem to kick in with FontGoggles when I change the weight. Or, I have something wrong with either the composite or ccmp.
lookup SUB_5 {
sub C caroncomb commaabovecomb by C_caroncomb_commaabovecomb;
sub c caroncomb commaabovecomb by c_caroncomb_commaabovecomb;
} SUB_5;
If I took the 900 weight C and shrank it, then it would look abnormal when used without the 2 stacked glyphs. I’m assuming there is a more elegant way to address this problem.
I thought about a slightly different solution after re-reading the VF doc on switching shapes. I created a new glyph called C.bold where I reduced the vertical height of C appx 75% for both masters. I then replaced the components in C_caroncomb_commaabovecomb with the new C.bold glyph, caroncomb and commaabovecomb. My ccmp remained the same. The results varied across apps. In Pages the line height was auto-adjusted to accommodate the C+caroncomb+commaabovecomb, but it appears the ccmp was not used as the C height was static. The issue with this presentation is that line spacing can vary widely on the page depending upon the fonts and weight used.
Next I tried Word. Word seemed to recognize the ccmp, and render the reduced size C, but the caroncomb didn’t seem to anchor properly to the C (or use the relative positioning in the composite), resulting in extra space between. The caroncomb and commaabovecomb were clipped as line height was not expanded (as with pages).
Mellel showed about the same results as word, but the caroncomb and commaabovecomb were not clipped.
In Photoshop the results were similar to pages. The line height was expanded to accommodate all three glyphs, but it also didn’t seem to implement ccmp as the C was not reduced in size.
I’m assuming there are some principles I’m not understanding, or I’ve made a mistake, with variable fonts. Any feedback is appreciated.
Either do a caroncomb_commaabovecomb, the necessary ccmp can be automated. Perhaps in a secondary lookup, you could also substitute for a C.low with adjusted anchors and all, like: sub C' caroncomb_commaabovecomb by C.low; and the combined effect could lower the overall height.
Or adjust the vertical metrics so that the first baseline offset is big enough for the full shape.
Don’t take Adobe apps for the gold standard. They are not. If it works as expected sim a browser or FontGoggles, it is most likely an Adobe bug. If you need to make it work desperately in those apps, consider calling the lookups in other features that are actually supported by the apps. YMMV.
Thanks for the suggestions. The users use Mac Word/Mellel first and InDesign second. What I’ve found with Word is it seems to render C+caroncomb as Ccaron without any ccmp. However, for a C+caroncomb+commaabovecomb it does not appear to auto-render the Ccaron first, it simply uses a C. To get it all to work in Word, I needed to modify the Ccaron glyph to use a reduced size C with the added caroncomb. Then I added the following ccmp.
lookup SUB_1 {
sub C caroncomb by Ccaron;
sub Ccaron commaabovecomb by C_caroncomb_commaabovecomb;
} SUB_1;
That rendered okay, but with a clipped top. So I took your suggestion and increased the hheaAscender to accommodate the full composite glyph. Seems to look fine in Word now. In FontGoggles I need to adjust the baseline parameter to show the full glyph.
I’ll try the other suggestion to see how Word treats the ccmp.
One question I have is feature automation with ccmp. I think I’ve adhered to the correct glyph naming conventions, but ccmp doesn’t autogenerate. Like it does with other features. Is auto supported with ccmp or am I missing something?
Cannot reproduce. Works for me in Glyphs 3.1.1 (3141): I added the three glyphs caroncomb commaabovecomb caroncomb_commaabovecomb to the font, updated features, and it produced:
lookup ccmp_Other_1 {
lookupflag 0;
sub caroncomb commaabovecomb by caroncomb_commaabovecomb;
} ccmp_Other_1;
Thanks for the hint. I forgot to set updates to cutting edge. I installed the same version and now an update is showing. I used the auto code and added an additional lookup to deal with compatibility between all the apps. Seems to work now. My original version didn’t have the lookup 0 statement. I’ve read through prior posts and still trying to understand its use/impact. Both Ccaron and C_caroncomb_commaabovecomb use the C.low reduced height glyph.
Thanks for the help!
lookup ccmp_Other_2 {
lookupflag 0;
sub caroncomb commaabovecomb by caroncomb_commaabovecomb;
} ccmp_Other_2;
lookup ccmp_Other_3 {
sub C caroncomb_commaabovecomb by C_caroncomb_commaabovecomb;
sub C caroncomb by Ccaron;
} ccmp_Other_3;
