Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

A brief history of fonts in Mac OS

By: hoakley
3 May 2025 at 15:00

The first Macs came with bitmap fonts stored in FONT resources, and those were normally used in the set sizes supplied, as they scaled so poorly. Later in 1984, with the release of the ‘Fat’ Mac 512K and its 128K ROM, Apple moved to NFNT bitmap fonts with a more flexible ID scheme. This continued to change the following year with the introduction of the LaserWriter printer and its built-in PostScript fonts, but those fonts remained in the printer, and Mac displays stayed with bitmap NFNT fonts.

At the outset, Apple had taken a small liberty with the size of the point, the standard unit in typography and print design. In normal US usage there were 72.27 points per inch, which Apple rounded down to 72 for the Mac, where it has remained ever since.

Adobe introduced PostScript Type 1 fonts, still primarily for PostScript laser printers and Adobe Type Manager software. Although competitors reverse-engineered the Type 1 format, Adobe brought them into costly licensing agreements, so limiting access to their rendering. This provoked Apple to start developing a rival outline format, later to be termed spline fonts or sfnt. This project was initially known internally as Bass, then renamed Royal, and was released as TrueType with System 7 in May 1991.

As late as 2002 Mac OS 9.2 still used some bitmap fonts.

Throughout Classic Mac OS, fonts were stored as resources, and in the early years had to be installed using Font/DA Mover, a bundled utility that also performed ID reconciliation. DA stood for Desk Accessory, which also required careful installation.

This is Font/DA Mover 4.1 in 1999.

Individual fonts were grouped into FOND font families, also introduced with the 128K ROM. These could include both NFNT and TrueType sfnt font types. FOND families each had their own ID, but those weren’t unique, so fonts had to be specified by name.

With the success of TrueType, Classic Mac OS became the first operating system to be able to work without the use of bitmap fonts, but still couldn’t itself render PostScript Type 1 fonts to a display. Those using Macs for pre-print design paid for Adobe Type Manager to perform that rendering.

TrueType was revolutionary in opening up font internals in a way that hadn’t been possible with Adobe’s control over PostScript Type 1 fonts. At the time I was writing CAD/CAM apps to support extreme-format cutting systems used by sailmakers and others, who also wanted to cut large characters from fabrics. One of Apple’s TrueType engineers worked closely with me to convert the outline drawing commands in TrueType glyphs into cutter control streams to fabricate letters and numbers sometimes several feet/metres high. I never did work out what point size they would have been.

Microsoft licensed TrueType free from Apple, but Adobe fought back by opening up its Type 1 font format as free to use. Apple enhanced TrueType in 1994, with TrueType GX, bringing Variations to compete with Adobe’s Multiple Master fonts, but it never caught on and few GX fonts were ever released. Its technology was, though, incorporated into Microsoft’s TrueType Open in 1994, and two years later that was merged with support for Type 1 features in OpenType, which became an ISO standard in 2007. The final milestone, for now at least, was the release of OpenType 1.8 in 2016, with its full incorporation of the font Variations of TrueType GX and Adobe’s Multiple Master fonts.

FontLab was originally developed for Windows, and version 3 came to Mac OS 8 in 1988. It’s seen here in 2001, in Mac OS 9.

The release of Mac OS X in 2001 drew Mac fonts away from their previous reliance on resource forks. Font suitcases thus moved to a data-fork format with the extension dfont.

These font suitcases are seen in data-fork format in Mac OS X 10.3 Panther in 2004.

At that time, Apple’s bundled Font Book app had limited features. Here it’s displaying a data-fork format TrueType font Zapfino.

Fontage was a substitute with additional features.

Mac OS X has also brought substantial improvements in Apple Advanced Typography (AAT), a successor to TrueType GX. Mac OS X 10.4 largely completed advanced support for Latin scripts, with later versions of OS X and macOS extending that to Arabic and Asian languages.

