CSS 폰트 모듈 레벨 3

요약

이 CSS3 모듈은 폰트 속성이 어떻게 지정되는지와 폰트 리소스가 어떻게 동적으로 로드되는지를 설명합니다. 이 명세의 내용은 이전에 CSS3 폰트와 CSS3 웹 폰트 모듈로 나뉘어 있던 내용을 통합한 것입니다. 폰트 로드 이벤트에 대한 설명은 CSS 폰트 로딩 모듈로 이동되었습니다.

문서 현황

이 섹션은 문서가 발행된 시점의 상태를 설명합니다. 다른 문서가 이 문서를 대체할 수 있습니다. 현재 W3C 발행물 목록과 이 기술 보고서의 최신 개정본은 W3C 기술 보고서 인덱스 https://www.w3.org/TR/에서 확인할 수 있습니다.

이 문서는 W3C 회원, 소프트웨어 개발자, 그리고 다른 W3C 그룹 및 관심 있는 관계자들에 의해 검토되었으며, 이사(Director)에 의해 W3C 권고안으로 승인되었습니다. 이 문서는 안정적인 문서로 참고 자료로 사용하거나 다른 문서에서 인용할 수 있습니다. W3C가 권고안을 만드는 역할은 명세에 주목을 끌고 널리 배포를 촉진하는 것입니다. 이는 웹의 기능성과 상호운용성을 향상시킵니다.

이 문서는 CSS 작업 그룹에서 W3C 권고안으로 제작되었습니다.

이 문서는 W3C 특허 정책에 따라 운영되는 그룹에서 제작되었습니다. W3C는 그룹의 결과물과 관련된 특허 공개 목록을 공개합니다. 해당 페이지에는 특허 공개 방법에 대한 안내도 포함되어 있습니다. 개별적으로 필수 청구항이 포함된 특허를 알고 있는 경우, W3C 특허 정책 6항에 따라 정보를 공개해야 합니다.

이 문서는 2018년 2월 1일 W3C 프로세스 문서에 따라 관리됩니다.

테스트 스위트와 구현 보고서 를 이용할 수 있습니다.

1. 소개

폰트는 문자에 대한 시각적 표현을 포함하는 리소스를 제공합니다 [CHARMOD][UNICODE]. 가장 단순한 수준에서는 문자 코드와 해당 문자를 나타내는 형태(글리프라고 함) 간의 매핑 정보를 포함합니다. 공통된 디자인 스타일을 공유하는 폰트들은 일반적으로 표준 폰트 속성 집합에 따라 폰트 패밀리로 그룹화됩니다. 패밀리 내에서, 특정 문자에 대해 표시되는 형태는 획의 굵기, 기울기, 상대 너비 등 다양한 요소에 따라 달라질 수 있습니다. 개별 폰트 페이스는 이러한 속성의 고유한 조합으로 설명됩니다. 특정 텍스트 범위에 대해 CSS 폰트 속성은 렌더링 시 사용할 폰트 패밀리 및 해당 패밀리 내의 특정 폰트 페이스를 선택하는데 사용됩니다. 예를 들어, Helvetica의 굵은(bold) 형태를 사용하려면 다음과 같이 할 수 있습니다:

body {
    font-family: Helvetica;
    font-weight: bold;
}

폰트 리소스는 사용자 에이전트가 실행되는 시스템에 로컬로 설치되어 있거나 다운로드 가능할 수 있습니다. 로컬 폰트 리소스의 경우 설명 정보를 폰트 리소스에서 직접 얻을 수 있습니다. 다운로드 가능한 폰트 리소스(웹 폰트라고도 함)의 경우 설명 정보가 폰트 리소스 참조와 함께 포함되어 있습니다.

폰트 패밀리는 일반적으로 가능한 모든 폰트 속성의 단일 페이스만 포함하지 않습니다. CSS 폰트 선택 메커니즘은 주어진 CSS 폰트 속성 집합을 단일 폰트 페이스에 어떻게 매칭할지 설명합니다.

2. 타이포그래피 배경

이 섹션은 규범적이지 않습니다.

타이포그래피 전통은 전 세계적으로 다양하므로, 모든 폰트를 언어와 문화 전반에 걸쳐 하나의 방법으로 분류할 수는 없습니다. 흔한 라틴 문자의 경우에도 다양한 변형이 가능합니다:

하나의 문자, 다양한 글리프 변형

문자의 형태 구조 차이는 폰트를 구분하는 한 방법입니다. 라틴 폰트의 경우, 문자 주요 획의 끝부분의 장식(세리프)은 세리프가 없는 폰트와 구분될 수 있습니다. 비슷한 비교는 비라틴 폰트에서도 가늘어지는 획을 가진 폰트와 주로 일정한 획을 사용하는 폰트 사이에서 볼 수 있습니다:

세리프가 있는 문자와 없는 문자

일본어 서체의 유사한 그룹화

폰트에는 문자 형태와 문자를 해당 형태에 매핑하는 데 필요한 데이터가 포함되어 있습니다. 이는 종종 1:1 매핑일 수 있지만, 더 복잡한 매핑도 가능합니다. 결합자음 부호(다이아크리틱 마크)의 사용은 기본 문자 형태에 많은 변형을 생성합니다:

다이아크리틱 마크에 따른 변형

문자 시퀀스가 fi 결합 문자처럼 하나의 글리프로 표현될 수도 있습니다:

결합문자(리그처) 예시

텍스트 맥락에 따른 시각적 변형은 유럽 언어에서는 종종 스타일 선택 사항이지만, [ARABIC-TYPO]와 같은 언어에서는 올바른 렌더링을 위해 필수적입니다. 아래 lam과 alef 문자는 연속될 때 반드시 결합되어야 합니다:

필수 아랍어 결합문자

이러한 형태 변환의 상대적 복잡성은 폰트 내에 추가 데이터를 필요로 합니다.

다양한 스타일 변형을 가진 폰트 페이스 집합은 종종 하나의 폰트 패밀리로 그룹화됩니다. 가장 단순한 경우, 일반 페이스가 굵은(bold) 및 기울임꼴(italic) 페이스로 보완되지만, 훨씬 더 광범위한 분류도 가능합니다. 글자 획의 두께(굵기weight)와 전체적인 글자 비율(너비width)의 변형이 가장 흔합니다. 아래 예시에서 각 글자는 Univers 폰트 패밀리 내의 서로 다른 폰트 페이스를 사용합니다. 위에서 아래로 갈수록 너비가 증가하고, 왼쪽에서 오른쪽으로 갈수록 굵기가 증가합니다:

하나의 폰트 패밀리 내 다양한 굵기와 너비 변형

여러 스크립트를 지원하는 폰트를 만드는 것은 어려운 작업입니다. 디자이너는 각 스크립트의 문화적 전통을 이해하고, 공통의 테마를 공유하는 문자 형태를 고안해야 합니다. 많은 언어들은 공통된 스크립트를 공유하지만, 각 언어마다 눈에 띄는 스타일적 차이가 있을 수 있습니다. 예를 들어, 아랍어 스크립트는 페르시아어와 우르두어에서 사용될 때 글자 형태에 상당한 체계적 차이를 보이는데, 키릴 문자도 세르비아어 및 러시아어와 같이 사용될 때 차이가 있습니다.

폰트의 문자 매핑(character map)은 해당 폰트의 문자와 글리프 간 매핑을 정의합니다. 만약 문서에 폰트 패밀리 목록에 포함된 폰트들의 문자 매핑(character map)이 지원하지 않는 문자가 있다면, 사용자 에이전트는 해당 문자를 지원하는 적절한 폰트를 찾기 위해 시스템 폰트 폴백 절차를 사용할 수 있습니다. 적절한 폰트를 찾을 수 없는 경우, 사용자 에이전트가 "누락된 글리프" 문자를 렌더링하게 됩니다. 시스템 폴백은 지정된 폰트 패밀리 목록에 해당 문자를 지원하는 폰트가 없을 때 발생할 수 있습니다.

폰트의 문자 매핑(character map)이 주어진 문자를 해당 글리프로 매핑하지만, OpenType [OPENTYPE] 및 AAT(Apple Advanced Typography) [AAT-FEATURES]와 같은 현대 폰트 기술은 기능 설정에 따라 문자를 다른 글리프로 매핑할 수 있는 방법을 제공합니다. 이러한 형식의 폰트는 기능을 폰트 자체에 내장하고 애플리케이션에서 제어할 수 있습니다. 이 방식으로 지정 가능한 일반적인 타이포그래피 기능에는 결합문자, 장식체(swashes), 문맥 대체(contextual alternates), 비례 및 탭형 숫자, 자동 분수 등이 있습니다. OpenType 기능의 시각적 개요는 [OPENTYPE-FONT-GUIDE]를 참조하세요.

3. 기본 폰트 속성

문자를 렌더링할 때 사용되는 특정 폰트 페이스는 해당 요소에 적용되는 폰트 패밀리와 기타 폰트 속성에 의해 결정됩니다. 이 구조는 각 설정을 독립적으로 조정할 수 있도록 해줍니다.

3.1. 폰트 패밀리: font-family 속성

이 속성은 폰트 패밀리 이름 또는 일반 패밀리 이름의 우선순위가 지정된 목록을 지정합니다. 폰트 패밀리는 굵기, 너비 또는 기울기 등이 다양한 페이스들의 집합을 정의합니다. CSS는 패밀리 이름과 다른 스타일 속성의 조합을 사용하여 개별 페이스를 선택합니다. 디자인 애플리케이션에서 스타일 이름으로 페이스를 직접 선택하는 것과 달리, 이러한 선택 메커니즘을 사용하면 폴백이 발생할 때 텍스트 표시가 어느 정도 일관성을 가질 수 있습니다.

디자이너는 CSS에서 선택에 사용되는 폰트 속성 정의가 폰트 분류 체계(taxonomy)를 정의하려는 것이 아님을 명확히 이해해야 합니다. 타입 디자이너가 생각하는 패밀리는 굵기, 너비, 기울기 같은 표준 축 외에도 다양한 축을 따라 변형되는 페이스 집합일 수 있습니다. 한 패밀리는 세리프 페이스와 산세리프 페이스를 모두 포함하거나, 해당 패밀리만의 고유한 축을 따라 다양해질 수도 있습니다. CSS 폰트 선택 메커니즘은 대체가 필요할 때 "가장 가까운" 대체 폰트를 결정하는 방법만을 제공합니다.

다른 CSS 속성과 달리, 구성 값들은 대안들을 나타내는 콤마로 구분된 목록입니다. 사용자 에이전트는 렌더링할 문자의 글리프를 포함한 사용 가능한 폰트가 나올 때까지 패밀리 이름 목록을 순차적으로 확인합니다. 이는 플랫폼마다 사용 가능한 폰트와 개별 폰트가 지원하는 문자 범위의 차이를 허용합니다.

폰트 패밀리 이름은 페이스 집합에 부여된 이름만을 지정하며, 개별 페이스를 지정하지는 않습니다. 예를 들어, 아래 폰트들이 있을 때 Futura는 일치하지만 Futura Medium은 일치하지 않습니다:

패밀리와 개별 페이스 이름

아래 예시를 참고하세요:

body {
    font-family: Helvetica, Verdana, sans-serif;
}

폰트 패밀리 이름에는 두 가지 종류가 있습니다:

<family-name>

이전 예시의 Helvetica 또는 Verdana와 같은 선택한 폰트 패밀리의 이름

<generic-family>

다음의 일반 패밀리 키워드가 정의되어 있습니다: ‘serif’, ‘sans-serif’, ‘cursive’, ‘fantasy’, 그리고 ‘monospace’. 이러한 키워드는 저자가 원하는 폰트가 없을 때 일반적인 폴백 메커니즘으로 사용할 수 있습니다. 키워드이므로 반드시 따옴표로 묶지 않아야 합니다. 저자들은 마지막 대안으로 일반 폰트 패밀리를 추가해 견고성을 높일 것을 권장합니다.

일반 패밀리를 제외한 폰트 패밀리 이름은 문자열로 따옴표를 묶거나, 식별자 시퀀스로 따옴표 없이 지정해야 합니다. 이는 대부분의 구두점 문자와 각 토큰의 시작에 있는 숫자가 따옴표 없이 폰트 패밀리 이름에 있을 경우 반드시 이스케이프 처리해야 함을 의미합니다.

이를 설명하기 위해, 다음 선언들은 유효하지 않습니다:

font-family: Red/Black, sans-serif;
font-family: "Lucida" Grande, sans-serif;
font-family: Ahem!, sans-serif;
font-family: test@foo, sans-serif;
font-family: #POUND, sans-serif;
font-family: Hawaii 5-0, sans-serif;

식별자 시퀀스가 폰트 패밀리 이름으로 주어지면, 계산된 값은 모든 식별자를 단일 공백으로 연결하여 문자열로 변환한 이름입니다.

이스케이프 실수를 방지하려면 공백, 숫자, 하이픈 이외의 구두점이 포함된 폰트 패밀리 이름은 따옴표로 묶는 것이 좋습니다:

body { font-family: "New Century Schoolbook", serif }

<BODY STYLE="font-family: '21st Century', fantasy">

키워드 값(‘inherit’, ‘serif’ 등)과 동일한 폰트 패밀리 이름은 혼동을 피하기 위해 반드시 따옴표로 묶어야 합니다. 사용자 에이전트는 이러한 키워드를 <family-name> 타입과 일치하는 것으로 간주해서는 안 됩니다. 이는 CSS 전체의 모든 키워드에 적용됩니다.

폰트 집합이 폰트 패밀리로 어떻게 그룹화되는지에 대한 정확한 방식은 플랫폼 폰트 관리 API마다 다릅니다. Windows GDI API는 하나의 패밀리에 네 개의 페이스만 그룹화할 수 있지만, DirectWrite API와 OSX 및 기타 플랫폼의 API들은 다양한 굵기, 너비, 기울기 등으로 구성된 폰트 패밀리를 지원합니다(부록 A에서 더 자세히 설명).

일부 폰트 포맷은 패밀리 이름의 여러 지역화(로컬라이즈) 버전을 포함할 수 있습니다. 사용자 에이전트는 플랫폼의 지역화, 시스템 API, 문서 인코딩과 관계없이 모든 이름을 인식하고 올바르게 일치시켜야 합니다:

지역화된 패밀리 이름 예시

지역화된 폰트 패밀리 이름 매칭과 관련된 세부사항 및 대소문자 구분 문제는 아래 폰트 매칭 섹션에서 설명합니다.

3.1.1. 일반 폰트 패밀리

모든 CSS 구현에서 다섯 가지 일반 폰트 패밀리는 반드시 하나 이상의 일치하는 폰트 페이스가 나와야 합니다. 그러나 일반 패밀리는 문자 유니코드 범위, 포함된 요소의 언어, 사용자 환경설정, 시스템 설정 등 여러 기준에 따라 서로 다른 서체로 구성된 복합 페이스일 수 있습니다. 또한 항상 서로 다르다고 보장할 수는 없습니다.

사용자 에이전트는 각 패밀리의 특성을 최대한 잘 표현하는 합리적인 기본값을 제공해야 하며, 기술적 한계 내에서 대체 선택도 허용하는 것이 좋습니다.

serif

세리프 폰트는 스크립트의 공식적인 텍스트 스타일을 나타냅니다. 이는 일반적으로 글리프 끝에 마감 획, 퍼졌거나 가늘어진 끝, 실제 세리프(슬랩 세리프 포함)가 있음을 의미하지만, 반드시 그것만을 의미하는 것은 아닙니다. 세리프 폰트는 보통 비례적으로 간격이 정해집니다. 두께가 두꺼운 획과 얇은 획의 변화가 ‘sans-serif’ 일반 패밀리 폰트보다 더 클 때가 많습니다. CSS는 ‘serif’라는 용어를 모든 스크립트의 폰트에 적용하지만, 일본어에서는 민초(Mincho), 중국어에서는 송(Sung)/송(Song), 한국어에서는 바탕(Batang) 등이 더 익숙할 수 있습니다. 아랍어의 경우, Naskh 스타일은 실제 디자인보다 타이포그래피 역할에 따라 ‘serif’에 더 가깝습니다. 이러한 설명에 해당하는 폰트는 모두 ‘serif’ 일반 패밀리로 사용할 수 있습니다.

세리프 폰트 샘플

sans-serif

CSS에서 산세리프 폰트의 글리프는 일반적으로 대비가 낮고(수직 및 수평 획 두께가 거의 동일) 획 끝이 단순하며(퍼짐, 교차 획, 장식 없음) 비례적으로 간격이 정해집니다. 두꺼운 획과 얇은 획의 변화가 ‘serif’ 패밀리 폰트보다 적습니다. CSS는 ‘sans-serif’라는 용어를 모든 스크립트의 폰트에 적용하지만, 일본어에서는 고딕(Gothic), 중국어에서는 흑체(Hei), 한국어에서는 굴림(Gulim) 등이 더 익숙할 수 있습니다. 이러한 설명에 해당하는 폰트는 모두 ‘sans-serif’ 일반 패밀리로 사용할 수 있습니다.

산세리프 폰트 샘플

cursive

커서브 폰트의 글리프는 대체로 더 비공식적인 스크립트 스타일을 사용하며, 결과적으로 인쇄된 글자보다 펜이나 붓으로 손글씨를 쓴 듯한 모습이 나타납니다. CSS는 ‘cursive’라는 용어를 모든 스크립트의 폰트에 적용하지만, Chancery, Brush, Swing, Script 등 다양한 이름이 폰트명으로도 사용됩니다.

커서브 폰트 샘플

fantasy

판타지 폰트는 주로 장식적이거나 표현적인 폰트로, 문자에 장식적 또는 개성 있는 표현을 담고 있습니다. 실제 문자를 나타내지 않는 Pi 또는 그림(Picture) 폰트는 포함되지 않습니다.

판타지 폰트 샘플

monospace

모노스페이스 폰트의 유일한 기준은 모든 글리프의 너비가 동일하게 고정되어 있다는 점입니다. 이는 주로 컴퓨터 코드 샘플을 렌더링할 때 사용됩니다.

모노스페이스 폰트 샘플

3.2. 글꼴 굵기: font-weight 속성

‘font-weight’ 속성은 글꼴의 글리프 굵기, 검은 정도 또는 획의 두께를 지정합니다.

값의 의미는 다음과 같습니다:

100 ~ 900

이 값들은 순서가 있는 연속을 이루며, 각 숫자는 이전 값보다 최소한 더 진한 굵기를 나타냅니다. 이는 아래에 흔히 사용되는 굵기 이름과 대략적으로 대응합니다:

• 100 - 얇음(Thin)
• 200 - 엑스트라 라이트(Extra Light, Ultra Light)
• 300 - 라이트(Light)
• 400 - 보통(Normal)
• 500 - 미디엄(Medium)
• 600 - 세미 볼드(Semi Bold, Demi Bold)
• 700 - 볼드(Bold)
• 800 - 엑스트라 볼드(Extra Bold, Ultra Bold)
• 900 - 블랙(Black, Heavy)

normal

‘400’과 동일합니다.

bold

‘700’과 동일합니다.

bolder

상속된 값보다 더 두꺼운 굵기를 지정합니다.

lighter

상속된 값보다 더 얇은 굵기를 지정합니다.

9단계 스케일이 아닌 다른 스케일을 사용하는 폰트 포맷의 경우, 그 스케일을 CSS 스케일에 매핑해야 하며 400은 대략 Regular, Book, Roman에 해당하고 700은 대략 Bold에 해당해야 합니다. 또는 스타일 이름에서 굵기를 추론할 수도 있으며, 이는 위의 스케일과 대략적으로 일치해야 합니다. 이 스케일은 상대적이므로, 더 큰 값의 페이스가 더 얇게 표시되어서는 안 됩니다. 스타일 이름에서 굵기를 추론하는 경우, 지역에 따라 스타일명이 달라질 수 있음을 주의해야 합니다.

대부분의 경우 특정 폰트 패밀리에는 몇 가지 굵기만 존재합니다. 지정한 굵기에 맞는 페이스가 없으면, 가까운 굵기의 페이스가 사용됩니다. 일반적으로 볼드 계열은 더 두꺼운 페이스, 라이트 계열은 더 얇은 페이스에 매핑됩니다(아래 폰트 매칭 섹션에서 정확한 정의 참조). 아래 예시는 서로 다른 굵기에 대해 어떤 페이스가 사용되는지 보여줍니다. 회색은 해당 굵기의 페이스가 없어서 가까운 굵기의 페이스가 사용되는 경우입니다:

400, 700, 900 굵기 페이스가 있는 폰트 패밀리의 굵기 매핑

300, 600 굵기 페이스가 있는 폰트 패밀리의 굵기 매핑

타이포그래퍼들이 선호하지는 않지만, 실제 볼드 페이스가 없는 경우 사용자 에이전트가 볼드 페이스를 합성하는 경우도 많습니다. 스타일 매칭 관점에서는 이러한 합성된 페이스도 패밀리 내에 존재하는 것처럼 취급해야 합니다. 저자는 ‘font-synthesis’ 속성을 사용하여 이 동작을 명시적으로 방지할 수 있습니다.

‘bolder’와 ‘lighter’ 지정 값은 부모 요소의 굵기를 기준으로 상대적인 굵기를 나타냅니다. 계산된 굵기는 상속된 ‘font-weight’ 값에 따라 아래 표를 기반으로 계산됩니다.

위 표는 보통과 볼드 페이스, 얇은 페이스, 두꺼운 페이스가 있는 폰트 패밀리가 있을 때 상대적으로 더 굵거나 더 얇은 페이스를 선택하는 것과 동일합니다. 특정 요소에서 사용되는 정확한 굵기 값을 더 세밀하게 제어하고 싶다면 상대적 굵기 대신 숫자 값을 사용할 수 있습니다.

3.3. 글꼴 너비: font-stretch 속성

‘font-stretch’ 속성은 폰트 패밀리에서 보통, 좁은(condensed), 넓은(expanded) 페이스를 선택합니다. 절대 키워드 값은 가장 좁은 것부터 가장 넓은 것까지 다음과 같이 정렬됩니다:

• ultra-condensed
• extra-condensed
• condensed
• semi-condensed
• normal
• semi-expanded
• expanded
• extra-expanded
• ultra-expanded

주어진 너비에 맞는 페이스가 없는 경우, normal 또는 condensed 값은 더 좁은 페이스에 매핑되고, 그렇지 않으면 더 넓은 페이스에 매핑됩니다. 반대로 expanded 값은 더 넓은 페이스에 매핑되고, 그렇지 않으면 더 좁은 페이스에 매핑됩니다. 아래 그림은 다양한 너비를 가진 폰트 패밀리에 대해 아홉 가지 font-stretch 속성 설정이 폰트 선택에 어떻게 영향을 미치는지 보여줍니다. 회색은 해당 너비의 페이스가 없어 다른 너비가 대체되는 경우입니다:

Condensed, normal, expanded 너비 페이스가 있는 폰트 패밀리의 너비 매핑

글꼴 너비 애니메이션: 글꼴 너비는 이산 단계로 보간됩니다. 보간은 나열된 값이 동일한 간격의 실수(real number)인 것처럼 진행됩니다. 보간 결과는 가장 가까운 값으로 반올림되며, 두 값의 중간에 정확히 위치한 경우에는 위 목록에서 나중에 나온 값으로 반올림됩니다.

3.4. 글꼴 스타일: font-style 속성

‘font-style’ 속성은 이탤릭(italic) 또는 오블리크(oblique) 페이스를 선택할 수 있도록 합니다. 이탤릭 형태는 일반적으로 커서브(cursive) 성격을 가지며, 오블리크 페이스는 보통 일반 페이스를 기울인 형태입니다. 오블리크 페이스는 일반 페이스의 글리프를 인위적으로 기울여서 시뮬레이션할 수도 있습니다. 아래 그림은 Palatino의 ‘a’와 Baskerville의 ‘N’을 회색으로 인위적으로 기울인 렌더링과 실제 이탤릭 버전을 비교합니다:

인위적 기울임과 실제 이탤릭 비교

값의 의미는 다음과 같습니다:

normal

이탤릭이나 오블리크가 아닌, 보통(normal) 페이스를 선택합니다.

italic

이탤릭 페이스로 표시된 글꼴을 선택하며, 없을 경우 오블리크 페이스를 선택합니다.

oblique

오블리크 페이스로 표시된 글꼴을 선택하며, 없을 경우 이탤릭 페이스를 선택합니다.

이탤릭이나 오블리크 페이스가 없는 경우, 오블리크 페이스는 인위적으로 일반 페이스를 기울여서 합성할 수 있습니다. 이러한 인위적 오블리크 페이스의 사용은 ‘font-synthesis’ 속성으로 비활성화할 수 있습니다. 오블리크 처리의 구체적인 동작은 명시적으로 정의되어 있지 않습니다.

저자들은 합성된 방법이 키릴 문자와 같이 이탤릭 형태가 매우 다른 스크립트에는 적합하지 않을 수 있음을 인지해야 합니다. 합성된 버전 대신 실제 이탤릭 폰트를 사용하는 것이 항상 더 좋습니다.

많은 스크립트는 일반 페이스 내에서 커서브 형태를 혼용하는 전통이 없습니다. 중국어, 일본어, 한국어 폰트는 거의 항상 이탤릭이나 오블리크 페이스가 없습니다. 여러 스크립트를 지원하는 폰트는 때때로 아랍어 등 특정 스크립트의 글리프를 이탤릭 페이스에서 생략할 수도 있습니다. 사용자 에이전트는 시스템 폰트 폴백을 지원할 때 페이스 간의 문자 매핑에 대해 주의해야 합니다.

3.5. 글꼴 크기: font-size 속성

이 속성은 폰트에서 글리프의 원하는 높이를 나타냅니다. 확장 가능한 폰트에서는 font-size가 폰트의 EM 단위에 적용되는 스케일 팩터입니다. (특정 글리프가 EM 박스 밖으로 삐져나올 수도 있습니다.) 확장되지 않는 폰트에서는 font-size가 절대 단위로 변환되어 폰트에 선언된 ‘font-size’와 동일한 절대 좌표 공간에서 매칭됩니다. 값의 의미는 다음과 같습니다:

<absolute-size>

<absolute-size> 키워드는 사용자 에이전트가 계산해 유지하는 글꼴 크기 테이블의 항목을 참조합니다. 가능한 값:

[ xx-small | x-small | small | medium | large | x-large | xx-large ]

<relative-size>

<relative-size> 키워드는 폰트 크기 테이블과 부모 요소의 계산된 ‘font-size’에 상대적으로 해석됩니다. 가능한 값:

[ larger | smaller ]

예를 들어, 부모 요소의 글꼴 크기가 ‘medium’이면 ‘larger’ 값은 현재 요소의 글꼴 크기를 ‘large’로 만듭니다. 부모 요소의 크기가 테이블 항목과 가까운 값이 아니면, 사용자 에이전트는 테이블 항목 사이를 보간하거나 가장 가까운 값으로 반올림할 수 있습니다. 숫자 값이 키워드를 넘어서면 사용자 에이전트가 테이블 값을 외삽해야 할 수도 있습니다.

<length-percentage>

길이 값 [CSS-VALUES]은 사용자 에이전트의 글꼴 테이블과 무관하게 절대 글꼴 크기를 지정합니다. 음수 길이는 허용되지 않습니다.

백분율 값은 부모 요소의 글꼴 크기에 상대적인 절대 글꼴 크기를 지정합니다. 백분율 값이나 em 단위 값을 사용하면 더 견고하고 계단적인 스타일시트를 만들 수 있습니다. 음수 백분율은 허용되지 않습니다.

아래 표는 절대 크기 스케일 팩터 및 HTML 헤딩/절대 글꼴 크기와의 매핑에 대한 사용자 에이전트 가이드라인을 제공합니다. ‘medium’ 값이 기준값으로 사용됩니다. 사용자 에이전트는 폰트나 디스플레이 장치 종류에 따라 값을 세부 조정할 수 있습니다.

참고 1. 가독성을 유지하기 위해, 이러한 가이드라인을 적용하는 사용자 에이전트는 컴퓨터 디스플레이에서 EM 단위당 9 디바이스 픽셀 미만의 글꼴 크기를 생성하지 않도록 해야 합니다.

참고 2. CSS1에서는 인접 인덱스 간 권장 스케일 팩터가 1.5였으나, 사용자 경험상 너무 컸습니다. CSS2에서는 컴퓨터 화면에서 인접 인덱스 간 권장 스케일 팩터가 1.2였으나, 작은 크기에서 문제가 있었습니다. 새로운 스케일 팩터는 각 인덱스마다 달라지며 더 나은 가독성을 제공합니다.

이 속성의 실제 값은 ‘font-size-adjust’의 숫자 값이나 특정 글꼴 크기의 부재로 인해 계산된 값과 다를 수 있습니다.

자식 요소는 계산된 ‘font-size’ 값을 상속합니다(그렇지 않으면 ‘font-size-adjust’의 효과가 누적됨).

p { font-size: 12pt; }
blockquote { font-size: larger }
em { font-size: 150% }
em { font-size: 1.5em }

3.6. 상대 크기 조정: font-size-adjust 속성

주어진 폰트 크기에서, 텍스트의 실제 크기와 가독성은 폰트마다 다르게 나타납니다. 라틴이나 키릴 문자처럼 대문자와 소문자를 구분하는 스크립트에서는, 소문자 높이가 대문자에 비해 얼마나 높은지가 가독성의 중요한 요소입니다. 이는 일반적으로 aspect value라고 불리며, 정확히 정의하면 폰트의 x-height를 폰트 크기로 나눈 값입니다.

폰트 폴백이 발생하는 경우, 폴백 폰트는 원하는 폰트 패밀리와 같은 aspect value를 가지지 않을 수 있어 읽기 어려울 수 있습니다. ‘font-size-adjust’ 속성은 폰트 폴백 시 텍스트의 가독성을 유지하는 방법을 제공합니다. 폰트의 x-height가 폰트마다 달라지지 않도록 font-size를 조정해줍니다.

p {
    font-family: Verdana, Futura, Times;
}

<p>Lorem ipsum dolor sit amet, ...</p>

아래는 각 폰트로 렌더링된 텍스트 비교 예시입니다. 열마다 Verdana, Futura, Times로 텍스트가 표시됩니다. 각 행 내에서는 동일한 font-size가 사용되며, 빨간 선이 x-height의 차이를 보여줍니다. 위쪽 행은 동일한 font-size 값으로 렌더링되고, 아래쪽 행은 ‘font-size-adjust’ 속성이 추가로 설정되어 폰트마다 x-height가 유지되도록 실제 폰트 크기가 조정됩니다. 아래쪽 행에서는 작은 텍스트도 비교적 가독성이 잘 유지됩니다.

‘font-size-adjust’ 사용 전후 텍스트 비교

이 속성은 저자가 요소에 대해 aspect value를 직접 지정할 수 있게 하며, 실제로는 첫 번째 선택 폰트의 x-height를 유지할 수 있도록 합니다. 값의 의미는 다음과 같습니다:

none

폰트의 x-height를 유지하지 않습니다.

<number>

아래 계산에 사용되는 aspect value를 지정합니다:

c  =  ( a / a' ) s

여기서:

s  =  font-size 값
a  =  'font-size-adjust' 속성에 지정된 aspect value
a' =  실제 폰트의 aspect value
c  =  사용할 조정된 font-size

음수 값은 유효하지 않습니다.

이 값은 선택된 모든 폰트에 적용되지만, 일반적으로는 font-family 목록의 첫 번째 폰트의 aspect value를 기준으로 지정해야 합니다. 정확하게 지정하면 위 공식의 (a/a') 항은 첫 번째 폰트에 대해 사실상 1이 되므로 조정이 발생하지 않습니다. 부정확하게 지정하면, font-family 목록 첫 번째 폰트로 렌더링된 텍스트가 ‘font-size-adjust’를 지원하지 않는 구형 사용자 에이전트에서 다르게 표시될 수 있습니다.

‘font-size-adjust’ 값은 ‘font-size’의 사용 값에 영향을 주지만, 계산된 값에는 영향을 주지 않습니다. first available font의 폰트 메트릭을 기반으로 하는 ex, ch 등의 상대 단위 크기에 영향을 주지만, em 단위 크기에는 영향을 주지 않습니다. ‘line-height’의 숫자 값은 ‘font-size’의 계산된 크기를 참조하므로, ‘font-size-adjust’는 ‘line-height’의 사용 값에 영향을 주지 않습니다.

CSS에서 저자들은 종종 ‘line-height’를 ‘font-size’의 배수로 지정합니다. ‘font-size-adjust’ 속성이 사용될 때는 줄 높이 설정에 주의해야 합니다. 줄 높이가 너무 좁게 설정되면 줄이 겹칠 수 있습니다.

저자는 동일한 내용의 span을 비교하여, 각각 다른 ‘font-size-adjust’ 속성 값을 지정하면, 주어진 폰트의 aspect value를 계산할 수 있습니다. 동일한 font-size를 사용할 경우, 해당 폰트에 대해 정확한 ‘font-size-adjust’ 값을 지정하면 두 span의 크기가 일치합니다.

테두리가 있는 두 span으로 폰트의 aspect value를 판별합니다. 두 span의 ‘font-size’는 같지만, 오른쪽 span에만 ‘font-size-adjust’가 지정됩니다. 0.5 값부터 시작하여 두 글자의 테두리가 일치할 때까지 값을 조정할 수 있습니다.

p {
    font-family: Futura;
    font-size: 500px;
}

span {
    border: solid 1px red;
}

.adjust {
    font-size-adjust: 0.5;
}

<p><span>b</span><span class="adjust">b</span></p>

Futura의 aspect value가 0.5인 경우

오른쪽 박스가 왼쪽보다 약간 크므로, 이 폰트의 aspect value는 0.5보다 작습니다. 박스가 일치할 때까지 값을 조정하세요.

3.7. 축약 폰트 속성: font 속성

‘font’ 속성은 아래에 설명된 예외를 제외하고, ‘font-style’, ‘font-variant’, ‘font-weight’, ‘font-stretch’, ‘font-size’, ‘line-height’, ‘font-family’를 한 번에 설정하는 축약 속성입니다. ‘font-variant’ 속성 값도 포함될 수 있지만, CSS 2.1에서 지원되는 값만 사용 가능하며, 이 명세에서 추가된 ‘font-variant’ 값은 사용할 수 없습니다:

<font-variant-css21> = [normal | small-caps]

이 속성의 문법은 여러 폰트 관련 속성을 한 번에 지정하는 전통적인 타이포그래피 축약 표기법을 기반으로 합니다.

‘font’의 모든 하위 속성은 초기값으로 먼저 리셋됩니다. 위에 열거된 속성뿐 아니라 ‘font-size-adjust’, ‘font-kerning’, ‘font-variant’의 모든 하위 속성, ‘font-feature-settings’까지 포함되지만 ‘font-synthesis’는 포함되지 않습니다. 이후, 축약 속성에서 명시적으로 지정된 속성만 해당 값으로 설정됩니다. 허용 값과 초기값에 대한 정의는 앞서 정의된 각 속성을 참고하세요. 하위 호환성 때문에 ‘font’ 축약 속성으로는 ‘font-size-adjust’를 초기값 이외로 설정할 수 없으니, 개별 속성을 사용해야 합니다.

p { font: 12pt/14pt sans-serif }
p { font: 80% sans-serif }
p { font: x-large/110% "new century schoolbook", serif }
p { font: bold italic large Palatino, serif }
p { font: normal small-caps 120%/120% fantasy }
p { font: condensed oblique 12pt "Helvetica Neue", serif; }

‘font-stretch’ 속성이 CSS 2.1에는 없었으므로, ‘font’ 규칙에 ‘font-stretch’ 값을 사용할 때는 구형 사용자 에이전트 호환 버전을 추가해야 합니다:

p {
  font: 80% sans-serif;   /* 구형 사용자 에이전트용 */
  font: condensed 80% sans-serif;
}

다음 값들은 시스템 폰트를 나타냅니다:

caption

캡션 컨트롤(버튼, 드롭다운 등)에 사용되는 폰트

icon

아이콘의 라벨에 사용되는 폰트

menu

메뉴(드롭다운 메뉴, 메뉴 리스트 등)에 사용되는 폰트

message-box

대화상자에 사용되는 폰트

small-caption

작은 컨트롤 라벨에 사용되는 폰트

status-bar

윈도우 상태 표시줄에 사용되는 폰트

시스템 폰트는 전체로만 설정할 수 있으며, 폰트 패밀리, 크기, 굵기, 스타일 등 모든 속성이 동시에 설정됩니다. 이후에 개별적으로 속성을 변경할 수 있습니다. 지정된 특징의 폰트가 해당 플랫폼에 없으면, 사용자 에이전트는 적절히 대체하거나(예: ‘small-caption’ 폰트로 ‘caption’ 폰트의 작은 버전을 사용할 수 있음), 또는 사용자 에이전트 기본 폰트를 대체로 사용해야 합니다. 시스템 폰트의 개별 속성이 운영체제의 사용자 환경설정에 없다면, 해당 속성은 초기값으로 설정해야 합니다.

이 속성이 "거의" 축약 속성인 이유는, 시스템 폰트는 ‘font-family’ 자체가 아닌 이 속성으로만 지정할 수 있기 때문입니다. 따라서 ‘font’는 하위 속성의 합 이상을 가능하게 해줍니다. 하지만 ‘font-weight’ 등 개별 속성은 시스템 폰트에서 값을 받아 독립적으로 변경할 수 있습니다.

위에 열거한 시스템 폰트 키워드는 처음 위치에 있을 때만 키워드로 인식되며, 다른 위치에서는 폰트 패밀리 이름의 일부로 처리됩니다:

  font: menu;        /* 시스템 메뉴 폰트 설정 사용 */
  font: large menu;  /* "menu"라는 폰트 패밀리 사용 */

button { font: 300 italic 1.3em/1.7em "FB Armada", sans-serif }
button p { font: menu }
button p em { font-weight: bolder }

button p { font: 600 9pt Charcoal }

button p {
  font-style: normal;
  font-variant: normal;
  font-weight: 600;
  font-size: 9pt;
  line-height: normal;
  font-family: Charcoal
}

3.8. 합성 페이스 제어: font-synthesis 속성

이 속성은 사용자 에이전트가 폰트 패밀리에 볼드 또는 이탤릭 페이스가 없는 경우, 볼드 또는 오블리크(기울임) 폰트 페이스를 합성할 수 있는지 제어합니다. ‘weight’가 지정되지 않으면, 사용자 에이전트는 볼드 페이스를 합성하지 않아야 하며, ‘style’이 지정되지 않으면 이탤릭 페이스를 합성하지 않아야 합니다. ‘none’ 값을 사용하면 모든 합성 페이스가 금지됩니다.

*:lang(ar) { font-synthesis: none; }

4. 폰트 리소스

4.1. @font-face 규칙

@font-face 규칙은 폰트에 연결할 수 있으며, 필요할 때 자동으로 가져와서 활성화합니다. 이를 통해 저자는 특정 플랫폼에 설치된 폰트 집합에 제한되지 않고, 페이지 디자인 목표에 가장 근접한 폰트를 선택할 수 있습니다. 일련의 폰트 디스크립터는 폰트 리소스의 위치(로컬 또는 외부)와 개별 페이스의 스타일 특성을 정의합니다. 여러 @font-face 규칙을 사용해 다양한 페이스를 가진 폰트 패밀리를 구성할 수 있습니다. CSS 폰트 매칭 규칙을 이용해 사용자 에이전트는 필요한 페이스만 선택적으로 다운로드할 수 있습니다.

@font-face 규칙은 @font-face at-키워드와 디스크립터 선언 블록으로 구성됩니다. 문법적으로 이 명세는 다음과 같은 생산식을 정의합니다:

font_face_rule
  : FONT_FACE_SYM S* '{' S* descriptor_declaration? [ ';' S* descriptor_declaration? ]* '}' S*
  ;

descriptor_declaration
  : property ':' S* expr
  ;

다음과 같은 새로운 정의가 도입되었습니다:

-    -|\\0{0,4}2d(\r\n|[ \t\r\n\f])?
F    f|\\0{0,4}(46|66)(\r\n|[ \t\r\n\f])?

다음과 같은 새로운 토큰이 도입되었습니다:

@{F}{O}{N}{T}{-}{F}{A}{C}{E} {return FONT_FACE_SYM;}

각 @font-face 규칙은 모든 폰트 디스크립터에 대해 값을 지정하며, 명시적 또는 암시적으로 지정됩니다. 규칙에서 명시적으로 값이 지정되지 않은 경우, 이 명세에 각 디스크립터마다 나열된 초기값을 사용합니다. 이 디스크립터들은 해당 @font-face 규칙 내에서만 적용되며, 문서 언어 요소에는 적용되지 않습니다. 디스크립터가 어떤 요소에 적용되는지, 자식 요소에 상속되는지에 대한 개념이 없습니다. 하나의 @font-face 규칙에 동일한 디스크립터가 여러 번 등장하면, 마지막 선언만 사용하고 이전 선언들은 무시됩니다.

@font-face {
  font-family: Gentium;
  src: url(http://example.com/fonts/Gentium.woff);
}

p { font-family: Gentium, serif; }

일련의 @font-face 규칙은 해당 규칙이 포함된 문서에서 사용할 수 있는 폰트 집합을 정의합니다. 폰트 매칭 시, 이러한 규칙으로 정의된 폰트가 시스템에 존재하는 다른 폰트보다 우선적으로 고려됩니다.

다운로드한 폰트는 해당 폰트를 참조하는 문서에서만 사용할 수 있습니다. 폰트 활성화 과정에서, 해당 폰트를 다른 애플리케이션이나 직접 연결하지 않은 문서에서는 사용할 수 없어야 합니다. 사용자 에이전트 구현자는 시스템 폰트 폴백 절차의 일부로, 다른 문서에서 폰트가 없을 때 다운로드 폰트를 사용하면 편리할 수 있지만, 이는 보안상 취약점이 되어 한 페이지의 내용이 다른 페이지에 영향을 줄 수 있으므로 공격자가 악용할 수 있습니다. 이러한 제한은 캐싱 동작에는 영향을 주지 않으며, 폰트는 웹 리소스와 동일하게 캐싱됩니다.

이 at-규칙은 CSS의 forward-compatible 파싱 규칙을 따릅니다. 선언 블록 내의 속성처럼, 사용자 에이전트에서 지원하지 않는 디스크립터 선언은 무시해야 합니다. @font-face 규칙은 font-family와 src 디스크립터가 필요하며, 둘 중 하나라도 없으면 @font-face 규칙은 폰트 매칭 알고리즘 수행 시 고려되지 않아야 합니다.

사용자 에이전트가 플랫폼 리소스가 제한적이거나 다운로드 가능한 폰트 리소스를 비활성화하는 기능을 제공하는 경우, @font-face 규칙을 단순히 무시해야 하며, 이 명세에 정의된 개별 디스크립터의 동작은 변경하면 안 됩니다.

4.2. 폰트 패밀리: font-family 디스크립터

이 디스크립터는 모든 CSS 폰트 패밀리 이름 매칭에 사용될 폰트 패밀리 이름을 정의합니다. @font-face 규칙이 유효하려면 필수입니다. 기본 폰트 데이터에 포함된 폰트 패밀리 이름을 재정의합니다. 폰트 패밀리 이름이 사용자의 환경에서 사용 가능한 폰트 패밀리와 동일하다면, 해당 스타일시트를 사용하는 문서에서는 기본 폰트가 숨겨집니다. 이를 통해 웹 저자는 사용자 환경에 이미 존재하는 폰트 패밀리 이름과 충돌을 걱정하지 않고 자유롭게 font-family 이름을 선택할 수 있습니다. 마찬가지로, 특정 폰트 패밀리 이름에 대한 플랫폼 대체는 사용하면 안 됩니다.

4.3. 폰트 참조: src 디스크립터

이 디스크립터는 폰트 데이터를 포함하는 리소스를 지정합니다. @font-face 규칙이 유효하려면 필수입니다. 값은 외부 참조 또는 로컬 설치된 폰트 페이스 이름의 우선순위가 지정된, 콤마로 구분된 목록입니다. 폰트가 필요할 때 사용자 에이전트는 나열된 참조들을 순차적으로 확인하여, 활성화할 수 있는 첫 번째 폰트를 사용합니다. 잘못된 데이터가 포함된 폰트나 찾을 수 없는 로컬 폰트 페이스는 무시되고, 사용자 에이전트는 다음 목록의 폰트를 로드합니다.

CSS의 다른 URL과 마찬가지로, URL이 상대경로인 경우 @font-face 규칙이 포함된 스타일시트 위치를 기준으로 해석됩니다. SVG 폰트의 경우, URL은 SVG 폰트 정의를 포함하는 문서 내 요소를 가리킵니다. 요소 참조가 생략되면, 첫 번째로 정의된 폰트를 참조한 것으로 간주합니다. 마찬가지로, 여러 폰트를 포함할 수 있는 폰트 컨테이너 포맷에서는 @font-face 규칙마다 하나의 폰트만 로드해야 합니다. 프래그먼트 식별자는 로드할 폰트를 지정하는 데 사용되며, [RFC8081]에 정의된 폰트의 PostScript 이름을 사용합니다. 표준 사용자 에이전트는 프래그먼트 식별자를 알 수 없거나 지원하지 않는 경우, 해당 폰트 리소스 다운로드를 건너뛰어야 합니다. 예를 들어, OpenType 컬렉션을 지원하지 않는 구형 사용자 에이전트는 목록에서 다음 url로 이동해야 합니다.

src: url(fonts/simple.woff);       /* 스타일시트 위치 기준으로 simple.woff 로드 */
src: url(/fonts/simple.woff);      /* 절대 경로에서 simple.woff 로드 */
src: url(fonts/coll.otc#foo);      /* 컬렉션 coll.otc에서 foo 폰트 로드 */
src: url(fonts/coll.woff2#foo);    /* woff2 컬렉션 coll.woff2에서 foo 폰트 로드 */
src: url(fonts.svg#simple);        /* id가 'simple'인 SVG 폰트 로드 */

외부 참조는 URL과, 해당 URL이 참조하는 폰트 리소스의 포맷을 설명하는 선택적 힌트(format)를 포함합니다. 포맷 힌트는 잘 알려진 폰트 포맷을 나타내는 쉼표로 구분된 포맷 문자열 목록입니다. 표준 사용자 에이전트는 포맷 힌트가 지원하지 않거나 알 수 없는 폰트 포맷만 표시할 경우, 해당 폰트 리소스 다운로드를 건너뛰어야 합니다. 포맷 힌트가 없으면, 사용자 에이전트는 폰트 리소스를 다운로드해야 합니다.

/* 가능하면 WOFF2 폰트, 그 다음 WOFF, 마지막으로 OpenType 폰트 사용 */
@font-face {
  font-family: bodytext;
  src: url(ideal-sans-serif.woff2) format("woff2"),
       url(good-sans-serif.woff) format("woff"),
       url(basic-sans-serif.ttf) format("opentype");
}

이 명세에서 정의하는 포맷 문자열:

TrueType과 OpenType [OPENTYPE]의 사용이 중복되는 경우가 많으므로, "truetype"과 "opentype" 포맷 힌트는 동의어로 간주해야 하며, "opentype" 포맷 힌트가 폰트에 Postscript CFF 스타일 글리프 데이터나 OpenType 레이아웃 정보가 포함되어 있음을 의미하지 않습니다(부록 A 참고).

저자가 특정 폰트가 로컬에 있으면 사용하고, 없으면 다운로드받고 싶을 때는 local()을 사용할 수 있습니다. <font-face-name> 인자는 local()에 전달되는 포맷별 문자열로, 더 큰 패밀리 내에서 개별 폰트 페이스를 고유하게 식별합니다. <font-face-name>의 문법은 "local("과 ")"로 둘러싸인 고유 폰트 페이스 이름입니다. 이름은 따옴표로 감쌀 수도 있고, 따옴표 없이 식별자 시퀀스로 지정하면 공백으로 구분된 식별자들을 단일 공백으로 연결해 문자열로 변환합니다.

/* Gentium의 일반 페이스 */
@font-face {
  font-family: MyGentium;
  src: local(Gentium),    /* 로컬 Gentium 사용 */
       url(Gentium.woff); /* 없으면 다운로드 */
}

OpenType과 TrueType 폰트에서는 이 문자열이 로컬 폰트의 Postscript 이름 또는 전체 폰트 이름과만 일치하도록 사용됩니다. 어떤 이름이 사용되는지는 플랫폼과 폰트마다 다르므로, 저자는 모든 플랫폼에서 올바르게 매칭되도록 두 이름을 모두 포함하는 것이 좋습니다. 특정 폰트 이름에 대한 플랫폼 대체는 사용하면 안 됩니다.

/* Gentium의 볼드 페이스 */
@font-face {
  font-family: MyGentium;
  src: local(Gentium Bold),    /* 전체 폰트 이름 */
       local(Gentium-Bold),    /* Postscript 이름 */
       url(GentiumBold.woff);  /* 없으면 다운로드 */
  font-weight: bold;
}

@font-face 규칙이 패밀리 내 단일 폰트의 특성을 지정하는 것처럼, local()에 사용되는 고유 이름도 개별 폰트만 지정하며 전체 폰트 패밀리를 지정하지 않습니다. OpenType 폰트 데이터 기준으로, Postscript 이름은 폰트의 name 테이블에서 nameID = 6인 레코드에 있습니다([OPENTYPE] 참고). Postscript 이름은 OSX와 Windows의 Postscript CFF 폰트에서 널리 사용되는 키입니다. 전체 폰트 이름(nameID = 4)은 Windows에서 TrueType 글리프가 있는 폰트의 고유 키로 사용됩니다.

전체 폰트 이름에 여러 로컬라이즈가 있을 경우, US 영어 버전을 사용합니다(Windows는 language ID = 0x409, Macintosh는 language ID = 0) 또는 US 영어 이름이 없으면 첫 번째 로컬라이즈를 사용합니다(OpenType 명세에서는 모든 폰트에 최소한 US 영어 이름을 포함할 것을 권장). 시스템 로케일이 네덜란드어일 때 네덜란드어 이름으로 매칭하는 것은 표준에 부합하지 않습니다. 이는 영어를 우선하려는 것이 아니라, 버전과 OS 로컬라이즈마다 폰트 스타일 이름("Bold" 등)이 다양하게 번역되므로 일관성 없는 매칭을 피하기 위함입니다. 패밀리 이름(nameID = 1)과 스타일 이름(nameID = 2)을 연결해 매칭하는 것도 표준에 부합하지 않습니다.

이 방식은 더 큰 패밀리 내에서 참조할 수 없는 페이스를 참조하는 것도 가능하게 해줍니다.

@font-face {
  font-family: Headline;
  src: local(Futura-Medium),
       url(fonts.svg#MyGeometricModern) format("svg");
}

@font-face {
  font-family: jpgothic;
  src: local(HiraKakuPro-W3), local(Meiryo), local(IPAPGothic);
}

@font-face {
  font-family: Hoefler Text Ornaments;
  /* Hoefler Text Regular와 동일한 폰트 속성 */
  src: local(HoeflerText-Ornaments);
}

@font-face {
  font-family: SectionHeader;
  src: local("Arial Lihavoitu");  /* Arial Bold의 핀란드어 전체 이름, 매칭 실패해야 함 */
  font-weight: bold;
}

h2 { font-family: SectionHeader, serif; }

@font-face {
  font-family: MainText;
  src: url(gentium.eot);                     /* 구형 사용자 에이전트용 */
  src: local("Gentium"), url(gentium.woff);  /* src 정의 오버라이드 */
}

4.4. 폰트 속성 디스크립터: font-style, font-weight, font-stretch 디스크립터

이 디스크립터들은 폰트 페이스의 특성을 정의하며, 스타일을 특정 페이스에 매칭하는 과정에서 사용됩니다. 여러 @font-face 규칙으로 구성된 폰트 패밀리의 경우, 사용자 에이전트는 패밀리 내 모든 페이스를 다운로드하거나 실제 문서에서 사용하는 스타일에 맞는 페이스만 이 디스크립터를 활용해 선택적으로 다운로드할 수 있습니다. 이 디스크립터의 값들은 해당 폰트 속성의 값과 동일하나, 상대 키워드인 ‘bolder’와 ‘lighter’는 사용할 수 없습니다. 디스크립터가 생략된 경우, 초기값이 적용됩니다.

이 폰트 페이스 스타일 속성의 값은 기본 폰트 데이터가 암시하는 스타일 대신 사용됩니다. 이를 통해 저자는 원본 폰트 데이터의 배열과 관계없이 페이스를 유연하게 조합할 수 있습니다. 합성 볼드 및 오블리크를 구현하는 사용자 에이전트는 폰트 디스크립터가 암시할 때만 합성 스타일을 적용해야 하며, 폰트 데이터에서 암시된 스타일만으로 적용하면 안 됩니다.

이 섹션에서 정의된 폰트 디스크립터는 특정 패밀리에 대해 @font-face 규칙으로 정의된 폰트 집합 내에서 폰트를 선택하는 데 사용됩니다.

단일 일반 페이스만 포함된 패밀리를 예로 들면:

@font-face {
  font-family: BaskervilleSimple;
  src: url(baskerville-regular.woff);
}

스타일이 없는 텍스트는 @font-face 규칙에서 정의된 일반 페이스로 표시됩니다:

하지만 이탤릭 텍스트는 별도 이탤릭 페이스가 정의되어 있지 않으므로, 대부분의 사용자 에이전트에서 일반 페이스의 글리프를 합성하여 기울여 표시합니다:

이번에는 실제 이탤릭 페이스가 정의된 패밀리를 보겠습니다:

@font-face {
  font-family: BaskervilleFull;
  src: url(baskerville-regular.woff);
}

@font-face {
  font-family: BaskervilleFull;
  src: url(baskerville-italic.woff);
  font-style: italic;
}

두 번째 @font-face 규칙은 폰트 리소스 baskerville-italic.woff에 대해 보통 굵기, 보통 너비, 이탤릭 스타일 속성을 정의합니다. 이탤릭 텍스트를 표시할 때, 사용자 에이전트는 이 폰트를 사용하며 이는 이탤릭 텍스트에 가장 가까운 매칭이기 때문입니다. 따라서 텍스트는 타입 디자이너가 설계한 글리프로 표시되며, 일반 페이스에서 합성된 기울임 글리프가 사용되지 않습니다:

특정 페이스를 선택하는 과정에 대한 완전한 설명은 폰트 매칭 섹션을 참고하세요.

4.5. 문자 범위: unicode-range 디스크립터

이 디스크립터는 해당 폰트 페이스에서 지원될 수 있는 유니코드 [UNICODE] 코드포인트 집합을 정의합니다. 디스크립터 값은 유니코드 범위(<urange>) 값들의 콤마 구분 목록입니다. 이 범위들의 합집합이, 특정 텍스트 구간에 대해 폰트 리소스를 다운로드할지 판단할 때 사용자 에이전트에게 힌트를 제공합니다.

각 <urange> 값은 "U+" 또는 "u+" 프리픽스와 아래 세 가지 형식 중 하나의 코드포인트 범위로 구성된 UNICODE-RANGE 토큰입니다. 아래 형식에 맞지 않는 범위는 무효이며 선언이 무시됩니다.

단일 코드포인트 (예: U+416)

유니코드 코드포인트, 1~6자리 16진수로 표현

구간 범위 (예: U+400-4ff)

하이픈으로 구분된 두 유니코드 코드포인트로, 구간의 시작과 끝(포함)을 표시

와일드카드 범위 (예: U+4??)

마지막에 ‘?’가 붙은 경우, 해당 위치에 임의의 16진수가 올 수 있음을 의미하는 코드포인트 집합

개별 코드포인트는 유니코드 문자 코드포인트 [UNICODE]에 대응하는 16진수로 작성합니다. 유니코드 코드포인트 값은 0에서 10FFFF까지 포함해야 합니다. 코드포인트의 숫자 값은 ASCII 대소문자를 구분하지 않습니다. 구간 범위의 경우, 시작과 끝 코드포인트는 위 범위 내에 있어야 하며, 끝 코드포인트는 시작 코드포인트보다 크거나 같아야 합니다.

‘?’로 지정된 와일드카드 범위에서 처음 숫자가 없는 경우("U+???")는 유효하며, 처음 숫자가 0인 와일드카드 범위("U+0???" = "U+0000-0FFF")와 동일합니다. 유니코드 범위를 벗어난 와일드카드 범위는 무효입니다. 이 때문에, 마지막에 붙는 ‘?’ 와일드카드 문자의 최대 개수는 5개입니다.

‘unicode-range’ 디스크립터 선언의 유니코드 범위 목록 내에서는 범위가 겹칠 수 있습니다. 이들 범위의 합집합이 해당 폰트가 사용될 수 있는 코드포인트 집합을 정의합니다. 사용자 에이전트는 이 집합 밖의 코드포인트에 대해 해당 폰트를 다운로드하거나 사용하면 안 됩니다. 사용자 에이전트는 범위 목록을 동일한 코드포인트 집합을 나타내는 형태로 정규화할 수 있습니다.

연관된 폰트는 ‘unicode-range’ 디스크립터로 정의된 전체 코드포인트 집합의 글리프를 포함하지 않을 수도 있습니다. 폰트가 사용될 때, effective character map은 ‘unicode-range’로 정의된 코드포인트와 폰트의 character map의 교집합입니다. 이를 통해 저자는 실제 폰트가 지원하는 정확한 범위를 신경 쓰지 않고 넓은 범위로 지원 범위를 정의할 수 있습니다.

4.6. 문자 범위로 복합 폰트 정의하기

동일한 패밀리와 스타일 디스크립터 값을 가지면서 서로 다른 유니코드 범위를 가진 여러 @font-face 규칙을 사용하면, 다른 스크립트마다 서로 다른 폰트의 글리프를 섞어 쓰는 복합 폰트를 만들 수 있습니다. 라틴, 그리스, 키릴 문자 등 단일 스크립트만 지원하는 폰트를 결합할 수도 있고, 자주 사용하는 문자와 덜 사용하는 문자를 분리해 저자가 폰트를 나누는 데에도 활용할 수 있습니다. 사용자 에이전트는 필요한 폰트만 가져오기 때문에 페이지 대역폭을 줄일 수 있습니다.

동일한 패밀리와 스타일 디스크립터 값을 가진 @font-face 규칙 집합에서 유니코드 범위가 겹치는 경우, 규칙은 선언된 역순으로 적용됩니다. 마지막에 정의된 규칙이 특정 문자에 대해 가장 먼저 확인됩니다.

특정 언어나 문자에 대한 예시 범위들:

unicode-range: U+A5;

단일 코드포인트, 엔/위안 기호

unicode-range: U+0-7F;

기본 ASCII 문자 코드 범위

unicode-range: U+590-5ff;

히브리어 문자 코드 범위

unicode-range: U+A5, U+4E00-9FFF, U+30??, U+FF00-FF9F;

일본어 한자, 히라가나, 가타카나 문자 및 엔/위안 기호 코드 범위

@font-face {
  font-family: BBCBengali;
  src: url(fonts/BBCBengali.woff) format("woff");
  unicode-range: U+00-FF, U+980-9FF;
}

@font-face {
  font-family: STIXGeneral;
  src: local(STIXGeneral), url(/stixfonts/STIXGeneral.otf);
  unicode-range: U+000-49F, U+2000-27FF, U+2900-2BFF, U+1D400-1D7FF;
}

@font-face {
  font-family: JapaneseWithGentium;
  src: local(MSMincho);
  /* 범위 미지정, 전체 범위가 기본값 */
}

@font-face {
  font-family: JapaneseWithGentium;
  src: url(../fonts/Gentium.woff);
  unicode-range: U+0-2FF;
}

/* 폴백 폰트 - 크기: 4.5MB */
@font-face {
  font-family: DroidSans;
  src: url(DroidSansFallback.woff);
  /* 범위 미지정, 전체 범위가 기본값 */
}

/* 일본어 글리프 - 크기: 1.2MB */
@font-face {
  font-family: DroidSans;
  src: url(DroidSansJapanese.woff);
  unicode-range: U+3000-9FFF, U+ff??;
}

/* 라틴, 그리스, 키릴 문자 및 일부
   기호와 구두점 - 크기: 190KB */
@font-face {
  font-family: DroidSans;
  src: url(DroidSans.woff);
  unicode-range: U+000-5FF, U+1e00-1fff, U+2000-2300;
}

body { font-family: DroidSans; }

<p>This is that</p>

<p>This &#x21e8; that<p>

4.7. 폰트 기능: font-feature-settings 디스크립터

이 디스크립터는 @font-face 규칙으로 정의된 폰트가 렌더링될 때 적용되는 초기 설정을 정의합니다. 폰트 선택에는 영향을 주지 않습니다. 값은 아래에서 정의된 해당 ‘font-feature-settings’ 속성과 동일하지만, ‘inherit’ 값은 제외합니다. 여러 폰트 기능 디스크립터 또는 속성이 사용될 때, 텍스트 렌더링에 대한 누적 효과는 아래 폰트 기능 해상도 섹션에서 설명합니다.

4.8. 폰트 로딩 가이드라인

@font-face 규칙은 문서에서 사용될 때만 폰트 리소스를 지연 로딩(lazy loading)할 수 있도록 설계되었습니다. 스타일시트에 라이브러리의 모든 폰트에 대한 @font-face 규칙을 포함시켜도, 사용자 에이전트는 실제로 해당 페이지에 적용되는 스타일 규칙에서 참조되는 폰트만 다운로드해야 합니다. 페이지에서 사용 여부와 무관하게 모든 @font-face 규칙에 정의된 폰트를 다운로드하는 사용자 에이전트는 표준에 부합하지 않습니다. 문자 폴백 상황에서 폰트가 다운로드될 수 있는 경우, 해당 텍스트 구간의 ‘font-family’ 계산값에 포함되어 있으면 폰트를 다운로드해도 됩니다.

@font-face {
  font-family: GeometricModern;
  src: url(font.woff);
}

p {
  /* p 요소가 있는 페이지에서만 폰트가 다운로드됨 */
  font-family: GeometricModern, sans-serif;
}

h2 {
  /* Futura가 로컬에 있어도 h2 요소가 있는 페이지에서는 폰트가 다운로드될 수 있음 */
  font-family: Futura, GeometricModern, sans-serif;
}

텍스트 내용이 다운로드 폰트보다 먼저 로드되는 경우, 사용자 에이전트는 다운로드 폰트 리소스가 없을 때 렌더링되는 것처럼 텍스트를 표시하거나, 폴백 폰트로 투명하게 렌더링해 폴백 폰트의 "깜빡임(flash)"을 방지할 수 있습니다. 폰트 다운로드가 실패하면 사용자 에이전트는 텍스트를 반드시 표시해야 하며, 투명 텍스트만 남기는 것은 표준에 부합하지 않습니다. 저자는 가능한 큰 페이지 재배치(reflow)를 피하기 위해, 다운로드 폰트와 메트릭이 비슷한 폴백 폰트를 폰트 목록에 추가하는 것이 좋습니다.

4.9. 폰트 가져오기 요구사항

폰트 로드를 위해, 사용자 에이전트는 @font-face 규칙 내에 정의된 URL에 대해 잠재적으로 CORS가 활성화된 fetch 메서드를 [FETCH] 명세에 따라 사용해야 합니다. 가져오기 시, 사용자 에이전트는 "Anonymous" 모드를 사용하고, 리퍼러 소스를 스타일시트의 URL로 설정하며, 오리진을 포함 문서의 URL로 설정해야 합니다.

이것이 저자에게 의미하는 바는, 저자가 교차 오리진 로드를 명시적으로 허용하는 조치를 취하지 않는 한 폰트는 일반적으로 교차 오리진으로 로드되지 않는다는 점입니다. 사이트는 Access-Control-Allow-Origin HTTP 헤더를 사용하여 폰트 데이터의 교차 사이트 로딩을 명시적으로 허용할 수 있습니다. 다른 스킴의 경우, 잠재적으로 CORS가 활성화된 fetch 메서드가 허용하는 범위를 제외하고 교차 오리진 로딩을 위한 명시적 메커니즘은 정의되거나 요구되지 않습니다.

/* 동일 오리진(즉, 도메인, 스킴, 포트가 문서와 일치) */
src: url(fonts/simple.woff);

/* 리디렉션 없는 data url은 동일 오리진으로 처리 */
src: url("data:application/font-woff;base64,...");

/* 교차 오리진, 다른 도메인 */
/* Access-Control-Allow-Origin 응답 헤더가 '*'로 설정됨 */
src: url(http://another.example.com/fonts/simple.woff);

/* 교차 오리진, 다른 스킴 */
/* 응답에 Access-Control-xxx 헤더 없음 */
src: url(https://example.com/fonts/simple.woff);

/* 교차 오리진, 다른 도메인 */
/* 응답에 Access-Control-xxx 헤더 없음 */
src: url(http://another.example.com/fonts/simple.woff);

5. 폰트 매칭 알고리즘

아래 알고리즘은 폰트가 개별 텍스트 구간과 어떻게 연결되는지 설명합니다. 구간의 각 문자에 대해 폰트 패밀리가 선택되고, 해당 문자를 위한 글리프를 포함하는 특정 폰트 페이스가 선택됩니다.

5.1. 폰트 패밀리 이름의 대소문자 구분

아래에 설명된 폰트 매칭 알고리즘의 일부로서, 사용자 에이전트는 스타일 규칙에서 사용된 폰트 패밀리 이름을 환경에 설치된 실제 폰트 패밀리 이름이나 @font-face 규칙에서 정의된 폰트 패밀리 이름과 매칭해야 합니다. 사용자 에이전트는 이러한 이름을 대소문자 구분 없이 매칭해야 하며, 유니코드 명세 [UNICODE]에서 설명된 "Default Caseless Matching" 알고리즘을 사용해야 합니다. 이 알고리즘은 3.13절 "Default Case Algorithms"에서 자세히 설명되어 있습니다. 구체적으로, 문자열을 정규화하거나 언어별 맞춤을 적용하지 않고 알고리즘을 적용해야 합니다. 이 알고리즘에서 지정한 케이스 폴딩 방법은 유니코드 문자 데이터베이스의 CaseFolding.txt 파일에서 상태 필드가 ‘C’ 또는 ‘F’인 케이스 매핑을 사용합니다 [UNICODE].

저자에게 이것은, 폰트 패밀리 이름이 플랫폼 폰트에 있든 스타일시트의 @font-face 규칙에 있든, 대소문자 구분 없이 매칭된다는 것을 의미합니다. 특히 결합 문자(다이아크리틱 등)를 사용할 경우, 실제 폰트 패밀리 이름과 일치하는 문자 시퀀스를 사용해야 합니다. 예를 들어, 소문자 a(U+0061) 뒤에 결합 링(U+030A)이 있는 패밀리 이름은, 모양은 같지만 결합 시퀀스 대신 미리 조합된 소문자 a-ring(U+00E5)을 사용하는 이름과 일치하지 않습니다.

구현자는 주어진 대소문자 구분 없는 문자열 비교 구현이 이 알고리즘을 정확히 사용하는지 반드시 확인해야 하며, 플랫폼의 문자열 매칭 루틴이 이를 따를 것이라 단정해서는 안 됩니다. 많은 경우 로케일별 동작이나 일부 문자열 정규화를 사용하기 때문입니다 [UAX15].

5.2. 폰트 스타일 매칭

텍스트 구간의 특정 문자를 위한 폰트를 선택하는 과정은 ‘font-family’ 속성에 명시된 폰트 패밀리들을 반복하며, 다른 폰트 속성에 기반해 적절한 스타일의 폰트 페이스를 선택한 뒤, 해당 문자 글리프가 존재하는지 확인하는 것으로 이루어집니다. 이는 폰트의 character map을 사용해 이루어지며, 해당 문자에 대한 기본 글리프로 매핑됩니다. 폰트가 주어진 문자를 지원한다고 간주되려면 (1) 문자가 폰트의 character map에 포함되어 있고, (2) 포함된 스크립트에서 요구한다면 해당 문자에 대한 셰이핑 정보가 있어야 합니다.

일부 레거시 폰트는 character map에 특정 문자를 포함하지만, 해당 텍스트 구간을 올바르게 렌더링하는 데 필요한 셰이핑 정보(예: OpenType 레이아웃 테이블 또는 Graphite 테이블)가 없을 수 있습니다.

기본 문자 뒤에 결합 문자가 이어지는 코드포인트 시퀀스는 약간 다르게 처리되며, 아래 클러스터 매칭 섹션을 참고하세요.

이 과정에서, 주어진 폰트 패밀리의 기본 페이스는 모든 폰트 스타일 속성이 초기값으로 설정된 경우 선택될 페이스로 정의됩니다.

1. 주어진 요소에 대해 계산된 폰트 속성 값을 사용해, 사용자 에이전트는 ‘font-family’ 속성에 지정된 첫 번째 패밀리 이름부터 시작합니다.
2. 패밀리 이름이 일반 패밀리 키워드인 경우, 사용자 에이전트는 사용할 적절한 폰트 패밀리 이름을 조회합니다. 사용자 에이전트는 포함 요소의 언어나 문자 유니코드 범위를 기반으로 일반 폰트 패밀리를 선택할 수 있습니다.
3. 그 외의 패밀리 이름에 대해서는, 사용자 에이전트가 @font-face 규칙으로 정의된 폰트와 시스템 폰트에서 패밀리 이름을 찾으려 시도하며, 위 섹션에서 설명한 대소문자 구분 없는 비교를 사용해 매칭합니다. 여러 로컬라이즈된 폰트 패밀리 이름이 있는 시스템에서는, 사용자 에이전트는 시스템 로케일이나 플랫폼 API와 관계없이 모든 이름을 매칭해야 합니다. @font-face 규칙에서 특정 페이스에 대해 정의된 폰트 리소스가 없거나 잘못된 폰트 데이터가 포함되어 있다면, 해당 페이스는 패밀리에 없는 것으로 간주해야 합니다. @font-face 규칙으로 정의된 패밀리에 페이스가 하나도 없으면, 해당 패밀리는 없는 것으로 간주해야 하며, 같은 이름의 플랫폼 폰트와 매칭하면 안 됩니다.
4. 폰트 패밀리와 매칭되면, 사용자 에이전트는 해당 패밀리의 폰트 페이스 집합을 조합하고, 아래에서 제시한 순서대로 다른 폰트 속성을 사용해 단일 페이스로 범위를 좁힙니다. 동일한 폰트 디스크립터 값을 가지지만 ‘unicode-range’ 값이 다른 여러 @font-face 규칙으로 정의된 페이스 집합은 이 단계에서 하나의 복합 페이스로 간주합니다:
   1. ‘font-stretch’가 먼저 시도됩니다. 매칭 집합에 ‘font-stretch’ 값과 일치하는 너비 값의 페이스가 있으면, 다른 너비의 페이스는 매칭 집합에서 제외합니다. 정확히 일치하는 너비가 없으면 가장 가까운 너비를 대신 사용합니다. ‘font-stretch’ 값이 ‘normal’ 또는 condensed 계열 값이면, 좁은 너비부터 우선 확인하고, 그 다음 넓은 너비를 확인합니다. expanded 계열 값이면 넓은 너비부터 확인하고, 그 다음 좁은 너비를 확인합니다. 가장 가까운 너비가 결정되면, 다른 너비 페이스는 제외합니다.
   2. ‘font-style’가 다음으로 시도됩니다. ‘font-style’ 값이 ‘italic’이면, italic 페이스를 먼저, 그 다음 oblique, 그 다음 normal 페이스를 확인합니다. 값이 ‘oblique’이면, oblique 페이스부터, 그 다음 italic, 그 다음 normal 페이스를 확인합니다. 값이 ‘normal’이면, normal 페이스부터, 그 다음 oblique, 그 다음 italic 페이스를 확인합니다. 다른 스타일 값의 페이스는 매칭 집합에서 제외합니다. 사용자 에이전트는 플랫폼 폰트 패밀리 내에서 italic과 oblique 페이스를 구분해서 처리해도 되지만 필수는 아니며, 모든 italic 또는 oblique 페이스를 italic 페이스로 취급할 수 있습니다. 그러나 @font-face 규칙으로 정의된 폰트 패밀리 내에서는 ‘font-style’ 디스크립터 값으로 italic과 oblique 페이스를 반드시 구분해야 합니다. italic이나 oblique 페이스가 없는 패밀리에서는, ‘font-synthesis’ 속성 값이 허용하면, 사용자 에이전트가 인위적으로 oblique 페이스를 합성할 수 있습니다.
   3. ‘font-weight’가 다음으로 매칭되어, 항상 매칭 집합을 단일 폰트 페이스로 줄입니다. bolder/lighter 상대적 굵기가 사용된 경우, ‘font-weight’ 속성 정의대로 상속된 굵기에 따라 유효 굵기를 계산합니다. 원하는 굵기와 위 단계 후 매칭 집합의 페이스 굵기를 비교해, 원하는 굵기가 있으면 해당 페이스가 매칭됩니다. 없으면 아래 규칙을 사용해 굵기를 선택합니다:
      • 원하는 굵기가 400보다 작으면, 원하는 굵기보다 작은 값들을 내림차순으로 확인 후, 원하는 굵기보다 큰 값들을 오름차순으로 확인해 일치할 때까지 진행합니다.
      • 원하는 굵기가 500보다 크면, 원하는 굵기보다 큰 값들을 오름차순으로 확인 후, 원하는 굵기보다 작은 값들을 내림차순으로 확인합니다.
      • 원하는 굵기가 400이면, 500부터 확인하고 이후 400 미만 굵기에 대한 규칙을 적용합니다.
      • 원하는 굵기가 500이면, 400부터 확인하고 이후 400 미만 굵기 규칙을 적용합니다.
   4. ‘font-size’는 UA에 따라 허용 오차 범위 내에서 매칭되어야 합니다. (확장폰트의 경우 보통 가까운 정수 픽셀로 반올림하고, 비트맵 폰트는 오차가 20%까지 클 수 있음.) 다른 속성(‘em’ 등)에서 추가 연산 시, 실제 사용된 ‘font-size’ 값이 기준이 됩니다.

5. 매칭된 페이스가 @font-face 규칙으로 정의된 경우, 사용자 에이전트는 아래 절차로 단일 폰트를 선택해야 합니다:

   1. 폰트 리소스가 아직 로드되지 않았고, ‘unicode-range’ 디스크립터 값의 문자 범위에 해당 문자가 포함되어 있으면, 폰트를 로드합니다.
   2. 다운로드 후, effective character map이 해당 문자를 지원하면, 해당 폰트를 선택합니다.

   매칭된 페이스가 복합 페이스인 경우, 사용자 에이전트는 @font-face 규칙이 정의된 역순으로 각 페이스에 대해 위 절차를 적용해야 합니다.

   다운로드 중에는, 사용자 에이전트가 폰트 다운로드를 기다리거나, 대체 폰트 메트릭으로 먼저 렌더링한 뒤 폰트가 다운로드된 후 다시 렌더링할 수 있습니다.

6. 매칭되는 페이스가 없거나 선택된 페이스에 렌더링할 문자의 글리프가 없으면, 다음 패밀리 이름을 선택하고 앞의 세 단계를 반복합니다. 패밀리 내 다른 페이스의 글리프는 고려하지 않습니다. 단, 사용자 에이전트는 해당 글리프를 지원하고 ‘font-synthesis’ 속성 값이 허용하면, 기본 페이스의 인위적 기울임 버전을 대체로 사용할 수 있습니다. 예를 들어, regular 페이스의 인위적 이탤릭 버전을 사용할 수 있습니다(italic 페이스가 아랍어 글리프를 지원하지 않는 경우 등).

7. 평가할 폰트 패밀리가 더 없고 매칭 페이스를 찾지 못한 경우, 사용자 에이전트는 시스템 폰트 폴백 절차를 수행해 렌더링할 문자에 가장 가까운 매칭을 찾습니다. 이 절차 결과는 사용자 에이전트마다 다를 수 있습니다.
8. 어떤 폰트로도 특정 문자를 표시할 수 없으면, 사용자 에이전트는 문자가 표시되지 않음을 명확히 나타내야 하며, 누락된 글리프의 기호(예: Last Resort Font 사용)나 기본 폰트의 누락 문자 글리프를 표시해야 합니다.

이 과정의 최적화는, 구현이 알고리즘을 정확히 따른 것처럼 동작한다면 허용됩니다. 매칭은 명확히 정의된 순서로 진행되어, 동일한 폰트와 렌더링 기술을 가진 경우 사용자 에이전트 간 결과가 최대한 일관되게 됩니다.

최초 사용 가능 폰트는, 예를 들어 ‘ex’, ‘ch’ 같은 폰트 상대 길이 정의나 ‘line-height’ 속성 정의에서 사용되며, ‘font-family’ 목록에서 U+0020(공백) 문자를 매칭할 수 있는 최초의 폰트(또는 사용 가능 폰트가 없으면 사용자 에이전트의 기본 폰트)로 정의됩니다.

5.3. 클러스터 매칭

텍스트에 결합 부호 등 문자가 포함된 경우, 기본 문자를 마크와 동일한 폰트로 렌더링하는 것이 이상적입니다. 이렇게 하면 마크의 위치가 정확해집니다. 이 때문에 클러스터의 폰트 매칭 알고리즘은 단일 문자 매칭보다 더 특화되어 있습니다. 변형 선택자(variation selector)가 포함된 시퀀스라면, 사용자 에이전트는 항상 시스템 폰트 폴백을 시도해 해당 문자에 맞는 글리프를 찾아본 뒤, 기본 문자의 기본 글리프를 사용합니다.

결합 부호나 기타 수정자가 포함된 코드포인트 시퀀스는 그래프 클러스터(grapheme cluster)라고 하며([CSS-TEXT-3], [UAX29] 참고), 기본 문자 b와 결합 문자 시퀀스 c1, c2…로 구성된 클러스터는 아래 단계로 매칭됩니다:

1. 폰트 목록의 각 패밀리에 대해, 앞 섹션에서 정의한 스타일 선택 규칙을 사용해 페이스를 선택합니다.
   1. 시퀀스 b + c1 + c2 …의 모든 문자가 해당 폰트에서 완전히 지원되면, 해당 폰트로 시퀀스를 렌더링합니다.
   2. 여러 코드포인트 시퀀스가 단일 문자와 정규적으로 동일하고, 폰트가 해당 문자를 지원한다면, 해당 폰트로 시퀀스를 렌더링하며, 클러스터 전체에 정규적으로 동일한 문자에 연결된 글리프를 사용합니다.
2. 1단계에서 폰트를 찾지 못한 경우:
   1. c1이 변형 선택자(variation selector)라면, 시스템 폴백을 사용해 b + c1 전체 시퀀스를 지원하는 폰트를 찾아야 합니다. 시스템에 전체 시퀀스를 지원하는 폰트가 없으면, 단일 문자 b만 단일 문자 매칭 규칙으로 매칭하고 변형 선택자는 무시합니다. 참고: 변형 선택자가 둘 이상인 시퀀스는 인코딩 오류로 처리하며, 뒤의 선택자는 무시합니다 [UNICODE].
   2. 그 외의 경우, 사용자 에이전트는 시스템 폰트 폴백을 사용해 전체 클러스터를 지원하는 폰트를 선택할 수 있습니다.
3. 2단계에서 폰트를 찾지 못한 경우, 1단계에서 매칭된 시퀀스를 사용해 폰트 목록에서 완전히 지원되는 가장 긴 시퀀스를 결정하고, 남은 결합 문자는 단일 문자 매칭 규칙으로 별도 매칭을 시도합니다.

5.4. 문자 처리 문제

CSS 폰트 매칭은 항상 유니코드 문자 [UNICODE]를 포함하는 텍스트 런에서 수행되므로, 레거시 인코딩을 사용하는 문서는 폰트 매칭 전에 트랜스코딩된 것으로 간주합니다. 레거시 인코딩과 유니코드용 character map을 모두 포함한 폰트의 경우, 레거시 인코딩 character map의 내용은 폰트 매칭 결과에 아무런 영향을 주지 않아야 합니다.

폰트 매칭 과정은 텍스트 런이 정규화(normalized) 또는 비정규화(denormalized) 형태임을 가정하지 않습니다([CHARMOD-NORM] 참고). 폰트는 조합된(precomposed) 형태만 지원하고, 기본 문자+결합 마크의 분해(decomposed) 시퀀스는 지원하지 않을 수 있습니다. 저자는 자신의 콘텐츠에 맞는 폰트를 항상 신중히 선택해야 하며, 콘텐츠에 정규화된 문자 스트림이 포함되는지 여부까지 고려해야 합니다.

특정 문자가 Private-Use Area 유니코드 코드포인트인 경우, 사용자 에이전트는 ‘font-family’ 목록에 명시된, 일반 패밀리가 아닌 폰트 패밀리만 매칭해야 합니다. ‘font-family’ 목록의 패밀리 중 해당 코드포인트의 글리프가 없으면, 사용자 에이전트는 해당 문자에 대해 시스템 폰트 폴백을 시도하지 않고 누락된 글리프 기호를 표시해야 합니다. 대체 문자 U+FFFD를 매칭할 때는, 사용자 에이전트가 폰트 매칭 과정을 생략하고 즉시 누락 글리프 기호를 표시할 수 있으며, 폰트 매칭 과정에서 선택된 폰트의 글리프를 반드시 표시할 필요는 없습니다.

일반적으로, 주어진 패밀리의 폰트들은 모두 동일하거나 유사한 character map을 가집니다. 여기서 설명하는 과정은 character map이 크게 다른 페이스가 포함된 패밀리도 처리할 수 있게 설계되었습니다. 하지만 저자는 이런 패밀리 사용이 예기치 않은 결과로 이어질 수 있음을 주의해야 합니다.

5.5. CSS 2.1 이후 폰트 매칭 변경사항

위 알고리즘은 CSS 2.1과 여러 주요 부분에서 다릅니다. 이러한 변경은 다양한 사용자 에이전트 구현에서 실제 폰트 매칭 동작을 더 잘 반영하기 위해 도입되었습니다.

CSS 2.1의 폰트 매칭 알고리즘과 비교한 차이점:

• 알고리즘에 font-stretch 매칭이 포함됨
• 가능한 모든 font-style 매칭 시나리오가 구분됨
• Small-caps 폰트는 폰트 매칭 과정에서 매칭하지 않으며, 이제는 폰트 기능(font features)으로 처리함
• 유니코드 변형 선택자(variation selector) 매칭이 필수
• 클러스터 시퀀스는 단위로 매칭됨

5.6. 폰트 매칭 예시

*:lang(ja) { font: 900 14pt/16pt "Heisei Mincho W9", serif; }
*:lang(zh-Hant-TW) { font: 800 14pt/16.5pt "Li Sung", serif; }

6. 폰트 기능 속성

최신 폰트 기술은 다양한 고급 타이포그래피 및 언어별 폰트 기능을 지원합니다. 이러한 기능을 이용하면, 하나의 폰트로 광범위한 결합문자, 문맥 및 스타일 대체, 표 형식 및 올드스타일 숫자, 스몰캡, 자동 분수, 스와시, 특정 언어용 대체 글리프 등을 제공할 수 있습니다. 저자가 이러한 폰트 기능을 제어할 수 있도록 ‘font-variant’ 속성은 CSS3에서 확장되었습니다. 이제 스타일적 폰트 기능을 제어하는 여러 속성의 축약형 역할을 합니다.

6.1. 글리프 선택 및 위치 지정

이 섹션은 규범적이지 않습니다

라틴 텍스트를 표시하는 단순한 폰트는 매우 기본적인 처리 모델을 사용합니다. 폰트에는 각 문자를 해당 글리프로 매핑하는 character map이 포함되어 있습니다. 이후의 문자 글리프는 텍스트 런을 따라 단순히 나란히 배치됩니다. OpenType, AAT(Apple Advanced Typography)와 같은 현대 폰트 포맷은 더 풍부한 처리 모델을 사용합니다. 특정 문자의 글리프는 문자 자체의 코드포인트뿐 아니라, 인접 문자, 언어, 스크립트, 텍스트에 활성화된 기능에 따라 선택 및 위치 지정될 수 있습니다. 폰트 기능은 특정 스크립트에 필수이거나, 기본 활성화가 권장되거나, 저자 제어용 스타일 기능일 수 있습니다. 폰트 선택 및 위치 지정이 전체 텍스트 처리 작업 순서(예: 텍스트 변환, 텍스트 방향, 텍스트 정렬)에서 어디에 위치하는지에 대해서는 [CSS-TEXT-3], § 텍스트 처리 순서에서 설명합니다.

이러한 기능의 시각적 개요는 [OPENTYPE-FONT-GUIDE]를 참고하세요. OpenType 폰트의 글리프 처리에 대한 자세한 설명은 [WINDOWS-GLYPH-PROC]를 참고하세요.

스타일적 폰트 기능은 크게 두 가지 범주로 분류할 수 있습니다: 주변 맥락과의 글리프 형태 조화에 영향을 주는 기능(커닝, 결합문자 등)과 글리프 선택에 영향을 주는 기능(스몰캡, 첨자/윗첨자, 대체 글리프 등)입니다.

아래에 나열된 ‘font-variant’의 하위 속성은 이러한 스타일적 폰트 기능을 제어합니다. 이들은 특정 스크립트의 표시에 필수적인 기능(예: 아랍어나 인도계 언어 텍스트에 사용되는 OpenType 기능)은 제어하지 않습니다. 글리프 선택과 위치 지정에만 영향을 주며, 폰트 매칭 섹션에서 설명한 폰트 선택에는 영향을 주지 않습니다(CSS 2.1과의 호환이 필요한 경우 제외).

사용자 에이전트 간 일관된 동작을 보장하기 위해, 각 속성별로 대응하는 OpenType 속성 설정을 명시하며 이는 규범적입니다. 다른 폰트 포맷을 사용할 때도 CSS 폰트 기능 속성 값을 특정 폰트 기능에 매핑하는 지침으로 삼아야 합니다.

6.2. 언어별 표시 지원

OpenType은 언어별 글리프 선택 및 위치 지정도 지원하므로, 언어가 특정 표시 동작을 요구하는 경우 텍스트를 올바르게 표시할 수 있습니다. 많은 언어가 공통 스크립트를 공유하지만, 특정 문자 형태가 언어마다 다를 수 있습니다. 예를 들어, 일부 키릴 문자 형태는 러시아어와 불가리아어에서 다릅니다. 라틴 텍스트에서는 "fi"를 점 없는 fi-결합문자로 표시하는 것이 일반적입니다. 하지만 터키어처럼 점 있는 i와 점 없는 i를 모두 사용하는 언어에서는, 이 결합문자를 사용하지 않거나 점이 있는 특수 버전을 사용해야 합니다. 아래 예시는 스페인어, 이탈리아어, 프랑스어 철자법에서 스타일적 전통에 따른 언어별 변형을 보여줍니다:

요소의 콘텐츠 언어가 문서 언어 규칙에 따라 알려진 경우, 사용자 에이전트는 해당 콘텐츠 언어로 OpenType 언어 시스템을 추론해, OpenType 폰트로 글리프 선택 및 위치 지정 시 이를 사용해야 합니다.

6.3. 커닝: font-kerning 속성

커닝은 글리프 간 간격을 문맥에 맞게 조정하는 것입니다. 이 속성은 폰트에 포함된 조정 데이터를 활용하는 메트릭 커닝을 제어합니다.

auto

커닝 적용 여부를 사용자 에이전트가 자유롭게 결정함

normal

커닝을 적용함

none

커닝을 적용하지 않음

커닝 데이터가 포함되지 않은 폰트에는 이 속성이 아무런 시각적 효과를 주지 않습니다. OpenType 폰트로 렌더링할 때, [OPENTYPE] 명세에서는 기본적으로 커닝이 활성화되는 것이 좋다고 권장하고 있습니다. 커닝이 활성화되면 OpenType kern 기능이 활성화되고, 수직 텍스트 런에서는 vkrn 기능이 대신 활성화됩니다. 사용자 에이전트는 OpenType 명세에 따라 kern 폰트 테이블에 포함된 데이터만으로 커닝을 지원하는 폰트도 지원해야 합니다. ‘letter-spacing’ 속성이 정의된 경우, 커닝 조정은 기본 간격의 일부로 간주되며, 커닝 적용 후 letter-spacing 조정이 이루어집니다.

‘auto’로 설정하면, 사용자 에이전트는 텍스트 크기, 스크립트, 텍스트 처리 속도에 영향을 주는 기타 요인에 따라 커닝 적용 여부를 결정할 수 있습니다. 올바른 커닝을 원한다면 ‘normal’로 명시적으로 활성화하는 것이 좋습니다. 반대로, 성능이 외형보다 중요한 상황에서는 커닝을 비활성화할 수도 있습니다. 하지만 잘 설계된 현대 구현에서는 커닝 활성화가 텍스트 렌더링 속도에 큰 영향을 주지 않는 것이 일반적입니다.

6.4. 합자: font-variant-ligatures 속성

합자와 문맥적 형태는 글리프를 결합하여 더욱 조화로운 형태를 만드는 방식입니다.

<common-lig-values>        = [ common-ligatures | no-common-ligatures ]

<discretionary-lig-values> = [ discretionary-ligatures | no-discretionary-ligatures ]

<historical-lig-values>    = [ historical-ligatures | no-historical-ligatures ]

<contextual-alt-values>    = [ contextual | no-contextual ]

개별 값의 의미는 다음과 같습니다:

normal

‘normal’ 값은 기본적으로 공통 기능이 활성화됨을 의미하며, 다음 섹션에서 자세히 설명합니다. OpenType 폰트의 경우, 공통 합자와 문맥적 형태가 기본적으로 켜져 있고, 선택적 및 역사적 합자는 꺼져 있습니다.

none

이 속성에서 다루는 모든 종류의 합자와 문맥적 형태가 명시적으로 비활성화됩니다. 합자가 필요하지 않은 경우 텍스트 렌더링 속도를 높일 수 있습니다.

common-ligatures

공통 합자 표시 허용(OpenType 기능: liga, clig). OpenType 폰트는 기본적으로 공통 합자가 활성화됩니다.

no-common-ligatures

공통 합자 표시 비활성화(OpenType 기능: liga, clig).

discretionary-ligatures

선택적 합자 표시 허용(OpenType 기능: dlig). 어떤 합자가 선택적인지 또는 옵션인지는 타입 디자이너가 결정하므로, 저자는 폰트 문서를 참고해서 어떤 합자가 discretionary인지 파악해야 합니다.

no-discretionary-ligatures

선택적 합자 표시 비활성화(OpenType 기능: dlig).

historical-ligatures

역사적 합자 표시 허용(OpenType 기능: hlig).

no-historical-ligatures

역사적 합자 표시 비활성화(OpenType 기능: hlig).

contextual

문맥적 대체글 표시 허용(OpenType 기능: calt). 엄밀히 합자 기능은 아니지만, 합자처럼 글리프의 형태가 주변 맥락과 조화를 이루도록 하는 데 자주 사용됩니다. OpenType 폰트에서는 기본적으로 활성화되어 있습니다.

no-contextual

문맥적 대체글 표시 비활성화(OpenType 기능: calt).

복합 스크립트를 올바르게 렌더링하기 위해 필요한 필수 합자들은 위의 설정(‘none’ 포함, OpenType 기능: rlig)에 영향을 받지 않습니다.

6.5. 아래첨자 및 위첨자 형태: font-variant-position 속성

이 속성은 타이포그래픽 아래첨자 및 위첨자 글리프를 활성화하는 데 사용됩니다. 이러한 글리프는 기본 글리프와 동일한 em-박스 내에 디자인되며, 기본 글리프와 동일한 기준선에 배치되도록 의도되어 있습니다. 크기 조정이나 기준선 재배치는 없습니다. 주변 텍스트와 잘 어울리도록 명확하게 디자인되며, 행 높이에 영향을 주지 않고 가독성을 높입니다.

아래첨자 글리프(상단) vs. 일반적으로 합성된 아래첨자(하단)

각 값의 의미는 다음과 같습니다:

normal

아래에 나열된 기능이 활성화되지 않습니다.

sub

아래첨자 변형의 표시를 활성화합니다(OpenType 기능: subs).

super

위첨자 변형의 표시를 활성화합니다(OpenType 기능: sups).

아래첨자와 위첨자의 의미론적 특성 때문에, 하나의 연속된 텍스트에서 값이 ‘sub’ 또는 ‘super’인 경우, 해당 범위의 모든 문자에 대해 변형 글리프가 없으면, 이 기능이 적용되지 않은 글리프의 축소 형태를 사용하여 합성 글리프를 가능하면 생성해야 합니다. 이는 변형 글리프와 합성 글리프가 올바르게 정렬되지 않는 혼합을 방지하기 위해 각 텍스트 범위마다 수행됩니다. OpenType 폰트에 특정 문자의 아래첨자나 위첨자 글리프가 없는 경우, 사용자 에이전트는 적절한 아래첨자 및 위첨자 글리프를 반드시 합성해야 합니다.

위첨자 대체 글리프(왼쪽), 합성 위첨자 글리프(중간), 그리고 두 가지의 잘못된 혼합(오른쪽)

텍스트 장식이 위첨자 또는 아래첨자 글리프가 포함된 텍스트 범위에만 적용되는 상황에서는, 장식의 위치 문제를 피하기 위해 합성 글리프가 사용될 수 있습니다.

과거에는 사용자 에이전트가 sub 및 sup 요소에 대해 font-size와 vertical-align을 사용하여 아래첨자와 위첨자를 시뮬레이션했습니다. 하위 호환성을 위해, 작성자는 조건부 규칙 [CSS3-CONDITIONAL]을 사용하여 이전 사용자 에이전트에서도 아래첨자와 위첨자가 기존 방식으로 렌더링되도록 하는 것이 권장됩니다.

font-size: smaller가 이러한 요소에 자주 사용되기 때문에, 아래첨자와 위첨자 텍스트에 적용되는 실질적인 스케일링 비율은 크기에 따라 달라집니다. 큰 텍스트에서는 폰트 크기가 3분의 1 정도 줄지만, 작은 텍스트에서는 감소 폭이 훨씬 적을 수 있습니다. 이로 인해 작은 텍스트 크기에서도 아래첨자와 위첨자가 읽기 쉬워집니다. 사용자 에이전트는 아래첨자 및 위첨자 글리프를 합성할 때 이를 고려해야 합니다.

OpenType 폰트 포맷은 OS/2 테이블 [OPENTYPE]에 아래첨자 및 위첨자 메트릭스를 정의하지만, 실제로 항상 정확하지 않으므로 글리프 합성 시 신뢰할 수 없습니다.

작성자는 폰트가 지원하는 모든 문자에 대해 아래첨자 및 위첨자 글리프를 제공하는 것이 일반적이지 않다는 점에 유의해야 합니다. 예를 들어, 라틴 숫자에는 아래첨자 및 위첨자 글리프가 자주 제공되지만, 구두점이나 문자에는 덜 제공됩니다. 이 속성에 대해 정의된 합성 폴백 규칙은 아래첨자와 위첨자가 항상 나타나도록 보장하지만, 사용된 폰트가 모든 문자에 대해 적절한 대체 글리프를 제공하지 않는다면 기대하는 모양과 다를 수 있습니다.

이 속성은 누적되지 않습니다. 아래첨자나 위첨자 내의 요소에 이 속성을 적용해도 위치가 중첩되지 않습니다. 이 속성의 값이 ‘sub’ 또는 ‘super’인 텍스트 범위에 포함된 이미지는 ‘normal’일 때와 동일하게 그려집니다.

이러한 한계로 인해, ‘font-variant-position’은 사용자 에이전트 스타일시트에서 사용하는 것이 권장되지 않습니다. 작성자는 폰트가 지정한 범위의 문자만 포함하는 경우에만 사용하는 것이 좋습니다.

대체 글리프는 기본 글리프와 동일한 기준선을 사용합니다. 기준선 위치의 이동이 없으므로, 대체 글리프를 사용한다고 인라인 박스의 높이나 라인박스의 높이가 변경되지 않습니다. 이는 리딩을 일정하게 유지하는 것이 중요한 다단 레이아웃 등에서 위첨자와 아래첨자 변형이 이상적입니다.

sub {
  vertical-align: sub;
  font-size: smaller;
  line-height: normal;
}

@supports ( font-variant-position: sub ) {

  sub {
    vertical-align: baseline;
    font-size: 100%;
    line-height: inherit;
    font-variant-position: sub;
  }

}

6.6. 대문자 변형: font-variant-caps 속성

이 속성은 소문자 대문자, 작은 대문자 또는 타이틀용 대문자에 사용되는 대체 글리프 선택을 허용합니다. 이러한 글리프는 주변의 일반 글리프와 잘 어울리도록 특별히 디자인되어, 단순히 텍스트 크기를 조정할 때 발생하는 두께나 가독성 저하 문제를 해결합니다.

각 값의 의미는 다음과 같습니다:

normal

아래 나열된 기능이 활성화되지 않습니다.

small-caps

스몰캡(작은 대문자) 표시를 활성화합니다(OpenType 기능: smcp). 스몰캡 글리프는 일반적으로 대문자 형태이지만, 크기가 소문자와 동일하게 축소됩니다.

all-small-caps

대문자와 소문자 모두에 대해 스몰캡 표시를 활성화합니다(OpenType 기능: c2sc, smcp).

petite-caps

소형 대문자 표시를 활성화합니다(OpenType 기능: pcap).

all-petite-caps

대문자와 소문자 모두에 대해 소형 대문자 표시를 활성화합니다(OpenType 기능: c2pc, pcap).

unicase

대문자에는 작은 대문자를, 소문자에는 일반 소문자를 혼합하여 표시합니다(OpenType 기능: unic).

titling-caps

타이틀용 대문자 표시를 활성화합니다(OpenType 기능: titl). 대문자 글리프는 소문자와 함께 사용할 때 과도하게 강조될 수 있으므로, 타이틀 대문자는 이런 상황을 위해 특별히 디자인됩니다.

이러한 글리프의 제공 여부는 폰트의 기능 리스트에 해당 기능이 정의되어 있는지에 따라 달라집니다. 사용자 에이전트는 스크립트별로 결정할 수 있지만, 문자별로 결정해서는 안 됩니다.

일부 폰트는 이 속성에 대해 설명된 기능의 일부만 지원하거나 전혀 지원하지 않을 수 있습니다. CSS 2.1과의 호환성을 위해, ‘small-caps’ 또는 ‘all-small-caps’이 지정되었지만 해당 폰트에 스몰캡 글리프가 없는 경우, 사용자 에이전트는 예를 들어 일반 폰트에서 소문자 글리프를 대문자 글리프의 축소 버전으로 대체(‘all-small-caps’의 경우 대문자와 소문자 모두 대체)하여 스몰캡 폰트를 시뮬레이션해야 합니다.

합성 스몰캡 vs. 실제 스몰캡

‘font-feature-settings’ 속성은 합성 스몰캡 폰트 사용 여부 결정에 영향을 주지 않습니다.

#example1 { font-variant-caps: small-caps; }
#example2 { font-variant-caps: small-caps; font-feature-settings: 'smcp' 0; }

주변 텍스트와 맞추기 위해, 폰트는 기능이 활성화될 때 대소문자가 없는 문자에 대해 대체 글리프를 제공할 수 있지만, 사용자 에이전트가 스몰캡을 시뮬레이션할 때는 대소문자가 없는 코드포인트에 대해 대체를 시뮬레이션해서는 안 됩니다.

스몰캡, all-small-caps 활성화된 대소문자 없는 문자

‘petite-caps’ 또는 ‘all-petite-caps’이 해당 기능을 지원하지 않는 폰트에 지정된 경우, 이 속성은 각각 ‘small-caps’ 또는 ‘all-small-caps’이 지정된 것과 동일하게 동작합니다. ‘unicase’가 해당 기능을 지원하지 않는 폰트에 지정된 경우, 이 속성은 소문자로 변환된 대문자에만 ‘small-caps’이 적용된 것처럼 동작합니다. ‘titling-caps’이 해당 기능을 지원하지 않는 폰트에 지정된 경우, 이 속성은 시각적으로 아무런 효과가 없습니다. 합성된 스몰캡 글리프가 사용될 때, 대소문자 구분이 없는 스크립트에 대해서는 ‘small-caps’, ‘all-small-caps’, ‘petite-caps’, ‘all-petite-caps’, ‘unicase’는 시각적으로 아무런 효과가 없습니다.

대소문자 변환을 사용하여 스몰캡을 시뮬레이션할 때, 변환은 ‘text-transform’ 속성에서 사용되는 변환과 일치해야 합니다.

최후의 수단으로, 일반 폰트의 크기 조정되지 않은 대문자 글리프를 스몰캡 폰트의 글리프로 대체하여 텍스트가 모두 대문자로 보이게 할 수 있습니다.

약어가 많은 텍스트의 가독성을 높이기 위한 스몰캡 활용

blockquote            { font-style: italic; }
blockquote:first-line { font-variant: small-caps; }

<blockquote>I'll be honor-bound to slap them like a haddock.</blockquote>

6.7. 숫자 형식화: font-variant-numeric 속성

숫자 형태 제어를 지정합니다. 아래 예시에서는 이러한 값들을 결합하여 해당 기능을 지원하는 폰트로 표 형식 데이터를 렌더링하는 방법을 보여줍니다. 일반 단락 텍스트에서는 비례 숫자가 사용되고, 표에서는 숫자 열이 올바르게 정렬되도록 표 숫자가 사용됩니다:

숫자 스타일 활용

가능한 조합:

<numeric-figure-values>   = [ lining-nums | oldstyle-nums ]

<numeric-spacing-values>  = [ proportional-nums | tabular-nums ]

<numeric-fraction-values> = [ diagonal-fractions | stacked-fractions ]

각 값의 의미는 다음과 같습니다:

normal

아래에 나열된 기능이 활성화되지 않습니다.

lining-nums

라이닝 숫자 표시를 활성화합니다(OpenType 기능: lnum).

oldstyle-nums

올드 스타일 숫자 표시를 활성화합니다(OpenType 기능: onum).

proportional-nums

비례 숫자 표시를 활성화합니다(OpenType 기능: pnum).

tabular-nums

표 숫자 표시를 활성화합니다(OpenType 기능: tnum).

diagonal-fractions

라이닝 대각선 분수 표시를 활성화합니다(OpenType 기능: frac).

stacked-fractions

라이닝 누적 분수 표시를 활성화합니다(OpenType 기능: afrc).

ordinal

서수 숫자에 사용되는 문자 형태 표시를 활성화합니다(OpenType 기능: ordn).

slashed-zero

슬래시가 그어진 0 표시를 활성화합니다(OpenType 기능: zero).

sup { font-variant-position: super; }
x<sup>2</sup>

.ordinal { font-variant-numeric: ordinal; }
<span class="ordinal">17th</span>

.amount { font-variant-numeric: oldstyle-nums diagonal-fractions; }

<h4>Steak marinade:</h4>
<ul>
  <li><span class="amount">2</span> tbsp olive oil</li>
  <li><span class="amount">1</span> tbsp lemon juice</li>
  <li><span class="amount">1</span> tbsp soy sauce</li>
  <li><span class="amount">1 1/2</span> tbsp dry minced onion</li>
  <li><span class="amount">2 1/2</span> tsp italian seasoning</li>
  <li>Salt &amp; pepper</li>
</ul>

<p>Mix the meat with the marinade and let it sit covered in the refrigerator
for a few hours or overnight.</p>

6.8. 동아시아 텍스트 렌더링: font-variant-east-asian 속성

동아시아 텍스트에서 글리프 대체 및 크기 조정을 제어할 수 있습니다.

<east-asian-variant-values> = [ jis78 | jis83 | jis90 | jis04 | simplified | traditional ]

<east-asian-width-values>   = [ full-width | proportional-width ]

각 값의 의미는 다음과 같습니다:

normal

아래에 나열된 기능이 활성화되지 않습니다.

jis78

JIS78 형태 렌더링을 활성화합니다(OpenType 기능: jp78).

jis83

JIS83 형태 렌더링을 활성화합니다(OpenType 기능: jp83).

jis90

JIS90 형태 렌더링을 활성화합니다(OpenType 기능: jp90).

jis04

JIS2004 형태 렌더링을 활성화합니다(OpenType 기능: jp04).

다양한 JIS 변형은 일본 국가 표준에 정의된 글리프 형태를 반영합니다. 폰트는 일반적으로 최신 국가 표준에 정의된 글리프를 포함하지만, 표지판 등과 맞추기 위해 이전 변형을 사용하는 것이 필요한 경우도 있습니다.

simplified

간화자 형태 렌더링을 활성화합니다(OpenType 기능: smpl).

traditional

번체자 형태 렌더링을 활성화합니다(OpenType 기능: trad).

‘simplified’와 ‘traditional’ 값은 시간이 지나면서 간소화된 문자에 대해, 일부 맥락에서 여전히 사용되는 오래된 번체 형태의 글리프를 제어할 수 있게 해줍니다. 사용되는 맥락에 따라 문자와 글리프 형태의 정확한 집합은 어느 정도 달라질 수 있습니다.

full-width

전각 변형 렌더링을 활성화합니다(OpenType 기능: fwid).

proportional-width

비례 폭 변형 렌더링을 활성화합니다(OpenType 기능: pwid).

ruby

루비 변형 글리프 표시를 활성화합니다(OpenType 기능: ruby). 루비 텍스트는 본문 텍스트보다 일반적으로 크기가 작으므로, 폰트 디자이너는 기본 글리프를 단순히 축소한 것보다 더 읽기 쉬운 루비 전용 글리프를 별도로 디자인할 수 있습니다. 글리프 선택에만 영향을 주며, 폰트 크기 조정이나 줄 레이아웃 등에는 영향을 주지 않습니다. 아래 붉은색 루비 텍스트는 기본 글리프(상단)와 루비 변형 글리프(하단)로 표시되어 있습니다. 스트로크 두께에서 약간의 차이가 있습니다.

6.9. 전체 폰트 렌더링 단축 속성: font-variant 속성

‘font-variant’ 속성은 모든 font-variant 하위 속성의 단축 속성입니다. ‘normal’ 값은 ‘font-variant’의 모든 하위 속성을 각각의 초기값으로 리셋합니다. ‘none’ 값은 ‘font-variant-ligatures’를 ‘none’으로 설정하고, 나머지 폰트 기능 속성을 모두 초기값으로 리셋합니다. 다른 단축 속성과 같이 ‘font-variant’를 사용할 때 명시되지 않은 ‘font-variant’ 하위 속성은 초기값으로 리셋됩니다. 이는 ‘font-feature-settings’의 값을 리셋하지 않습니다.

6.10. 저수준 폰트 기능 설정 제어: font-feature-settings 속성

이 속성은 OpenType 폰트 기능에 대한 저수준 제어를 제공합니다. 널리 사용되지는 않지만 특정 용도에 필요한 폰트 기능에 접근할 수 있도록 하기 위한 방법입니다.

작성자는 일반적으로 ‘font-variant’와 관련 하위 속성을 최대한 사용하고, 이 속성은 특수한 경우에만 사용하는 것이 좋습니다.

/* 스몰캡 활성화 및 두 번째 swash 대체 사용 */
font-feature-settings: "smcp", "swsh" 2;

‘normal’ 값은 이 속성에 의해 글리프 선택이나 위치 지정에 변화가 없음을 의미합니다.

기능 태그 값의 문법은 다음과 같습니다:

<feature-tag-value> = <string> [ <integer> | on | off ]?

<string>은 대소문자를 구분하는 OpenType 기능 태그입니다. OpenType 명세 [OPENTYPE]에 따라 기능 태그는 네 개의 ASCII 문자로 이루어집니다. 4글자보다 길거나 짧거나, U+20–7E 범위를 벗어나는 문자가 포함된 태그는 유효하지 않습니다. 기능 태그는 폰트에 정의된 기능 태그와 일치하기만 하면 되므로, OpenType에 명시적으로 등록된 기능에만 제한되지 않습니다. 커스텀 기능 태그를 정의하는 폰트는 OpenType 명세 태그 네임 규칙 [OPENTYPE-FEATURES]을 따라야 합니다.

폰트에 없는 기능 태그는 무시됩니다. 사용자 에이전트는 이러한 기능 태그에 대해 폴백 동작을 합성하려 해서는 안 됩니다. 단, 폰트에 ‘kern’ 테이블에 커닝 데이터가 있지만 ‘GPOS’ 테이블에 kern 기능이 없는 경우, 사용자 에이전트가 kern 기능을 합성적으로 지원할 수 있습니다.

일반적으로 작성자는 ‘font-kerning’ 속성을 사용해 커닝을 명시적으로 활성화/비활성화하는 것이 좋습니다. 이 속성이 있으면 커닝 데이터를 가진 모든 폰트에 적용됩니다.

값이 있을 경우, 이는 글리프 선택에 사용되는 인덱스를 의미합니다. <integer> 값은 0 이상이어야 하며, 0은 기능이 비활성화됨을 의미합니다. 불리언 기능의 경우 1은 기능 활성화입니다. 불리언이 아닌 기능의 경우 1 이상은 기능 활성화 및 기능 선택 인덱스를 의미합니다. ‘on’은 1과 동일하고, ‘off’는 0과 동일합니다. 값이 생략되면 1로 간주합니다.

font-feature-settings의 계산된 값은 맵 형식이므로, 지정된 값의 중복은 유지되지 않습니다. 동일한 축 이름이 여러 번 나타나면 마지막 값이 이전 값을 대체합니다.

font-feature-settings: "dlig" 1;       /* dlig=1 임의 합자 활성화 */
font-feature-settings: "smcp" on;      /* smcp=1 스몰캡 활성화 */
font-feature-settings: 'c2sc';         /* c2sc=1 대문자→스몰캡 활성화 */
font-feature-settings: "liga" off;     /* liga=0 일반 합자 비활성화 */
font-feature-settings: "tnum", 'hist'; /* tnum=1, hist=1 표 숫자 및 역사적 형태 활성화 */
font-feature-settings: "tnum" "hist";  /* 잘못된 문법, 콤마로 구분해야 함 */
font-feature-settings: "silly" off;    /* 잘못된 문법, 태그가 너무 김 */
font-feature-settings: "PKRN";         /* PKRN=1 사용자 정의 기능 활성화 */
font-feature-settings: dlig;           /* 잘못된 문법, 태그는 문자열이어야 함 */

폰트에서 지원하는 범위를 넘는 값을 지정하면 동작은 명확히 정의되지 않습니다. 불리언 기능의 경우 일반적으로 기능이 활성화됩니다. 불리언이 아닌 기능의 경우 범위 밖 값은 일반적으로 0과 동일하게 동작합니다. 그러나 폰트 설계(특히 lookup 방식)에 따라 정확한 동작은 달라질 수 있습니다.

OpenType 기능 태그에 대해 명확히 정의되었지만, 폰트 기능을 지원하는 다른 현대 폰트 포맷의 기능 태그가 앞으로 추가될 수 있습니다. 가능하다면, 다른 폰트 포맷의 기능도 OpenType 등록 태그 패턴을 따르도록 해야 합니다.

body { font-feature-settings: "hwid"; /* 반각 OpenType 기능 */ }

<p>매일카레를 먹어도 질리지 않는다</p>

7. 폰트 기능 해석

앞 절에서 설명한 것처럼, 폰트 기능은 ‘font-variant’ 또는 ‘font-feature-settings’ 스타일 규칙, 또는 @font-face 규칙에서 여러 방식으로 활성화될 수 있습니다. 이러한 설정의 합에 대한 해석 순서가 아래에 정의되어 있습니다. CSS 속성으로 정의된 기능은 레이아웃 엔진의 기본 기능 위에 적용됩니다.

7.1. 기본 기능

OpenType 폰트의 경우, 사용자 에이전트는 해당 스크립트와 서체 모드에 대해 OpenType 문서에 정의된 기본 기능을 활성화해야 합니다. 필수 합자, 일반 합자 및 문맥적 형태는 기본적으로 활성화되어야 하며(OpenType 기능: rlig, liga, clig, calt), 로컬 형태(OpenType 기능: locl), 조합 문자 및 마크의 올바른 표시를 위한 기능(OpenType 기능: ccmp, mark, mkmk)도 활성화되어야 합니다. 이러한 기능은 ‘font-variant’와 ‘font-feature-settings’ 속성 값이 ‘normal’이어도 항상 활성화되어야 하며, 작성자가 명시적으로 오버라이드하는 경우(예: ‘font-variant-ligatures’를 ‘no-common-ligatures’로 설정)만 개별 기능이 비활성화됩니다. 아랍어 [ARABIC-TYPO], 크메르어 또는 데바나가리 등 복합 스크립트 처리를 위해 추가 기능이 필요합니다. 세로 텍스트 범위 내에서 세로 글자에 대해서는 세로 대체(OpenType 기능: vert)가 반드시 활성화되어야 합니다.

7.2. 기능 우선순위

일반 및 폰트별 폰트 기능 속성 설정은 아래와 같이 우선순위가 증가하는 순서로 해석됩니다. 이 순서는 특정 텍스트 런에 영향을 주는 폰트 기능의 결합된 목록을 구성하는 데 사용됩니다.

1. 기본적으로 활성화되는 폰트 기능, 해당 스크립트에 필요한 기능을 포함합니다.
2. 폰트가 @font-face 규칙을 통해 정의된 경우, @font-face 규칙의 font-feature-settings 디스크립터로 암시되는 폰트 기능.
3. ‘font-variant’ 속성의 값, 관련 ‘font-variant’ 하위 속성 및 OpenType 기능을 사용하는 기타 CSS 속성(예: ‘font-kerning’ 속성)으로 암시되는 폰트 기능.
4. ‘font-variant’ 또는 ‘font-feature-settings’ 이외의 속성에 의해 결정되는 기능 설정. 예를 들어, ‘letter-spacing’ 속성에 기본값이 아닌 값을 설정하면 일반 합자가 비활성화됩니다.
5. ‘font-feature-settings’ 속성의 값으로 암시되는 폰트 기능.

이 순서 덕분에 작성자는 @font-face 규칙 내에서 폰트의 기본값을 설정한 뒤, 특정 요소에 대해 속성 설정으로 이를 오버라이드할 수 있습니다. 일반 속성 설정은 @font-face 규칙의 설정을 오버라이드하고, 저수준 폰트 기능 설정은 ‘font-variant’ 속성 설정을 오버라이드합니다.

결합된 폰트 기능 설정 목록에 동일한 기능에 대한 값이 둘 이상 있을 경우, 마지막 값이 사용됩니다. 폰트가 해당 기능을 지원하지 않는 경우, 텍스트는 해당 기능이 활성화되지 않은 것처럼 렌더링됩니다. 폰트 폴백은 발생하지 않으며, 특정 속성에 명시적으로 정의된 경우를 제외하고 기능 합성도 시도하지 않습니다.

7.3. 기능 우선순위 예시

body {
  font-variant-numeric: proportional-nums;
}

table.prices td {
  font-variant-numeric: tabular-nums;
}

8. 오브젝트 모델

@font-face 규칙의 내용은 아래의 CSS 오브젝트 모델 확장을 통해 접근할 수 있습니다.

8.1. CSSFontFaceRule 인터페이스

CSSFontFaceRule 인터페이스는 @font-face 규칙을 나타냅니다.

interface CSSFontFaceRule : CSSRule {
    readonly attribute CSSStyleDeclaration style;
};

부록 A: 플랫폼 폰트 속성을 CSS 속성으로 매핑

이 부록은 다른 섹션에서 설명된 일부 문제와 상황에 대한 배경 정보로 포함되었습니다. 참고용으로만 보아야 합니다.

CSS의 폰트 속성은 사용되는 기반 폰트 포맷과 독립적으로 설계되어 있습니다. 비트맵 폰트, Type1 폰트, SVG 폰트뿐만 아니라 일반적으로 사용되는 TrueType 및 OpenType 폰트도 지정할 수 있습니다. 하지만 TrueType과 OpenType 포맷의 특징 중 일부는 저자들에게 혼동을 주고, 다양한 플랫폼에서 구현자들에게 어려움을 줄 때가 있습니다.

TrueType은 원래 애플에서 개발되었으며 [[TRUETYPE]] 화면과 인쇄 모두를 위한 윤곽선 폰트 포맷으로 설계되었습니다. 마이크로소프트가 애플과 함께 TrueType 포맷 개발에 참여했고, 두 플랫폼은 이후 TrueType 폰트를 지원해왔습니다. TrueType 포맷의 폰트 데이터는 공통의 네 글자 태그 이름으로 구분되는 여러 테이블로 구성되어 있으며, 각 테이블은 특정 데이터 유형을 포함합니다. 예를 들어, 저작권 및 라이선스 정보를 포함한 네이밍 정보는 ‘name’ 테이블에 저장됩니다. 문자 맵(‘cmap’) 테이블에는 문자 인코딩과 글리프의 매핑이 담겨 있습니다. 이후 애플은 향상된 타이포그래피 기능을 지원하기 위해 추가 테이블을 도입했으며, 이는 Apple Advanced Typography(AAT) 폰트로 불립니다. 마이크로소프트와 어도비는 고급 타이포그래피를 위해 별도의 테이블 집합을 개발하여 OpenType 포맷[OPENTYPE]라고 불렀습니다. OpenType 명세는 ISO에서 Open Font Format [OPEN-FONT-FORMAT]으로 표준화되었습니다.

많은 경우, Microsoft Windows 또는 Linux에서 사용되는 폰트 데이터는 애플의 Mac OS X에서 사용되는 데이터와 약간 다릅니다. TrueType 포맷이 플랫폼별 명시적 변형을 허용했기 때문입니다. 여기에는 폰트 메트릭, 이름, 문자 맵 데이터 등이 포함됩니다.

특히, 폰트 패밀리 이름 데이터는 플랫폼별로 다르게 처리됩니다. TrueType과 OpenType 폰트의 경우 이 이름들은 ‘name’ 테이블 name ID 1의 레코드에 담겨 있습니다. 다양한 로케일용으로 여러 이름을 저장할 수 있지만, 마이크로소프트는 항상 미국 영어 버전의 이름을 포함할 것을 권장합니다. 윈도우에서는 하위 호환성을 위해 이 패밀리 이름을 최대 네 개의 페이스로 제한하기로 결정했으며, 더 큰 그룹에는 "preferred family"(name ID 16)나 "WWS family"(name ID 21)를 사용할 수 있습니다. OSX와 같은 다른 플랫폼은 이런 제한이 없어서 패밀리 이름으로 모든 그룹을 정의합니다.

name 테이블의 다른 데이터는 패밀리 내에서 특정 페이스를 고유하게 식별하는 이름을 제공합니다. 전체 폰트 이름(name ID 4)과 포스트스크립트 이름(name ID 6)은 개별 페이스를 고유하게 설명합니다. 예를 들어, Gill Sans 패밀리의 Bold 페이스는 전체 이름이 "Gill Sans Bold"이고 포스트스크립트 이름은 "GillSans-Bold"입니다. 한 페이스에 대해 여러 지역화된 전체 이름 버전이 있을 수 있지만, 포스트스크립트 이름은 항상 제한된 ASCII 문자로 만든 고유한 이름입니다.

다양한 플랫폼에서는 서로 다른 이름을 사용해 폰트를 검색합니다. 예를 들어, Windows의 GDI CreateIndirectFont API에서는 패밀리나 전체 이름 모두로 페이스를 검색할 수 있고, Mac OS X에서는 CTFontCreateWithName API 호출로 전체 이름과 포스트스크립트 이름으로 페이스를 찾습니다. Linux에서는 fontconfig API로 이 이름들을 모두 활용해 폰트를 검색할 수 있습니다. 플랫폼 API가 자동으로 다른 폰트 선택을 대체하는 경우, 반환된 폰트가 지정한 이름과 일치하는지 확인해야 할 수도 있습니다.

특정 페이스의 두께(굵기)는 OS/2 테이블의 usWeightClass 필드나 스타일 이름(name ID 2)에서 추론할 수 있습니다. 폭 역시 OS/2 테이블의 usWidthClass 또는 스타일 이름에서 추론할 수 있습니다. Windows GDI API에서 200 이하의 굵기에서 합성 볼딩과 관련된 역사적 이유로, 폰트 디자이너들이 OS/2 테이블의 값을 왜곡하는 경우도 있습니다.

타이, 아랍어, 데바나가리처럼 문맥적 셰이핑을 사용하는 복합 스크립트를 렌더링하려면 OpenType 또는 AAT 폰트에만 존재하는 기능이 필요합니다. 현재 복합 스크립트 렌더링은 Windows와 Linux에서는 OpenType 폰트 기능으로, Mac OS X에서는 OpenType과 AAT 폰트 기능 모두로 지원됩니다.

변경 사항

2018년 8월 14일 CSS Fonts 3 Proposed Recommendation (제안 권고안) 이후 변경 사항

• 변경 로그에서 CSS Fonts 4로 이동된 기능은 이제 해당 명세의 해당 섹션으로 연결됨
• W3C 권고안의 날짜 및 기본정보 업데이트
• Unicode 참조를 최신 버전으로 업데이트
• 이 변경 사항 섹션 업데이트

2018년 3월 15일 CSS Fonts 3 Candidate Recommendation (후보 권고안) 이후 변경 사항

• ‘font-variant’ 디스크립터가 구현 부족으로 CSS Fonts 4로 이동됨
• ‘font-feature-values’ at-rule이 구현 부족으로 CSS Fonts 4로 이동됨
• 알 수 없는 프래그먼트 식별자 처리 방식 명확화
• 길이-백분율 정의를 위한 CSS Values & Units 링크 추가

2013년 10월 CSS3 Fonts Candidate Recommendation (후보 권고안) 이후 변경 사항

• ‘font-language-override’ 속성이 CSS Fonts 4로 이동됨
• CSSFontFeatureValuesRule 인터페이스가 CSS Fonts 4로 이동됨
• CSSFontFaceRule 인터페이스가 DOM Level 2 스타일에서 널리 구현된 버전으로 되돌림
• 제네릭 폰트 패밀리가 복합 페이스일 수 있음을 명확화
• "첫 번째 사용 가능한 폰트"는 U+0020(공백) 문자를 매칭하는 폰트임을 명확화
• 스몰캡 합성과 ‘font-feature-settings’의 상호작용 명확화
• 모든 CSS 키워드는 잘못된 폰트 패밀리 이름으로 표시됨
• ‘font-synthesis’가 ‘font’ 단축 속성으로 리셋되지 않음을 명확화
• "시스템 폰트" 대신 "설치된 폰트"라는 문구 사용
• font-family: 또는 src:가 없는 잘못된 @font-face 규칙도 DOM에 표시되지만 폰트 선택에 영향 없음 명확화
• 절대 키워드 크기를 수정하지 않을 때 상대 크기의 비율 범위 명확화
• font-variation-settings와 font-feature-settings 모두 계산된 값이 맵이며, 중복 지정은 제거됨을 명확화
• ‘font-variant-position’ 값이 ‘font-variant’ 단축 속성에 빠진 부분 추가
• font-size-adjust에 음수 값, font-size의 음수 백분율 값이 잘못된 값임을 명확화
• 사용자 에이전트가 OS/2 테이블의 아래첨자/위첨자 메트릭을 반드시 사용할 필요 없음 명확화
• CSS Text 연산 순서에 대한 참고 링크 추가
• RFC 8081(폰트 상위 미디어 타입)에 대한 표준 링크 추가
• 사소한 편집 정리

감사의 글

Tal Leming, Jonathan Kew, Ken Lunde, Christopher Slye께 많은 도움과 피드백을 주신 데 감사드립니다. John Hudson은 OpenType 언어 태그의 미묘한 차이점을 설명해 주셨고, 비잔틴 인장에 텍스트를 표시하기 위한 문자 변형 사용 예시도 제공해 주셨습니다. Ken Lunde와 Eric Muller는 CJK OpenType 기능과 유니코드 변형 선택자에 대해 소중한 피드백을 주셨습니다. ‘font-variant’ 하위 속성으로 폰트 기능을 지원한다는 아이디어는 Håkon Wium Lie, Adam Twardoch, Tal Leming이 제안한 것입니다. Elika Etemad는 @font-feature-values 규칙의 초기 디자인 아이디어를 제공해 주었습니다. House Industries에도 임의 합자 예시에 Ed Interlock을 사용할 수 있도록 허락해 주셔서 감사드립니다.

Robert Bringhurst에게 The Elements of Typographic Style의 멋진 영감에 특별히 감사드립니다.

적합성

문서 규칙

적합성 요구 사항은 설명적 주장과 RFC 2119 용어의 조합으로 표현됩니다. 규범적 부분에서 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, “OPTIONAL” 등의 주요 단어는 RFC 2119에서 설명된 대로 해석해야 합니다. 하지만, 가독성을 위해 이 단어들은 본 명세에서 모두 대문자로 표기되지 않습니다.

이 명세의 모든 텍스트는 명시적으로 비규범적임을 표시한 섹션, 예시, 참고를 제외하면 모두 규범적입니다. [RFC2119]

이 명세의 예시는 “예를 들어”라는 말로 소개되거나, 아래와 같이 class="example"로 규범적 텍스트와 구분됩니다:

정보 제공용 노트는 “참고”라는 단어로 시작하며, 아래와 같이 class="note"로 규범적 텍스트와 구분됩니다:

참고, 이것은 정보 제공용 노트입니다.

적합성 클래스

CSS Fonts Level 3 모듈의 적합성은 세 가지 적합성 클래스로 정의됩니다:

스타일 시트

CSS 스타일 시트.

렌더러

UA로, 스타일 시트의 의미를 해석하고 문서를 렌더링하는 사용자 에이전트.

저작 도구

UA로, 스타일 시트를 작성하는 도구.

스타일 시트가 CSS Fonts Level 3 모듈에 적합하려면, 이 모듈에서 정의된 속성을 사용하는 모든 선언이 일반 CSS 문법과 각 속성의 개별 문법에 따라 유효한 값을 가져야 합니다.

렌더러가 CSS Fonts Level 3 모듈에 적합하려면, 해당 사양에 정의된 대로 스타일 시트를 해석하는 것 외에도, CSS Fonts Level 3 모듈에서 정의된 모든 기능을 올바르게 파싱하고 문서를 그에 따라 렌더링해야 합니다. 단, 디바이스의 한계로 인해 UA가 문서를 올바르게 렌더링하지 못하는 경우라도 UA가 비준수적이라고 볼 수 없습니다. (예: UA가 흑백 모니터에서 색상을 렌더링할 필요는 없음)

저작 도구가 CSS Fonts Level 3 모듈에 적합하려면, 이 모듈의 기능별 개별 문법과 일반 CSS 문법에 따라 문법적으로 올바른 스타일 시트를 작성하고, 이 모듈에서 설명된 스타일 시트의 모든 기타 준수성 요구 사항을 충족해야 합니다.

부분 구현

저자가 향후 호환성 파싱 규칙을 활용하여 폴백 값을 지정할 수 있도록, CSS 렌더러는 지원 가능한 수준이 없는 모든 at-rule, 속성, 속성 값, 키워드, 기타 구문 구조를 반드시 잘못된 것으로 처리해야 하며, 적절히 무시해야 합니다. 특히, 사용자 에이전트는 지원되지 않는 구성 값이 있으면, 단일 다중 값 속성 선언에서 지원되는 값만 선택적으로 무시해서는 안 됩니다: 값 중 하나라도 잘못된 값(지원되지 않는 값 포함)으로 간주되면 CSS는 전체 선언을 무시해야 합니다.

실험적 구현

향후 CSS 기능과 충돌을 피하기 위해 CSS2.1 명세는 CSS의 독점적 또는 실험적 확장에 대해 접두어 문법을 예약합니다.

명세가 W3C 프로세스의 Candidate Recommendation 단계에 도달하기 전까지, 모든 CSS 기능의 구현은 실험적입니다. CSS 워킹 그룹은 구현 시, W3C Working Draft에 포함된 기능도 포함하여 이러한 기능에 접두어 문법을 사용할 것을 권장합니다. 이는 초안의 향후 변경과의 호환성 문제를 방지합니다.

비실험적 구현

명세가 Candidate Recommendation 단계에 도달하면 비실험적 구현이 가능해지며, 구현자는 사양에 따라 올바르게 구현되었음을 입증할 수 있는 모든 CR 단계 기능에 대해 접두어 없는 구현을 출시해야 합니다.

CSS의 상호 운용성을 확립 및 유지하기 위해, CSS 워킹 그룹은 비실험적 CSS 렌더러가 접두어 없는 구현을 출시하기 전 W3C에 구현 보고서(필요한 경우 해당 테스트케이스 포함)를 제출할 것을 요청합니다. W3C에 제출된 테스트케이스는 CSS 워킹 그룹의 검토 및 수정 대상입니다.

테스트케이스 및 구현 보고서 제출에 대한 추가 정보는 CSS 워킹 그룹 웹사이트 https://www.w3.org/Style/CSS/Test/에서 확인할 수 있습니다. 질문은 public-css-testsuite@w3.org 메일링 리스트로 문의하세요.

참고 문헌

규범적 참고문헌

[CSS-VALUES]

Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 3 2016년 9월 29일. CR. URL: https://www.w3.org/TR/css-values/

[FETCH]

Fetch. WhatWG 현행 표준. URL: https://fetch.spec.whatwg.org/

[OPENTYPE]

OpenType specification. Microsoft. URL: http://www.microsoft.com/typography/otspec/default.htm

[OPENTYPE-FEATURES]

OpenType feature registry. Microsoft. URL: http://www.microsoft.com/typography/otspec/featurelist.htm

[RFC2119]

S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt

[RFC8081]

C. Lilley. The "font" Top-Level Media Type. 2017년 2월. Proposed Standard. URL: https://tools.ietf.org/html/rfc8081

[UAX15]

Mark Davis; Ken Whistler. Unicode Normalization Forms. 2012년 8월 31일. Unicode Standard Annex #15. URL: http://www.unicode.org/reports/tr15/

[UNICODE]

The Unicode Standard URL: http://www.unicode.org/versions/latest

기타 참고문헌

[AAT-FEATURES]

Apple Advanced Typography font feature registry. Apple. URL: https://developer.apple.com/fonts/TrueType-Reference-Manual/RM09/AppendixF.html

[ARABIC-TYPO]

Huda Smitshuijzen AbiFares. Arabic Typography: A Comprehensive Sourcebook. Saqi Books. 2001. ISBN 0-86356-347-3.

[CHARMOD]

Martin J. Dürst; et al. Character Model for the World Wide Web 1.0: Fundamentals. 2005년 2월 15일. W3C Recommendation. URL: http://www.w3.org/TR/2005/REC-charmod-20050215/

[CHARMOD-NORM]

Addison Phillips. Character Model for the World Wide Web: String Matching. 2018년 4월 20일. W3C Working Draft. (작업 중) URL: https://www.w3.org/TR/2018/WD-charmod-norm-20180420/

[CSS-TEXT-3]

Elika J. Etemad / fantasai; Koji Ishii. CSS Text Module Level 3. 2017년 8월 22일. W3C Working Draft. (작업 중) URL: https://www.w3.org/TR/2017/WD-css-text-3-20170822/

[CSS3-CONDITIONAL]

L. David Baron. CSS Conditional Rules Module Level 3. 2013년 4월 4일. W3C Candidate Recommendation. (작업 중) URL: http://www.w3.org/TR/2013/CR-css3-conditional-20130404/

[OPEN-FONT-FORMAT]

정보기술 — 오디오-비주얼 객체의 코딩 — Part 22: Open Font Format. 국제표준화기구. ISO/IEC 14496-22:2009. URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c052136_ISO_IEC_14496-22_2009%28E%29.zip

[OPENTYPE-FONT-GUIDE]

OpenType User Guide. FontShop International. URL: http://www.fontblog.de/wp-content/uploads/2015/11/FF_OTF_user_guide.pdf

[TRUETYPE]

TrueType™ Reference Manual. Apple. URL: https://developer.apple.com/fonts/TrueType-Reference-Manual/

[UAX29]

Mark Davis. Unicode Text Segmentation. 2012년 9월 12일. Unicode Standard Annex #29. URL: http://www.unicode.org/reports/tr29/

[WINDOWS-GLYPH-PROC]

John Hudson. Windows Glyph Processing. Microsoft Typogrraphy. URL: http://www.microsoft.com/typography/developers/opentype/default.htm

색인

• 100...900 굵기 값, 3.2.
• <absolute-size>, 3.5.
• all-petite-caps, 6.6.
• all-small-caps, 6.6.
• aspect value, 3.6.
• authoring tool, ??
• auto
  • font-kerning, 6.3.
• bold, 3.2.
• bolder, 3.2.
• character map, 5.2.
• common-ligatures, 6.4.
• <common-lig-values>, 6.4.
• composite face, 5.2.
• condensed, 3.3.
• contextual, 6.4.
• <contextual-alt-values>, 6.4.
• CSSFontFaceRule, 8.1.
• cursive, 정의, ??
• default face, 5.2.
• descriptor_declaration, 4.1.
• diagonal-fractions, 6.7.
• discretionary-ligatures, 6.4.
• <discretionary-lig-values>, 6.4.
• <east-asian-variant-values>, 6.8.
• <east-asian-width-values>, 6.8.
• effective character map, 4.5.
• expanded, 3.3.
• extra-condensed, 3.3.
• extra-expanded, 3.3.
• <family-name>, 3.1.
• fantasy, 정의, ??
• <feature-tag-value>, 6.10.
• first available font, 5.2.
• font, 3.7.
• @font-face, 4.1.
• <font-face-name>, 4.3.
• font_face_rule, 4.1.
• FONT_FACE_SYM, 4.1.
• font-family
  • 디스크립터, 4.2.
  • 속성, 3.1.
• font-feature-settings
  • 디스크립터, 4.7.
  • 속성, 6.10.
• font-kerning, 6.3.
• font-size, 3.5.
• font-size-adjust, 3.6.
• font-stretch
  • 디스크립터, 4.4.
  • 속성, 3.3.
• font-style
  • 디스크립터, 4.4.
  • 속성, 3.4.
• font-synthesis, 3.8.
• font-variant
  • 속성, 6.9.
• font-variant-caps, 6.6.
• <font-variant-css21>, 3.7.
• font-variant-east-asian, 6.8.
• font-variant-ligatures, 6.4.
• font-variant-numeric, 6.7.
• font-variant-position, 6.5.
• font-weight
  • 디스크립터, 4.4.
  • 속성, 3.2.
• full-width, 6.8.
• <generic-family>, 3.1.
• historical-ligatures, 6.4.
• <historical-lig-values>, 6.4.
• italic, 3.4.
• jis04, 6.8.
• jis78, 6.8.
• jis83, 6.8.
• jis90, 6.8.
• lighter, 3.2.
• lining-nums, 6.7.
• monospace, 정의, ??
• no-common-ligatures, 6.4.
• no-contextual, 6.4.
• no-discretionary-ligatures, 6.4.
• no-historical-ligatures, 6.4.
• none
  • font-kerning, 6.3.
  • font-size-adjust, 3.6.
  • font-variant, 6.9.
  • font-variant-ligatures, 6.4.
• normal
  • font-feature-settings, 6.10.
  • font-kerning, 6.3.
  • font-stretch, 3.3.
  • font-style, 3.4.
  • font-variant, 6.9.
  • font-variant-caps, 6.6.
  • font-variant-east-asian, 6.8.
  • font-variant-ligatures, 6.4.
  • font-variant-numeric, 6.7.
  • font-variant-position, 6.5.
  • font-weight, 3.2.
• <number>, 3.6.
• <numeric-figure-values>, 6.7.
• <numeric-fraction-values>, 6.7.
• <numeric-spacing-values>, 6.7.
• oblique, 3.4.
• oldstyle-nums, 6.7.
• ordinal, 6.7.
• petite-caps, 6.6.
• proportional-nums, 6.7.
• proportional-width, 6.8.
• <relative-size>, 3.5.
• renderer, ??
• ruby, 6.8.
• sans-serif, 정의, ??
• semi-condensed, 3.3.
• semi-expanded, 3.3.
• serif, 정의, ??
• simplified, 6.8.
• slashed-zero, 6.7.
• small-caps, 6.6.
• src, 4.3.
• stacked-fractions, 6.7.
• style sheet
  • 준수성 클래스, ??
• sub, 6.5.
• super, 6.5.
• support, 5.2.
• system font fallback, 5.2.
• tabular-nums, 6.7.
• titling-caps, 6.6.
• traditional, 6.8.
• ultra-condensed, 3.3.
• ultra-expanded, 3.3.
• unicase, 6.6.
• unicode-range, 4.5.
• <urange>, 4.5.
• weight, 2.
• width, 2.

속성 색인