[varLib instancer] should set up italic style linking as an option

When slicing a VF with ital or slant axis, varLib instancer could set up proper italic style bits + italic angle + caret slope if italic != 0 and if slant != 0. For example with and additional argument like --is-italic followed by an integer for italic angle.

For example when running:
fonttools varLib.instancer "../fonts/variable/Nunito[ital,wght].ttf" ital=1 wght=200:1000 -o "../fonts/variable/Nunito-Italic[wght].ttf"

Then we have to patch this kind of metadata:

for font_path in glob.glob("../fonts/variable/*Italic*.ttf"):
        with open(font_path, "rb") as f:
            print("Fix italic style linking in {}".format(font_path))
            ttFont = TTFont(f)
            ttFont["head"].macStyle = MacStyle.ITALIC
            ttFont["post"].italicAngle = -9
            ttFont["hhea"].caretSlopeRise = 1000
            ttFont["hhea"].caretSlopeRun = 158
            ttFont.save(font_path)

Here's some code to set up some kind of linking:

    # style mapping
    styleMapStyleName = font["name"].getName(2, 3, 1, 0x409).toStr().lower()
    macStyle = []
    if styleMapStyleName == "bold":
        macStyle = [0]
    elif styleMapStyleName == "bold italic":
        macStyle = [0, 1]
    elif styleMapStyleName == "italic":
        macStyle = [1]
    font["head"].macStyle = intListToNum(macStyle, 0, 16)

    selection = font["OS/2"].fsSelection
    selection &= ~(1 << 0)
    selection &= ~(1 << 5)
    selection &= ~(1 << 6)
    if styleMapStyleName == "regular":
        selection |= 1 << 6
    elif styleMapStyleName == "bold":
        selection |= 1 << 5
    elif styleMapStyleName == "italic":
        selection |= 1 << 0
    elif styleMapStyleName == "bold italic":
        selection |= 1 << 0
        selection |= 1 << 5
    font["OS/2"].fsSelection = selection

yeah, I like that.
basically what I suggested to do #1264 (comment) but never got around doing it

PRs welcome!

@RosaWagner

@RosaWagner Can you please test with the latest fontTools release and report what else instancer should be doing?

Fixed with #2673 -- feel free to reopen if not

Hi, sorry I was on holidays.

The PR did fixed the style linking issue but I still see 2 things that would influence user experience:

italic angle is still 0
caretSlopeRise and caretSlopeRun are still 1 and 0 respectively. They can be calculated from the italic angle.

we only set the post.italicAngle for "slnt" axis where the relationship is well defined, but not for "ital". How would you go about setting that for "ital" axis?

fonttools/Lib/fontTools/varLib/__init__.py

Lines 876 to 880 in 455158f

    
           if "slnt" in location and "post" in font: 
        
           	italicAngle = max(-90, min(location["slnt"], 90)) 
        
           	if font["post"].italicAngle != italicAngle: 
        
           		log.info("Setting post.italicAngle = %s", italicAngle) 
        
           		font["post"].italicAngle = italicAngle

caretSlopeRise and caretSlopeRun

I don't think we touch those. Feel free to suggest how this should be updated and/or make a PR, thanks

I use the ital axis in anticipation of slicing, to set up the stat, fvar and name tables correctly from scratch.

If I set up the VF with a slant axis, then the STAT in the output italic is wrong:

'slnt' should be be replaced by an 'ital' axis [0;1], Roman=0, Italic=1, and 0 linked to 1 in Roman.

caretSlopeRise and caretSlopeRun
I don't think we touch those. Feel free to suggest how this should be updated and/or make a PR, thanks

I don't know exactly how to do that, but this is the informations I found to calculate them (the OT spec is now very chatty about it): https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6hhea.html

Coming back to this since we are trying to onboard a font which has a continuous italic axis that we need to slice.

I made 3 test cases that I attach here, and below is the result. I think that caret slope and italic angle should be set in all cases by varLib.instancer. Then it might make sense that the nameID25 and STAT table is not handled by fonttools here.

ITAL = -12

Name

ID25 appends Italic
ID2,17,etc have Italic

Style linking bits

post (italic angle is not 0)
hhea (caret slope is not 1)
head (macstyle is Italic)
OS/2 (fsSelection is Italic)

Design space

only italic instances
no slant/ital slider
ital axis in stat
ital value is 1

ITAL = 1

Name

ID25 appends Italic
ID2,17,etc have Italic

Style linking bits

post (italic angle is not 0)
hhea (caret slope is not 1)
head (macstyle is Italic)
OS/2 (fsSelection is Italic)

Design space

only italic instances
no slant/ital slider
ital axis in stat
ital value is 1

SLANT = -12

Name

ID25 appends Italic
ID2,17,etc have Italic

Style linking bits

post (italic angle is not 0)
hhea (caret slope is not 1)
head (macstyle is Italic)
OS/2 (fsSelection is Italic)

Design space

only italic instances
no slant/ital slider
ital axis in stat instead of slnt
ital value is 1

