Before Apple switched its system font to San Francisco in 2015, with El Capitan, it had used a succession of fonts already in widespread use, including Lucida Grande and Helvetica Neue. Those could be used in regular documents, embedded and used on other systems, and there was a good chance that anyone you sent documents to would also have those fonts installed locally, but not so for San Francisco, which is exclusive to Apple.

Open Font Book on a Mac with a standard suite of system fonts, and you won’t find San Francisco, or either of its abbreviated names of SF or SF Pro. Browse the list of fonts available in Pages or any other app and you won’t find them there either. The only place you can see them in cameo is in the 17 TrueType fonts of the SF family in /System/Library/Fonts, from SFArabic to SFNSRounded.

Yet most apps use the system font in their interfaces, and sometimes they appear in their documents too. I’ll trace an example through my log browser Ulbow out to a PDF and web page of a log extract.

Because Ulbow browses log extracts, there must be no ambiguity in the glyphs displayed, no room for confusion between O and 0, or l and 1 (O and 0, or l and 1). It also helps if its characters are evenly spaced, so it uses the system monospaced font for the text contents of its window. Prior to Catalina, that was set using NSFont.monospacedDigitSystemFont(), but since then it’s done using NSFont.monospacedSystemFont() instead.

Ulbow then saves the styled text from a log extract, which is stored as an NSAttributedString, to Rich Text format. That’s much easier than it sounds, as that’s the standard format for such attributed strings, and conveniently supported by macOS. The Rich Text file sets the font to be used to .AppleSystemUIFontMonospaced-Regular, and that in turn is recognised correctly by my Rich Text editor DelightEd as the Regular face of the font .AppleSystemUIFontMonospaced. Provided that file is opened on a Mac, with the system fonts installed, macOS will find the font and display it correctly, even though you won’t ordinarily find any of these system fonts in app font menus.

Not all Rich Text editors will respect the system font set, though. While Nisus Writer Pro is happy to, Pages converts it to Helvetica whether it opens the RTF file direct, or the styled text is pasted in from DelightEd. Oddly, though, Pages adds the original font to its font menu so you can select the text and set it back to that font if you insist.

Export that Rich Text file from DelightEd to PDF, and the font is carried through into the PDF source, where each block of text is set in the same font:
/Type /Font /Subtype /TrueType /BaseFont /AAAAAB+.SFNSMono-Regular /FontDescriptor
here named SFNSMono-Regular, the first mention of the system font filename. Note, though, that font isn’t embedded in the PDF, so when displayed on another system lacking macOS system fonts, it should be substituted using another monospace font such as Courier New.

DelightEd will also export the Rich Text file to HTML using the standard built-in conversion, where embedded CSS sets the font as .AppleSystemUIFontMonospaced to maintain consistency. Unfortunately, that’s where the monospaced font comes to an end, as Safari won’t render it using that, despite running on macOS, and falls back to its default body font.

These behaviours are all intended to ensure that San Francisco isn’t exported from your Mac to a non-Apple system. If you’re a registered Apple developer, you can download system fonts from Apple, and use them to design app mockups. But if you were to try transferring those to a different platform, then you would breach the font’s licence. In any case, other systems are likely to refuse to display those fonts because of the licence terms embedded in them.

There’s also a GitHub repository where you can download OpenType versions of all the San Francisco family for strictly non-commercial purposes. Each is accompanied by a summary of restrictions on its use.

Finally, the jewel in San Francisco’s crown isn’t a font at all, but a collection of thousands of vector-graphic symbols, SF Symbols. These are readily accessible in UIKit (iOS), AppKit (macOS), and above all in SwiftUI. A small selection of them appears in this screenshot from Unhidden.

A curious discovery

When my workflow had fully transformed from Sketch to Figma, I found there was an option “Case-Sensitive Forms” placed in several typeface setting panels. The appearance of the font might change slightly and occasionally when I enable this setting.

I was interested in this setting option, then I tried to find out concepts and related knowledge about the term “Case-Sensitive Forms.”

In this post, I will explain what Case-Sensitive Forms are, when should we implement this feature to uplift our design with several practices, and how to use it in our workflow.

Features

The “Case-Sensitive Forms” is a feature of OpenType features, which are like hidden compartments in fonts that allow us to change how fonts look and behave. When we use this feature, the font will:

1. Shift some punctuation marks up to a higher position;
2. Change oldstyle figures to modern figures.

Feature 1: Shifting some punctuation marks up to a higher position

In general, punctuation marks are vertically centered with lowercase characters, which is known as “x-height.”

However, when using the Case-Sensitive Forms feature, some punctuation marks are aligned with the height of uppercase characters, which we call “Cap height.”

Feature 2: Changing oldstyle figures to modern figures

Some fonts use oldstyle figures by default to add visual attraction. It is often used in traditional publications like books and newspapers since this font has a rhythmic beauty with varied heights.

When using the Case-Sensitive Forms feature, fonts will be directly changed to modern figures, also known as “lining figures.”

Realistic practices

Inspiring by the feature 1, shifting some punctuation marks up to a higher position, it is well-suited for compositions that mix uppercase characters, figures, and CJK characters.

Here is a list of compositions that might be visually improved by using the Case-Sensitive Forms feature.

1. International phone number

Because figure glyphs are as high as uppercase characters, the use of Case-Sensitive Forms is ideal for displaying phone numbers that include area codes.

2. Date and time

Similarly, date and time is also well-suited for using the Case-Sensitive Forms feature since they are typically consisted of figures and marks.

3. All caps text

To make titles or other important information visually prominent, we often capitalize the text, which is also ideal for using the Case-Sensitive Forms feature.

4. East Asian typography

East Asian typography looks like a square, meaning the visual height of Chinese, Japanese, Korean, and Vietnamese characters is similar to the “X” letter’s cap height.

Therefore, the Case-Sensitive Forms feature are also fitting for the East Asian typography scenario, ensuring marks are vertically aligned with the characters.

5. Sensitive information

When displaying sensitive information on digital interfaces, such as Social Security Number(SSNs), bank account numbers, and phone numbers, we often use asterisks (*) or dots (•) to partially obscure it. In that case, the Case-Sensitive Forms feature is highly suitable.

6. Text face

A rare scenario that may be ideal for using the Case-Sensitive Forms feature is text faces, such as “:D” and “:-)”

How to use

1. Supported typefaces

Only typefaces that support the OpenType feature of Case-Sensitive Forms can enable this feature.

It means that not ALL typefaces support this feature, even if we implement this setting in design tools or through coding. I’ve simply made a list to clarify which typefaces support it and which not.

Typefaces that support the Case-Sensitive Forms feature:

1. DIN Pro;
2. Inter;
3. San Francisco (fonts for Apple platforms);
4. Inria Sans;
5. Warnock Pro…

Typefaces that DO NOT support the Case-Sensitive Forms feature:

1. Arial;
2. Helvetica;
3. Noto Sans;
4. Roboto;
5. Source Sans;
6. Segoe UI…

In other words, the Case-Sensitive Forms feature only works on Apple devices if we use the system default font on our website.

2. Figma

Follow these steps to implement the Case-Sensitive Forms feature in Figma. Select a text layer, then:

1. Open the “Type settings” panel;
2. Switch to the “Details” tab;
3. Check the “Case-sensitive forms” option.

3. CSS

To use the Case-Sensitive Forms feature on the website, we just need to simply add font-feature-settings: ‘case’; to the element that we want to implement this feature.

The CSS Compatibility of this style is quite good. Again, we need to ensure the typefaces support the Case-Sensitive Forms feature; otherwise there will be no changes.

Set as default?

We’ve discussed many scenarios and advantages of using the Case-Sensitive Forms feature. So should we set it as the default style?

My answer is NO.

Although it can uplift visual details with numbers and capital text, it is quite awful when used with lowercase letters, which are more commonly used on our website.

However, we can safely implement the Case-Sensitive Forms feature in some components that always consist of numbers, marks, and capital letters. Here is the list of UI components:

1. Avatar;
2. Badge;
3. Pagination (Image viewer, Swiper and the likes);
4. Letter counter.

For comparison, let’s see the most common solution in which the Case-Sensitive Forms feature is not implemented on digital interfaces.

Recently, my team has been redesigning our mobile component library. I’ve suggested using the Case-Sensitive Forms feature on the components listed above. Let’s see the outcomes in the future.

References

1. Feature: case — Case sensitive Forms
2. 高级排版功能：Case-Sensitive Forms 是什么？

Uplifting your design details with the Case-Sensitive Forms feature was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.