Major foundries produced their own software. This is Linotype’s FontExplorer X in 2006, helping to repair a PostScript font suitcase with missing files for download to a PostScript printer.

By 2006, FontLab had developed into FontLab Studio, seen here editing glyphs from my own handwritten font.

Linotype released a Pro version of its FontExplorer X, shown here in 2010. For typographers, designers and font nerds it revealed almost everything there was to know about a font, here a TrueType Helvetica variant.

The other major font design app for Mac OS was Fontographer, developed by James R Von Ehr II, and released by his company Altsys in 1986. This was the successor to an earlier bitmap font editor named Fontastic, and two years later Altsys released the pioneering illustration app FreeHand. In 1995, Altsys was bought by Macromedia, then ten years later Fontographer was bought by FontLab. This shows Fontographer 5.0, released in 2010, and sadly abandoned a few years later.

References

Chapter 4 in Apple’s Inside Macintosh: Text (1993)

Wikipedia’s list of typefaces in Mac OS X
PostScript fonts on Wikipedia
TrueType on Wikipedia
OpenType on Wikipedia

Uplifting your design details with the Case-Sensitive Forms feature

The image features a graphic with a light blue and white gradient background. It includes the text “Uplifting your design details with Case-Sensitive Forms” in bold blue letters and the website “LRD.IM” in smaller text. A 3D letter ‘A’ in a blue, bubble-like design is positioned on the right side of the image.

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.

The image shows a settings panel in Figma focusing on typography settings. It highlights the “Case-Sensitive Forms” option, which is clearly marked in a dropdown menu under the “Details” tab. The “Case-Sensitive Forms” setting is encircled in red to emphasize its importance in the typography setup.

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.”

Comparative display of text alignment with and without Case-Sensitive Forms in Figma, showing punctuation marks adjusted to a higher position.

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.”

Visual comparison in Figma of oldstyle figures versus modern figures using Case-Sensitive Forms feature.

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.

Graphic displaying an international phone number ‘+1(425) 555–0100’ with normal and Case-Sensitive Forms formatting in Figma.

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.

Graphic displaying the date ‘2024–06–10 9:39 PM (GMT+8)’ with normal and Case-Sensitive Forms formatting in Figma.

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.

Graphic displaying the text ‘SIGN-UP NOW’ in all caps, with normal and Case-Sensitive Forms formatting in Figma.

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.

Graphic displaying East Asian typography ‘50条/页’ and ‘NHK | 日本放送协会’ with normal and Case-Sensitive Forms formatting in Figma.

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.

Graphic displaying masked sensitive information ‘***-**-1234’ with normal and Case-Sensitive Forms formatting in Figma.

6. Text face

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

Graphic displaying text faces ‘:D’ and ‘:-)’ with normal and Case-Sensitive Forms formatting in Figma.

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.
Screenshot of the Figma interface highlighting the Case-Sensitive Forms setting in the type settings panel. Step 1: Select the text layer indicated by a three dots icon. Step 2: Click on the ‘Details’ tab. Step 3: Enable the Case-Sensitive Forms option from a dropdown menu.

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.

Code snippet displayed in a dark theme editor with CSS properties: font-feature-settings: ‘case’; This is used to implement Case-Sensitive Forms for displaying a phone number.

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.

Chart displaying high browser compatibility for CSS font-feature-settings, with most modern browsers showing extensive support for advanced typographic features.

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.

Graphic displaying the sentence ‘I bought apples (and oranges).’ in two styles: normal and with Case-Sensitive Forms in Figma.

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.
Display of various UI components using Case-Sensitive Forms in Figma, including Avatar icons with notification counts, Badge icons with user images, a pagination interface, and a letter counter showing ‘My website is LRD.IM’.

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

Display of various UI components in Figma without Case-Sensitive Forms: Avatar icons with notification counts, Badge icons with user images, a pagination interface, and a letter counter showing ‘My website is LRD.IM’.

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.

❌
❌