Test-Slice.zip

sorry for the delay, I thought I had already replied here last week but apparently it got lost (maybe I closed the tab before hitting the green button).

a continuous italic axis

You mean you can have ital=0.5? That's a bit uncommon, I thought ital was meant to be a discrete axis, like a boolean 0 or 1.

I think that caret slope and italic angle should be set in all cases by varLib.instancer

as I said above, we only set the post.italicAngle for "slnt" axis where the relationship is well defined in the OT spec, but not for "ital". A font could arguably be "italic" in style without being slanted, or two fonts be equally considered "italic" while having different slant angles; there's no intrinsic relationship between "ital" and "slnt" other than the one the font designer specifies.
If you are suggesting that we also update the caret slope/rise based on the "slnt" axis then I think we could do that. I suggest you file a separate specific issue for that, as this one is already getting too broad, and already partly addressed (we already set the style linking flags in OS/2 and head table after #2673, but we only do that when --update-font-names option is passed [which in turn requires a full STAT table] and we only consider a font "bold" or "italic" if their subfamily name after instancing contains those particles).

regarding nameID 25 ("Variations PostScript Name Prefix" string), my understanding is that it is optional/cosmetic (to help squeeze long family names) and Adobe's "PostScript Name Generation Algorithm" document explains how to make one up if 25 is missing. I don't think it should be the job of the instancer to update that.

Coming back to ital vs slnt, does your font include both ital and slnt? The interaction between the two axes is a bit complicated, the spec uses these words (emphasis mine):

The Italic axis is distinct from the Slant axis ('slnt'). Fonts may use one or the other, depending on the nature of the design, but should rarely use both. While an italic design often incorporates some slant in the design, use of the Italic axis does not require use of the Slant axis. An italic font should not be characterized in the STAT table as being italic and also having some slant, unless the font family includes multiple italic designs with different amounts of slant.

https://learn.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_ital

You mean you can have ital=0.5? That's a bit uncommon, I thought ital was meant to be a discrete axis, like a boolean 0 or 1.

You are right. My goal is that once separated, a VF with a continuous ital or slant axis has all metadata corrected to be a family with proper Roman/Italic relationship. ITAL=1 is the only scenario where I end up with the 0/1 boolean between Roman and Italic style in STAT.

regarding nameID 25 ("Variations PostScript Name Prefix" string), my understanding is that it is optional/cosmetic (to help squeeze long family names) and Adobe's "PostScript Name Generation Algorithm" document explains how to make one up if 25 is missing. I don't think it should be the job of the instancer to update that.

Indeed. But not having it creates bugs in Indesign. I agree it is not the compiler job to do it, so we will have to patch that with gftools.

(we already set the style linking flags in OS/2 and head table after #2673, but we only do that when --update-font-names option is passed [which in turn requires a full STAT table] and we only consider a font "bold" or "italic" if their subfamily name after instancing contains those particles).

Exactly! This is what I am doing and aiming for. The problem is that for now it doesn't result in a fully functional Italic style. I understand it would be a bit too much for fonttools to also change the STAT for a slant axis (slnt,-12 should become ital,1), it may go against the designer's will. My thoughts would have been to integrate an argument like --is-italic, and if present then boom, changes everything.

Coming back to ital vs slnt, does your font include both ital and slnt?

It would be nice but no, it is too confusing for text editors to do that for now. But I can make a test; then ital would be using STAT format 4, right?

I'll open a new issue for caret.

ITAL=1 is the only scenario where I end up with the 0/1 boolean between Roman and Italic style in STAT.

STAT also has an axis value format that describes a range, maybe you can use that to call Italic anything that is ital>0? Not sure if that would make the instancer behave like you expect as regards setting the italic style linking bits, but I'd think so.

not having it creates bugs in Indesign.

I was dreading that answer... 😓

fonttools to also change the STAT for a slant axis (slnt,-12 should become ital,1)

hm, I'm not sure about that. 🤔

Not sure that foonttools should or not do it, or not sure that the axis should change from slnt to ital once sliced?

If the latter, browser support of slant axis is unsurprisingly very inconsistent, at GF we would need the most conventional boring italic set up possible ^^ If it doesn't make sense at a fonttools level, then we would patch it with gftools. Hence my conclusion, if italic angle and caret can get set up for every scenarios by fonttools, then I know what remains to do at gftools level.

that the axis should change from slnt to ital once sliced?

this

browser support of slant axis is unsurprisingly very inconsistent

I know...

so, you're basically suggesting that when a VF contains slnt axis (but no ital axis), and a user slices it to some abritrary non-default location, that fonttools modifies the STAT table to add an ital design axis that wasn't there to begin with?
I think that is too opinionated for a general purpose tool like ours. I would also be a bit wary of doing this on a regular basis in the downstream tools as a workaround for browsers inconsistent implementation of slnt axis.

My theory is that if a user has a VF with a slant axis or a continuous italic axis, and if that user separates it in two VF Roman/italic on purpose, it means they probably want to give to their own users fully functional Roman and Italic VFs that ensure cross-platform compatibility. Which you started doing with changing the italic angle and the italic style bits.

My real and concrete suggestion is that caret slope and caret run are the only field truly missing —from a non-opinionated pov.
My second suggestion was to apply the same changes (italic angle mostly) to the other scenarios that users tend to follow (the scenario ITAL=-12 is the case I see most). But I get that this is not Spec friendly, and therefore not fonttools' job to care about.

The rest is more a Google Fonts API need, and I was trying to see if it would also make sense to consider them at a fonttools level. I do understand everything you point, and I agree. So I think the best solution here would be to make a "make boring italic" script in gftools ;)

ITAL=-12

doesn't it need to be within 0 and 1?

Yes it should; at least for separated Roman/Italic VFs.
In some cases, continuous ital axis (so 1 VF, not 2) is set up the same as slant (ital=-12 instead slant=-12), or with positive values in (actually most) cases (ital=12 instead of slant=-12). Both are against OT spec.

But not having [nameID 25] creates bugs in Indesign

Is this documented anywhere, and is there a fontbakery check for it?

Is this documented anywhere, and is there a fontbakery check for it?

There are several links and conversation in this issue: googlefonts/gftools#297. Our last testing about this is from this summer 2022, didn't check if CC23 has fixed it yet. Fontbakery's related issue is still opened.

Both are against OT spec.

if that's the case, where are these non-spec compliant ital axes expected to work?

They are not expected to work, but they do in some environments. Indesign is having actually a decent support for ital=12 in term of style linking —for what I tested (in Mac)—, and it works relatively okay in browsers with the variation setting CSS thing. ~~Although Windows won't install the instances listed in the FVAR and will show only default origin if a VF has continuous ital axis (tested this summer).~~

EDIT: Just tested again on Windows 11 (build 22000.1098) and MS Word; continuous axis ital=1 is very well supported. In the case of ITAL=-12, it is now behaving like SLNT=-12; all instances from FVAR (including italics) are installed, but style linking in MS Word is not working (italic instance are displayed in font menu though to avoid faux-italic when using italic button).

@tiroj

yet another instance of

the unintended consequences of font makers working around bugs and of bugs hence become de facto undocumented standards that then can never be fixed

to quote @tiroj from googlefonts/gftools#297 (comment)

Yes it is. Where do you want to go with all the questions? You are not happy with #2613 (comment) ?

I was simply trying to understand what you are doing, to see if I could help. You are free to introduce spec-unfriendly hacks if it floats your boat.

Ah eheh, but it is not what I am doing (except for name ID25) ;)

