Scripting: Kerning doesn't appear to work properly with character range queries

[Paul Tuersley]

Either I'm missing something or Kerning doesn't appear to work properly with character range queries. It mostly seems to return undefined, even for a character range of a single character.

It's potentially important to check if kerning has been manually altered to be able to take steps to preserve that kerning during a scripted edit. autoKernType seems to work as expected, only returning undefined on mixed autoKernTypes in a single text layer, it's just kerning that does. Makes it impossible to query in any useful way.

1. Create a comp, a text layer with some text, set to Metrics. Run attached kerntest script and you get:

autoKern all = Metrics first char = Metrics
kerning all = undefined first char = undefined

Kerning should be returning 0 in both cases (the scripting docs say so too)

2. Use Character panel to set Kerning to 0. Run script:

autoKern all = None first char = None
kerning all = undefined first char = undefined

Kerning should be returning 0 in both cases.

3. Click between two later characters on the text layer and set Kerning pulldown to 100. Run script:

autoKern all = None first char = None
kerning all = 100 first char = undefined

Again seems wrong. Why is full char range returning 100?
All should be returning undefined, and first char should return 0.
Only that later char will return the kerning value you just set.

4. Set text back to Metrics, click between two later characters and set Kerning to 100. Run script:

autoKern all = Metrics first char = Metrics
kerning all = undefined first char = undefined

Kerning should be returning same as in Step 3. All is undefined, first is 0, only the later char returns its altered value.

[Douglas_Waterfall]

@Paul Tuersley Ah, yes kerning. That is super, super annoying.

There was a disagreement on how we should document the CharacterRange properties (and also at the time with ParagraphRange) and so simplicity won out but at the cost of difference relative to the TextDocument not being properly communicated. kerning is one of those differences.

The CharacterRange in my design goes to great lengths not to lie about anything - so I used undefined a lot when there is no value to be provided. For example, think about mixed attributes - is it 12pts or 24pts? With the TextDocument, which only looks at the first character of the TextLayer, it never has a mixed problem. But CharacterRange does - which is why in this example it would return undefined to indicate mixed.

Before CharacterRange/ParagraphRange the one exception to this was Paragraph Justification - unlike character attributes, this one attribute actually is calculated across the entire range of the TextLayer, so it does have a mixed problem. The solution prior to my getting involved was to simply add a special value to the enum to indicate mixed: ParagraphJustification.MULTIPLE_JUSTIFICATIONS. Clearly it is a fudge, which could be gotten away with because it was an enum. When I added all the new paragraph attributes they return undefined for mixed, even if they are an enum.

kerning and autoKernType are two intertwined attributes which have this unusual interaction which leads to much confusion.

If autoKernType is set to metric/optical then the kerning attribute is entirely ignored. This why when you ask for the kerning attribute for a character in these cases it returns undefined. If the autoKernType is set to manual, THEN the kerning attibute holds (in effect) the manual kern value (to be stricly correct, the kerning attribute should really be named manualKerning...) Setting the kerning attribute to a value will silently ALSO change the autoKernType to manual.

The underlying text engine which we use takes a bit of a confusing stance on this, for plausible reasons, but does not play well with our understanding as scripters. The UI does a special thing for kerning in that at an insertion point it is setup to report the composer calculated kerning value for the automatic kerning types with respect to the previous character. Due to this same abstraction, if you set the autoKernType when at this insertion point, it sets it on the previous character, not the next character like all other attributes.

Again, for the similar reasons, a character selection is confusing because no calculated kerning can be reported - only with an insertion point.

I considered allowing scripting to report these calculated values but decided that until a TextDocument started composing itself the kerning values returned would be inaccurate if any change was made. Something for the future perhaps.

My feeling is that our UI is very misleading when it comes to kerning, what with sometimes greyed out and other times bright blue, and setting a different character than you actually think you are selecting - it is a problem.

Hope that clears things up a bit for you, the docs should be updated as well to indicate that this variance of behavior.

Douglas Waterfall

After Effects Engineering

[Paul Tuersley]

@Douglas_Waterfall Thanks again for the explanation.

I went back and tested text with a kern value inserted in a single place and looped through doing single characterRange checks.

So it appears any zero kerning value returns undefined, while that one character does report back as 100. So I guess you can check for manual kerning once you understand this quirk.

It still seems odd that a (0,-1) range will report 100 in that case (Step 3 in my bug report). So it's not returning undefined where I might expect, but is where I wouldn't expect (i.e. if kerning on any given char == 0).

As (0,-1) == undefined is a great way to quickly check if dealing with a mixed attribute, kerning is the one thing that utterly fails to play nice with that. You'd have to loop through every character to gather that information if autoKern reports as None or undefined. You'd just never know that if you used the same methodology employed for checking other attributes.

I'm leaning more in favour of always editing text a character at a time anyway, so hopefully that will be able to preserve any existing kerning when editing non-related attributes. My implementation for presenting kerning focuses on autoKernType anyway, just telling the user if a layer has Metrics, Optical or "-" and that still seems pretty reasonable. Trying to factor manual kerning into my presentation of text shown in blocks of matching attributes would just be incomprehensible anyway.