1976년 ATypI에서의 보간 논의부터 Multiple Master, TrueType GX, Skia, MutatorMath, fonttools, fontmake, 그리고 OpenType Variable Fonts 재탄생과 Rust 재작성까지 이어지는 폰트 컴파일러와 가변 폰트 도구들의 간략한 역사
부제: 폰트 컴파일러의 짧은 역사. 혹은 왜 fontmake인가. 혹은 ATypI에서 벌어진 일.
2023년에 작성되었으며, 틀린 것은 전부 @rsheeter 책임. 쓸 만한 건 전부 다른 사람 덕분.
1976년과 2013년 사이에 무슨 일이 있었는지는 문서화가 부족하다. PR 환영.
필명 Mr B는 @rsheeter가 Behdad Esfahbod를 그렇게 부르는 게 웃기다고 생각해서 쓴다. 재미는 각자 판단.
Peter Karow는 "Font Technology: Methods and Tools"에서 1976년에 IKARUS 프로그램이 새 기능을 논의 중이었다고 언급한다. 바로 보간(interpolate)을 할 수 있다는 것. 이는 필자가 찾아낸, 궁극적으로 가변 폰트(variable fonts)로 이어지는 개념에 대한 가장 이른 문헌상의 언급이다. 다만 이는 클라이언트 측이 아니라 사전 계산(ahead of time) 쪽에 해당한다.
Adobe가 Multiple Master(MM) 폰트를 시연한다. 이 포맷은 코너 마스터(corner master)들 사이를 보간하며, 기본(default)을 별도로 인코딩하지 않는다. Multiple Master 인스턴스 생성은 사전 계산이 아니라 런타임에 이루어진다. 다만 Adobe Type Manager(ATM)은 사전 계산(export ahead-of-time)을 제공했다.
당시 ATM은 매우 인기 있었다. 시스템의 폰트 관련 호출을 가로채는 방식으로 동작해서, MM을 다양한 앱에서 어느 정도 제한된 형태로이긴 하지만 그냥 잘 돌아가게 만들었다. 일러스트레이터와 포토샵 같은 몇몇 앱은 슬라이더(자동 광학 사이징은 없음?) 형태라도 어느 정도 직접 지원을 제공했지만, 전체적으로 사용자 애플리케이션 차원에서의 지원은 널리 퍼지지 않았다. 폰트 제작 도구들은 90년대 중후반에 MM을 지원했으나, 초기에는 사내에서만 쓰는 전용 포맷과 내부용 폰트 에디터였다.
Adobe Type 팀은 optical size에 열광했지만, 비즈니스적으로 MM에 투자한 가장 큰 이유는 PS나 PDF 파일을 생성·렌더링할 때 빠져 있는 폰트를 대신할 Adobe Sans와 Adobe Serif를 제공하기 위함이다. "정확한" 폰트는 있지만, 임베드가 허용되지 않는다거나 해서, 그 폰트와 유사한 메트릭, 대문자 높이(cap height), 굵기(weight), 기울기(slope) 등 메타데이터를 가진 좋은 대체 폰트를 생성해야 했다. 혹은 PDF 안에 폰트가 완전히 임베드되어 있지는 않지만, 그런 메타데이터는 들어 있을 수 있고, 그러면 Adobe Acrobat이 그 정보로 적절한 인스턴스를 생성해 렌더링할 수 있다. Adobe Sans가 먼저 등장하는데, Myriad를 기반으로 하고, '90 혹은 '91년에 "Super ATM"에 포함되어 배포된다. Adobe Serif는 다음 버전에 나온다.
Multiple Master는 크게 두 메이저 버전이 있었고, 창의적으로 1번과 2번이라고 부르자면 다음과 같다:
어느 시점에는 MM이 디자인 스페이스의 일부 영역을 울타리치듯(fence off) 막는 기능도 추가되는데, 대표적으로 Kepler(굵기, 폭, optical size)의 작고 두껍고 좁은 구석 구간을 사용자가 건드리지 못하도록 하는 데 쓰였다.
OpenType로의 전환 과정에서 MM 포맷은 폐기되었지만, 런타임 가변 폰트라는 개념 자체는 살아남는다.
Skia로 유명한 Mike Reed는 Multiple Master v1을 보다가 사실상 현대 가변 폰트를 발명하는 핵심 통찰을 얻는다. 꼭 코너에서 시작할 필요는 없고, 어떤 점이든 잡고 그 지점으로부터의 델타를 인코딩하면 된다는 것이다. Multiple Master와 마찬가지로, TrueType GX 폰트도 런타임에 인스턴스를 만든다.
이 접근법에서는 축을 많이 두는 게 자연스럽게 가능해진다. 4축 제한은 산산조각난다! 이것이 2016년 ATypI에서 발표된 variable fonts와 동일한 개념이다. 우리는 단지 20년쯤 휴식기를 가졌을 뿐.
맥락을 보자면, 애플은 자사 플랫폼을 완전히 통제한다. 덕분에 포맷을 새로 만들고 바로 배포할 수 있었다.
비슷한 시기에, 비트맵 폰트에서 업그레이드된 TrueType은 프린터 입장에서 디스크 공간 절약 수단으로 판매되고 있었다. GX도 그 흐름에 합류한다. 플로피 디스켓 한 상자를 치우고, 모든 포인트 사이즈를 지원하는 40KB짜리 폰트 하나로 대체하라는 식이다.
당시 스타일답게 애플은 그 어떤 것도 오픈 소스로 공개하지 않는다. 문서화도 형편없다고 평가된다. 이런 점들이 오늘날의 variable fonts가 실제로 나오기까지 지연을 초래했을 가능성이 크다.
참고 자료:
Skia(견본)는 처음으로 의미 있는 가변 폰트로 배포된 사례다. "QuickDraw GX" 폰트로 묘사되며, 굵기(weight)와 폭(width) 변화를 제공한다. 슬라이더 UI까지 갖춘 데모가 https://vimeo.com/120047887 에 있다.
애플은 폰트 제작을 위해 David Berlow를 고용했다. 약간 의역하자면, 여러 출처가 동의하길, 가변 폰트 디자인의 속속들이를 Berlow만큼 잘 아는 디자이너는 없다. 그는 90년대부터 이걸 삶으로 겪어 온 사람이다.
Berlow의 유명한 애니메이션 도마뱀은 Zycon에 들어 있으며, 90년대 중반에 탄생했다.
FreeType에 "Apple의 변형 가능한(distortable) 폰트 기술" 지원이 추가된다(커밋).
Superpolator가 2004년에 출시된다. 내부적으로는 파이썬 MutatorMath 라이브러리를 사용한다.
Adam Twardoch이 W3C Webfonts Working Group에 Multiple Master 부활을 제안한다. 메일 스레드에서 웹의 동적 컨텍스트가 애플리케이션 UI나 인쇄보다 더 많은 이득을 볼 수 있다고 지적한다.
한편 구글은 Noto 3단계를 진행 중이다. 그때까지는 바이너리만 수집하고 있었다. Apache 2가 말하는 "수정에 선호되는 형태"로서의 "소스"는 없으니, 일반적인 의미의 오픈 소스로 보긴 어려운 상태였다.
"소스" 형태란, 수정에 선호되는 형태를 의미하며, 소프트웨어 소스 코드, 문서 소스, 설정 파일 등을 포함하되 이에 한정되지 않는다.
이 점이 Mr B를 괴롭힌다. 올바른 의미의 오픈 소스로 만들기 위해서는 소스가 필요하고, 또 가변 폰트 같은 멋진 걸 하려면 소스가 필수다. Noto 3단계에서는 소스를 제공하는 것이 목표에 포함된다.
A List Apart에 Variable Fonts for Responsive Design이 실린다.
Mr B는 소스가 온다는 걸 안다! 신난다! 하지만 ... 그 소스를 어떻게 _빌드_해야 하지? 우리는 지금까지 소스가 없는 바이너리에서, 소스+바이너리로 가려 한다. 그런데 소스로부터 바이너리를 컴파일할 방법이 없다.
컴파일러가 필요하다! 그 컴파일러는 가변 폰트를 빌드할 수 있어야 한다. 그러면 컴파일러를 만들 재료로 쓸 수 있는 것은 무엇이 있을까?
FontTools는 어려운 부분을 이미 많이 구현했고, 오픈 소스다. Mr B는 이것을 기반으로 쌓기로 결정한다. fontmake가 탄생한다! fontmake는 처음부터 가변 폰트를 빌드할 줄 안다.
.glyphs plist 파일을 읽기 위해 glyphsLib를 작성한다몇 가지 거친 부분도 있었다:
이 새롭고 근사한 가변 폰트를 빌드하기 위해 .designspace 파일과 designspaceLib(@letterror 제작)가 탄생한다. 이는 의존성 혼란을 줄이고, "FontTools로 삶 속의 기본적인 폰트 작업은 다 할 수 있다"는 생각을 유지하기 위해 FontTools에 병합된다.
이제 가변 폰트를 만들 수 있게 되었지만, 여전히 고통스럽다. 먼저 fontmake로 ttf-interpolatable 파일을 만든 다음 varLib를 수동으로 실행해야 한다. 변이 축이 하나만 지원되던 시기라 varLib는 비교적 단순했다.
@simoncozens가 가장 좋아하는 부분, 즉 폰트 컴파일의 병합 단계가 도착했다!
인스턴스 생성에는 MutatorMath가 사용된다.
2014년 가을, ATypI 바르셀로나에서 여러 핵심 내용이 공개된다:
MutatorMath는 가변 폰트로부터 인스턴스를 계산하는 데 필요한 모든 것을 제공한다. 이제 이것이 공개·오픈 소스가 되었으니 ... 보간을 클라이언트에서 하면 어떨까? — 이것이 본질적으로 오늘날의 가변 폰트다.
fontmake가 점점 완성되어 간다. 이제 직접 가변 폰트를 빌드할 수 있어서, 여러 단계를 거치는 수동 파이프라인이 필요 없다.
@brawer가 FontTools에 gvar를 구현한다.
Mr B는 클라이언트 측 보간에 대한 멋진 아이디어를 피칭한다. 변화하는 폰트. 이름을 variable fonts라고 붙일 수도 있겠다?
glyphs2gx.py 같은 탐색적 작업이 공개되기 시작한다.
Mr B는 폰트 포맷에 멋진 기능들을 넣을 수 있으면 좋겠다고 생각한다: OpenType BE. 이 가운데 일부는 2023년 현재도 적극적으로 개발 중이다. https://github.com/harfbuzz/boring-expansion-spec
fontmake는 소스에서 바로 가변 폰트를 생성하는 법을 배운다. varLib는 다축(multi-axis) 가변 폰트에 대한 델타를 계산하는 법을 익히고, 그 결과 fontmake로 그런 폰트를 빌드할 수 있게 된다.
즉, 가변 폰트를 빌드할 수 있게 되었지만, 여전히 골칫거리가 있다.
Mr B는 OpenType GX, 탐색적 제안을 작성한다. 라이브러리와 도구들이 등장함에 따라 생기는 영향이 이렇게 요약된다:
Superpolator / MutatorMath 같은 도구는 물론 Glyphs, RoboFont 같은 현대적인 폰트 에디터 덕분에, 보간(interpolation)은 최근 몇 년 사이에 흔한 작업이 되었다.
Microsoft, Adobe, Monotype, Google — 이하 카발(The Cabal) — 은 4월에 모여 가변 폰트 프로그램을 시작한다. 그리고 9월 발표까지 매달 만난다.
The return of Multiple Master가 쇼를 완전히 장악해 버린다! 카발은 아마 속으로 승리의 퍼레이드를 했을 것이다.
John Hudson은 Introducing OpenType Variable Fonts에서 이 새로운 물건이 정확히 무엇인지 가장 잘 알려진 설명을 쓴다.
Mr B는 오픈 소스 빌드 파이프라인의 현황에 대해 슬라이드를 발표한다. 초점은 Noto지만, 실제로 구축되는 것은 범용적인 시스템이다.
가변 폰트의 크기와 복잡도는 계속 증가한다. fontmake는 여전히 잘 작동한다. 다만 사용자는 더 빠르기를 원하고, 엔지니어는 더 단순하길 바란다.
fontmake에는 수많은 최적화가 적용된다. 일부는 Cython으로 포팅되고, 많은 작업이 메모리 안에서 처리되지만, 사용자는 여전히 더 빠르기를 바란다.
MutatorMath는 2017년에 https://github.com/LettError/ufoProcessor 를 낳는다.
우리는 여전히 더 크고 복잡한 폰트를 만들고 있다. fontmake는 여전히 잘 작동한다. 사용자는 여전히 더 빠르기를 바란다.
걱정할 것 없다. Rust로 다시 쓰면 되니까: