Incorrect behavior when Case-Sensitive Forms are activated

[jameslucas]

Case-Sensitive Forms are an OpenType feature designed to replace some glyphs with alternates when All Caps is applied. (Official description here.) Activating Case-Sensitive Forms (a checkbox in the Capital section of the Typography window) should have no effect except when All Caps is applied, but currently Case-Sensitive Forms is replacing relevant glyphs whenever the feature is activated regardless of case.

In the examples illustrated here, Case-Sensitive Forms include and upward shift of hyphens and parentheses for Abril, Lygia, and Albertan and a switch from oldstyle to lining numerals for Abril and Lygia. All of these behaviors are correct in the right column where All Caps has been applied but incorrect in the left column where case is unchanged. Additionally, activating Case-Sensitive Forms forces capital letters from Lygia. I suspect that there is something different and/or wrong with Lygia’s coding but note that it would likely not matter if Affinity’s handling of Case-Sensitive Forms were correct.

Additional notes

1. The same examples exported from Adobe InDesign 18.0 is included for comparison. As far as I know, it is not possible to turn off Case-Sensitives Forms in that program.
2. This issue to be affecting Publisher v1 as well, but I think it might be a new issue. PDFs I have exported more than a few months ago do not show this unexpected behavior, but I’m having trouble finding definitive evidence that I had Case-Sensitive Forms turned on at that point.
3. Minor nit: ‘Case-Sensitive’ should be hyphenated in the Typography window.

 

Edited November 13, 2022 by jameslucas
InDesign example image had wrong numeral form for Baskerville original, causing potential confusion

[Callum]

Hi JamesLucas,

Please could you confirm if this issue still occurs using our latest 2.0.4 version?

Thanks
C

[jameslucas]

@Callum I regret to report that the problem persists in v 2.0.4.

Thanks for asking—and please don’t hesitate to ask again down the road!

[kenmcd]

On 11/12/2022 at 5:07 PM, jameslucas said:

should have no effect except when All Caps is applied

Nothing in the OpenType spec requires this (that is probably an Adobe decision).
It is designated as a user-controlled feature that the user applies.

And AllCaps does not apply to tabular figures, another common use of case sensitive forms - and the math characters that go with them.

And some advanced fonts have case sensitive forms for small caps.

More advanced fonts will use contextual alternates to intelligently help control when it is applied.

@Callum
I think would be a mistake to mess with this.
Only the user should apply this.
 

[kenmcd]

On 11/12/2022 at 5:07 PM, jameslucas said:

Additionally, activating Case-Sensitive Forms forces capital letters from Lygia. I suspect that there is something different and/or wrong with Lygia’s coding but note that it would likely not matter if Affinity’s handling of Case-Sensitive Forms were correct.

In Lygia the Case Sensitive Forms feature affects the following characters:
- all lowercase characters are converted to uppercase characters
- all small caps characters are converted to uppercase characters
- all old style figures are converted to proportional lining figures characters
- all punctuation is converted to the case sensitive forms

This is clearly the font developer's intent.

[jameslucas]

18 hours ago, kenmcd said:

And AllCaps does not apply to tabular figures, another common use of case sensitive forms - and the math characters that go with them.

And some advanced fonts have case sensitive forms for small caps.

More advanced fonts will use contextual alternates to intelligently help control when it is applied.

@Callum
I think would be a mistake to mess with this.
Only the user should apply this.
 

@kenmcd You make a good point about Small Caps and Contextual Alts. I should not have neglected to mention those as legitmate activation conditions. But isn’t that all the more reason to want to be able to have Case-Sensitive Forms turned on by default (and turned off only as an option of last resort)? Who wants to have to turn C-S Forms on for each and every relevant character style (or worse, turned on manually every time local formatting is applied)? Edit: Ken’s post got me thinking I had missed something, and yeah, apparently Publisher does a decent job of turning on C-S forms in certain circumstances, such as applying all-caps locally. I hadn’t noticed that because I tend to do as much as possible with Text Styles, and there is no such automatic activation there. I don’t think this changes my overall recommendation, but it’s certainly a good thing.

As for the OpenType standards, maybe the language is murky, but the feature name is pretty clear about the behavior that should be expected. This is about making the forms sensitive to case. If the case is mixed, the appropriate forms should be used, and right now Publisher is using the the upper case forms in mixed case settings.

This may be a tangent, but I will note that I think your assertion about tabular forms is faulty. I just tried Arno Pro (chosen for no better reason than being alphabetically the first font with Tabular Oldstyle numerals I have installed) in both Adobe InDesign and Affinity Publisher. All Caps changed it to Tabular Lining, just as I would expect. I don’t doubt that some fonts fail to do this correctly, but I don’t think that’s an argument for not making Publisher work as intuitively as possible.

[kenmcd]

On 11/12/2022 at 5:07 PM, jameslucas said:

Activating Case-Sensitive Forms (a checkbox in the Capital section of the Typography window) should have no effect except when All Caps is applied,

I guess I just disagree with this.
case is a discretionary OpenType feature and it should stay that way.
I really do not want another OpenType feature with forced outcomes.
Users should have control.

Right now I cannot use APub to test a font's small caps features because of the dumb always-on fake small caps obscures any issues (missing or broken substitutions).
So having case be disabled would just be another PITA.

AllCaps is a software developer construction - so I guess they can add to it whatever features make sense to them. I have been going through my head about the possible (bad) interactions with other OpenType features. What if the font has old style figures and nothing else, or both proportional lining and tabular lining as alternates? I guess it would/could pick the next one in the OpenType order, and I guess it should still be switched maually. How will it affect contextual alternates, or ccmp, or rlig, or whatever? Dunno. The fear of unintended consequences.

The idea that the case is turned On automatically with AllCaps is probably a good idea. And probably will help without any side effects for the average user.
But have case only be On when AllCaps is enabled - ahhh... No, thank you.

[jameslucas]

Circling back—I talked to a couple type designers I know, and both said they design their case features with the assumption that software will handle them exactly as Adobe InDesign does. That’s not to say that this is the ideal (we did spend a decade having to write HTML to work with Internet Explorer’s esoteric standards), but it’s worth noting. Anyway, this is clearly an issue of some complexity, so I want to make a few notes for any Affinity folks looking into this.

1. A checkbox that checks and unchecks itself to show that a feature is in use is a really weird UI element. I can’t think of another example in any other software I use. I don’t know why anyone would intuitively know how to use it.
2. It’s not unreasonable to assume that that most users will assume that case works like calt. I.e., being ‘on’ means it’s allowed to work when appropriate, and being ‘off’ means that it’s disabled. It might be more intuitive were this a 3-way choice of ‘default’, ‘on’, and ‘off’, which ‘default’ is something like the current implementation.
3. Case-sensitive features need to be easy and intuitive to use via Text Styles, and currently that is not even remotely the case.

Separately…

On 2/14/2023 at 9:49 PM, kenmcd said:

Right now I cannot use APub to test a font's small caps features because of the dumb always-on fake small caps obscures any issues (missing or broken substitutions).

I think if the small caps are faked, the option its italicized in the Typography menu. I’m not saying that’s sufficient—just noting it in case it helps you, @kenmcd. 🤷

[kenmcd]

@jameslucas I do agree with you that it would be nice if this would all be easy, and consistent, and predictable ... but ...

No doubt many font designers think about how their fonts will work with ID.
Unfortunately some of them only think about that (and do dumb mac-only stuff).
It is good the typical Adopey "Pro" font has a typical set of features (consistency).
Users can expect certain things to be in the Pro vs. the Std fonts.
And this is helpful when creating app features like AllCaps and expecting it to act the same with all fonts.
But all fonts are not the same, and there are many, many different configurations.

Many fonts (most) have no case feature at all.
And those that do have case are all over the place as to what is included.
Some have just the most basic punctuation.
Some have lots of punctuation, lowercase to uppercase, small caps to uppercase, oldstyle figures to lining figures, various symbols shifted, and diacritics shifted, etc.
And all of this (case) has to interact with those features, and calt, and ccmp, etc., etc.

In Adobe Garamond Pro case overrides frac.
In Adobe Source Serif 4 frac overrides case.
How should AllCaps handle this?
A similar common interaction is with calt.
And the issues with case are similar to the issues with calt.
It is very hard to predict, and plan for, every different scenario.
At least once a week someone is posting in GitHub that some font is broken - when it is just calt is just not handling that particular scenario as they expect.
calt is often used to move a hyphen, like case, and the user does not understand why they are at different heights just a few characters away from each other - usually with changing case, and symbols, and figures, and punctuation, etc. in their text.
Answered another of these calt/case issue posts just yesterday (jumping bullets).
And case is the same way.
You cannot predict all the text where it will be used.
And you cannot predict all of the other feature interactions (many).
So you need to be able to control it manually (often to turn it Off).

Creating a case feature is relatively easy.
But calt is programming which can get very complicated fast.
Again, hard to predict all the scenarios.
Good example is the programming fonts like Fira Code, and JetBrains Mono, which have extensive calt code, and the weekly issues posts to go with it.

I like the idea of turning On various features with AllCaps like case.
Agree with you that often this is going to be very helpful.
But the are too many different fonts and different uses out there.
Users also need to be able to select case and other features à la carte.

I find it frustrating to not be able to turn-Off calt, ccmp, and rlig for example.
Another reason to not use APub to document a font, or test it.
 

Regarding the small caps - I need a visual way to scan if there are any issues.
When smcp is Off, and fake small caps is Off, you can see what is not working (usually do this in LibreOffice).
When you are trying to document everything which is supported and does work, you also need to be able to see what is not supported, or not working.
And with hundreds of characters it gets kinda crazy.
For example EB Garamond has ~800 lowercase characters, and ~400 small caps.
So out of those 800, some should have small caps, some should not, and some may be missing, and some are not working properly.
Your mission, Mr. Briggs, is to figure that out and put it on paper.