I add my edits of previous comment here as a small update for people interested.

I just re-tested continuous ital axis where ital has [0-1] range. Windows 11 support is good, also style linking in MS Word is working. Support is also good in Mac and in Adobe Indesign. Spec says "The Italic axis can be used as a variation axis within a variable font, though this is not expected to be common". So I would at least consider continuous axis ITAL=1 as a spec compliant scenario.

Support of slant axis and cases like ital=-12 are still not super well supported everywhere. Like, in Windows all instances get installed, but in Word style linking button is not working (italic instances shows in font menu though, which is quite nice since they are not accessible with the button).

Navigation Menu

Repository navigation

[varLib instancer] should set up italic style linking as an option #2613

ITAL = -12

ITAL = 1

SLANT = -12

Test-Slice.zip

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	if "slnt" in location and "post" in font:
	italicAngle = max(-90, min(location["slnt"], 90))
	if font["post"].italicAngle != italicAngle:
	log.info("Setting post.italicAngle = %s", italicAngle)
	font["post"].italicAngle = italicAngle

[varLib instancer] should set up italic style linking as an option #2613

Description

Activity

madig commented on Jun 23, 2022

anthrotype commented on Jun 23, 2022

madig commented on Jul 12, 2022

anthrotype commented on Jul 18, 2022

RosaWagner commented on Jul 20, 2022

anthrotype commented on Jul 20, 2022

RosaWagner commented on Jul 20, 2022

RosaWagner commented on Nov 10, 2022

ITAL = -12

ITAL = 1

SLANT = -12

Test-Slice.zip

anthrotype commented on Nov 14, 2022

RosaWagner commented on Nov 14, 2022

anthrotype commented on Nov 14, 2022

RosaWagner commented on Nov 14, 2022

anthrotype commented on Nov 14, 2022

anthrotype commented on Nov 14, 2022

RosaWagner commented on Nov 14, 2022

anthrotype commented on Nov 14, 2022

RosaWagner commented on Nov 14, 2022

justvanrossum commented on Nov 14, 2022

RosaWagner commented on Nov 14, 2022

anthrotype commented on Nov 14, 2022

RosaWagner commented on Nov 14, 2022

anthrotype commented on Nov 14, 2022

RosaWagner commented on Nov 14, 2022

anthrotype commented on Nov 14, 2022

RosaWagner commented on Nov 14, 2022

RosaWagner commented on Nov 16, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions