작년 가을엔 <응답하라 199x>라는 레트로 장르의 TV 드라마가 인기가 많았다.
요즘은 사극 드라마라도 하나 방영되면 전국의 역덕후들이 벌떼처럼 일어나서 별 희한한 곳에서 고증 오류들을 찾아 올리는 게 관행이다. 이 드라마 역시 예외가 아니었다.

2013년 10월 18일 방영분에는 아래와 같은 유명한 장면이 나온다.

사용자 삽입 이미지

서울 지하철 1호선의 노선색이 빨간색이고 역명판이 둥글게 만들어져 있던 옛날 시절을 재현한 것까지는 좋다. 솔직히 말하면 본인조차도 그 실물을 본 적은 없다. 본인은 서울 태생이 아니며 서울 지하철을 이용하기 시작한 건 21세기부터이기 때문이다.

그럼에도 불구하고 저 장면에는 여러 크고 작은 고증 오류가 존재한다.
벽면의 인테리어가 실제 지하철 서울 역과 다르며 섬식 승강장 역을 상대식 승강장으로 만들어 놓은 건 애교라 친다만...
역명판의 글꼴을 2003년에 만들어진 걸로 쓰면 어떡하냐. 무려 코레일체!

20세기 설정에 너무 깔끔한 21세기 서체가 혼자 확 튀어 보인다.
게다가 저건 철도청/코레일의 전속 서체이지 서울 지하철에서 쓰던 서체도 아니다.
완전 어처구니없는 고증 오류가 아닐 수 없다.ㅋㅋㅋㅋㅋ

또한, 글꼴만치 부각되는 건 아니지만 '서울驛'이라는 한자 병기가 들어간 것도 오류다.
서울 지하철이 처음 개통했을 때는 역명판에 한자 병기가 없었기 때문이다. 그건 1999~2000년대가 돼서야 추가되었다. 딱 그 시기에 로마자 표기법 개정분 반영, 한자 병기와 더불어 국철(= 광역전철) + 지하철 노선색 통합까지 몽땅 진행되었으니 수도권 전철의 외형이 크게 바뀌는 시기였다.

그건 그렇고 아무튼...
그럼 1994년 기준으로 코레일체 대신 저기에 무슨 글꼴이 들어가야 맞는지 궁금하다면, 아래의 '진짜' 옛날 사진을 참고하시기 바란다. 엔하위키엔 관련 자료가 이미 다 올라와 있다. ㅎㅎ

사용자 삽입 이미지

시대를 풍미해 온 지금의 지하철 전속 서체와 같거나 최소한 비슷한 투의 납작한 헤드라인이 그때에도 쓰였다.
초롱테크에서 1990년대 중반에 정식으로 내놓은 그 디지털 서체는 그걸 좀 더 세련되게 다듬은 게 아닐까 싶다.

사용자 삽입 이미지

본인은 개인적으로 이 서체를 굉장히 좋아한다. 마치 런던 지하철의 전속 서체가 그야말로 런던 지하철 전체의 정체성을 대변하는 명물이 되어 있듯, 저 서체는 수도권 전철까지는 아니어도 서울 지하철을 대표하는 서체가 되기에 손색이 없다고 생각한다.

사용자 삽입 이미지

그런데 왜 그걸 함부로 바꾸고, 이미 만들어 놓은 멀쩡한 시설까지 돈 들여서 뜯어고치고 있는지 모를 일이다.
서울 도시철도 공사 관할역들의 경우, 지상에 있는 검은 배경의 세로형 역 폴사인의 서체가 어느 샌가 야금야금 서울 남산체로 바뀌고 있다.

오히려 지하철이 아니라 광역전철 소속이어서 우측도 아닌 좌측통행으로 건설된 신분당선이 클래식 지하철체를 살려 쓰고 있으니.. 혼란스럽다.

음, 그나저나 응답하라 1994의 오류가 또 생각 났다.
내가 언뜻 본 기억으로는 그 드라마 내부에서 등장하는 TV 뉴스 화면의 자막이...
굴림은 양반이고 아예 나눔고딕인 장면이 있었다!

서 태지가 은퇴하는 소식이 나오는 20세기 복고 드라마에, 2008년 한글날에 무료 배포된 서체가 등장한다는 게 말이 되냐.. ㅋㅋㅋㅋ

요즘은 유튜브만 검색하면 1990년대 옛날 영상 매체의 주요 장면을 아주 쉽게 구할 수 있다.
자막에다가는 엑스포체나 그래픽체만 넣었어도 지금으로부터 2, 30년 전의 영상 매체의 구리구리한(?) 분위기를 아주 손쉽게 낼 수 있었을 것이다. 무슨 서체를 쓰든 CG 처리는 똑같이 필요했을 텐데, 이게 무슨 돈이 더 드는 일도 아니고!

사용자 삽입 이미지

* 결론

1. 이렇듯 글꼴 유행도 시대에 따라 변한다.
2. 철도와 성경의 융합에 이어 철도와 글꼴의 융합도 얼마든지 가능하다.

Posted by 사무엘

2014/01/06 08:13 2014/01/06 08:13
, , ,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/917

한글 글꼴 처리 기술의 변천사

※ 0세대

0이라는 숫자는 뒤에 나올 1~3세대와 비교했을 때 '상대적인' 관점에서 붙여졌다. 1~3에 비해 0은 기계/아날로그적인 성격이 짙다.
한글을 모아쓰기+네모꼴 형태로 표현할 여건이 도저히 안 되는 환경을 말한다. 한 낱자를 상황에 따라 여러 벌로 분간해서 처리할 수가 없고, 최소 수천 자에 달하는 한글을 글자 단위로 부호화할 수도 없다.

옛날에 전보가 한글을 풀어쓰기 형태로 찍었다고 그러고, 김 정수 교수가 고안한 한글 두벌식 기울여 풀어쓰기도 0세대 기술이다. 굳이 풀어쓰기가 아니라도, 쓰이는 한글 몇 글자만 그림처럼 다루는 것도 딱히 기술이란 게 쓰인 게 아니므로 넓게는 0세대 기술로 간주한다.

그나마 0세대 기술 중에서 한글의 원리를 가장 잘 반영한 바람직한 기술은 공 병우 한글 세벌식 타자기, 그리고 그 이념을 물려받은 직결식 글꼴이다.

※ 1세대

제한된 벌수의 자모를 조합하여 한글 글자를 정사각형에다 모아쓰기 형태로 찍을 수 있다. 16*16 크기의 화면용 조합형 한글 글꼴이 바로 1세대의 상징이다.

옛날에 자체 한글을 지원하던 국내 도스용 프로그램들은 전부 이 수준의 기술을 사용하였으며, 도스용 아래아한글 1.x는 더 나아가서 간단한 수준의 옛한글과 자체 조합 로직까지 구현했다. 1세대 기술은 작고 간결하면서도 한글의 조합 원리와 무척 잘 부합한다는 큰 장점이 있기 때문에, <날개셋> 편집기 역시 최소주의를 추구하는 차원에서 딱 이 수준의 기술만을 의도적으로 고수하고 있다.

철도역 승강장의 전광판이 0세대인 롤지나 플랩에서 LED로 바뀌면서 1세대 기술로 한글을 표현한 것들이 많다.

※ 2세대

1세대보다 많이 발전했다. 8*16, 16*16의 한계를 벗어나 글자 크기를 자유롭게 조절할 수 있고 심지어 윤곽선 글꼴을 지원한다. 영문의 경우 W와 I의 폭이 다른 가변폭 글꼴을 지원한다. Windows의 경우 트루타입 글꼴이 도입되면서 글꼴의 기술 수준이 1.x세대에서 2세대 수준으로 껑충 뛰었으며, 아래아한글도 2.x 버전으로 넘어가면서 이 수준에 도달했다.

디스플레이 소자의 기술이 발달하면서 요즘은 전광판이 청색이나 흰색을 포함한 원색도 잘 표현하고 해상도도 더욱 높아졌다. 그래서 종전의 16*16만으로는 글자의 크기가 너무 작기 때문에 2세대로의 전환은 필수이다.
그러나 2세대 기술은 구현체마다 차이는 있지만, 1세대에 비해 한글 자체만의 조합 가능성이나 옛한글 표현 능력은 오히려 퇴보한 경우가 많다. 1코드 포인트당 반드시 한 글자가 대응한다는 한계에 여전히 매여 있기 때문이다.

※ 3세대

글꼴 처리 기술의 만렙으로, PC에는 21세기 무렵부터 도입되었다. 한글까지 가변폭 글꼴의 처리가 완벽하게 지원되며, 가변폭으로도 모자라서 커닝까지 처리된다. OpenType 기술을 이용하여 아랍· 태국어 문자까지도 꼼수 없이 잘 처리할 수 있을 정도인데 하물며 옛한글쯤이야 모아쓰기 형태로 표시를 못 할 이유가 전혀 없다.

유니코드라는 건 이런 글꼴 처리 기술과 결부되지 않을 수가 없는 규격이다. 그렇기 때문에 문자의 서식을 전혀 고려하지 않는 텍스트 에디터를 만든다 해도, 이제는 유니코드를 완벽하게 지원하려면 워드 프로세서를 만들 때나 필요할 것 같은 이런 기술을 어느 정도 사용하지 않을 수 없게 되었다.

3세대에서는 글꼴의 화면 렌더링도 단순한 grayscale 수준을 넘어서서 LCD 화면의 픽셀 구조에 특화된 subpixl 방식을 지원한다.

Posted by 사무엘

2013/08/31 19:47 2013/08/31 19:47
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/872

북한의 한글 서체

북한에서 만든 한글 서체의 중요한 특징 중 하나:
ㅌ을 E 모양이 아니라 ㅡ+ㄷ 모양으로 쓰는 걸 선호한다! 즉, 위의 가로줄을 아래의 몸통과 분리해서 따로 적는다는 뜻이다.

사용자 삽입 이미지

물론, 북한 서체 중에도 E자 모양인 물건이 없는 건 아니다.
그러나 일단 북한의 굴림-바탕-돋움-궁서에 해당하는 4대 기본 글꼴인 천리마-청봉-광명-붓글이 모두 ㅌ이 ㅡ+ㄷ모양이니, 북한에서는 이걸 ㅌ의 공식적인 기본형으로 간주하는 듯하다.

남한에서 쓰는 글꼴 중에는 ㅌ이 그렇게 돼 있는 물건은 진짜 궁서체밖에 없지 싶다.
북한이야 원래 문화가 196, 70년대-_-의 복고풍을 추구하고 서체도 순명조 내지 붓글씨 계열을 쓰는 걸 좋아하는 동네이긴 하지만, 명조 계열 서체까지 ㅌ을 그렇게 적는 관행은 남한에서는 좀체 찾아볼 수 없다.

북한과 한글 서체라는 두 분야에 모두 평균 이상으로 관심이 많은 나조차 이걸 눈치채는 데 시간이 굉장히 오래 걸린 이유는, 역시 ㅌ이 자주 쓰이는 자음이 아니기 때문이어서인 것 같다.

두음법칙만큼이나 한글의 자형의 미세한 차이도 남북의 문화 차이를 나타낼 수 있는 잣대가 된 듯하다.
원래 ㅌ의 모양은 ㅡ+ㄷ이 맞다는 설명도 옛날에 본 것 같으나, 그 근거를 모르겠다. 당장 훈민정음해례 같은 엄청 옛날 문헌을 봐도 ㅌ은 E 모양으로 그려져 있는데?

Posted by 사무엘

2013/07/23 08:36 2013/07/23 08:36
, ,
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/858

1. 라틴 알파벳의 위엄

오늘날 세계 문자들 중에 라틴 알파벳은 인지도와 실용성 면에서 단연 절대적인 '갑'임을 부정할 수 없다. 라틴 알파벳은 다음과 같은 여러 장점과 유리한 점이 있다.

  • 어느 한 국가나 민족만의 문자가 아니다. 물론 나라의 정서법마다 알파벳을 읽는 방식에 대동소이한 차이가 있어서 혼동스러운 면모도 있지만, 어쨌든 가장 국제적이다.
  • 음소문자여서 나름 다양한 언어의 말소리에 대응하기 유리하다. 또한 풀어쓰기를 하는 구조여서 언어의 다양한 음절 구조에 대응하기에도 유리하다.
  • 글자 수가 적어서 간편하며 활용하기도 쉬운 구조이다. 가령, 세계의 문자들 중에 기계식 타자기로도 만들고 또 겨우 8*8 크기의 비트맵에 각 글자의 모양을 다 담을 수 있는 문자는 얼마 되지 않을 게다.
  • 각각의 글자들이 들쭉날쭉하고 개성이 뚜렷해서 한데 뭉쳤을 때 시각성이 뛰어나며, 기호로서의 역할도 하기 좋다.
  • 타이포그래피 관점에서는 문자 차원에서 대소문자 구분이 존재하고, 또 이탤릭체 같은 같은 방식으로도 호소력을 높일 수 있다.

물론 라틴 알파벳은 표음· 음소문자라는 취지와는 달리 현실은 시궁창으로 언문일치가 개떡이며, 구조적으로 모음 글자가 너무 부족하다는 한계도 있긴 하다.

그럼에도 불구하고 라틴 알파벳은 신경 써야 하는 글자 수가 겨우 수십 개에 불과하기 때문에, 개개의 글자가 그야말로 왕이며, 서체 디자이너는 각 글자에 대해 완전 올인 몰빵 최적화가 가능하다. 이게 개인적으로 가장 부럽게 느끼는 점이다.
가령, A~Z까지 아주 정교하게 테스트된 수제 힌팅 프로그램을 집어넣는 여유를 부리는 건 이미 20여 년 전에 트루타입 글꼴이 처음으로 도입됐을 때부터 있었던 일이다.

그리고 요즘 글꼴이라는 건, 그저 코드값별로 고정된 글자의 폭과 벡터 이미지만을 기술하는 static한 데이터의 집합이 아니다. OpenType 기술 규격 덕분에 자기 옆에 무슨 글자가 오느냐에 따라서 다른 모양을 제공할 수 있고(GSUB), 폭을 미세하게 달리할 수도 있다(커닝.. 이게 개념적으로 더 확장되어 GPOS).

알파벳 정도야 문자 개수를 제곱해 봐야 몇백~몇천 정도까지의 조합밖에 안 나오니, 그 정도는 감당 가능하다. 한글이 '가' 할 때 ㄱ과 '고'나 '강' 할 때 ㄱ의 모양이 서로 달라지는 게, 알파벳으로 치면 W 다음에 A가 올 때와 W 다음에 P가 올 때의 간격을 미세하게 달리 설정하는 것과 같다는 뜻이다. 무슨 뜻인지 아시겠는가?

이런 기술은 이런 게 반드시 있어야만 정서법 차원에서 제대로 표시가 가능한, 복잡한 외국어 문자(complex script. 태국어나 아랍어 문자 같은)를 위해서 개발된 것이다. 그런데 라틴 알파벳은 원래 그런 기술의 도움을 받아야 할 정도로 복잡한 문자가 아님에도 불구하고, 더 정교하고 아름다운 타이포그래피를 위해 서체 디자이너가 그런 최신 기술까지 적용하여 시쳇말로 가히 잉여짓을 하고 있는 것이다. 가령, 라틴 알파벳도 아주 정교하고 미려한 필기체 중에는 그렇게 다이나믹한 표시 조건이 필요한 것도 있으니 말이다.

2. 반대편 극단에 있는 한자와 가나

이렇게 소수의 유한한 글자들이 왕인 라틴 알파벳 문화권에 비해, 글자 수가 엄청 많은 CJK는 상황이 굉장히 다르다.
한자는 전세계의 문자들 중 유일하게 '열린-_- 집합'인 무지막지한 문자 시스템이다. 덕분에 가변폭-_-이라든가 글자간의 다이나믹한 상호작용 같은 개념은 전혀 존재하지 않는다. 그래도 각각의 글자 자체가 워낙 그림처럼 생겼기 때문에 그 특성을 살린 타이포그래피가 존재한다.

거기에다 일본어 정서법은 한자에다가 자기네만의 간단한 표음문자가 더해져서 상황이 또 달라진다.
일본어는 입력하기가 굉장히 복잡하고 어려운 축에 든다. 그리고 '가나'라고 불리는 고유 문자는 구조적으로 불완전하며 한글에 비해 스케일이 작고 표음 능력에 한계가 있는 게 사실이다. 일본어 정서법은 가나 전용이 현실적으로 무리이다. 한자를 쓰지 않으면 안 되는 상황이며, 한글하고는 분명 상황이 다르다.

그러나 이런 형태가 단점만 있는 건 아니다. 굵직한 의미를 강조하는 한자와, 비교적 단순한 모양인 가나가 어우러지면 그것도 또 개성이 있으며 시각성이 살아나서 읽기도 꽤 좋다. 유식한 용어를 동원하자면 function word와 content word가 딱 잘 구분돼 보인다.
또한 입력이 어려운 대신, 한번 입력된 일본어 문장은 문자 차원에서 한자, 히라가나, 가타카나 같은 적지 않은 양의 NLP 정보가 담기기 때문에, 형태소 분석이나 번역을 의외로 유리하게 만들기도 한다. 히라가나-가타카나 구분이 라틴 알파벳으로 치면 대소문자에 얼추 비슷하게 대응한다고 볼 수도 있다(완전히 같지는 않지만).

3. 한글은 멀티 패러다임

자, 이렇게 라틴 알파벳 쪽의 정황과 한자 및 일본어 정서법의 정황을 살펴보았다.
그렇다면 세종대왕이 창제한 그 우수하고 독창적인 문자라는 '한글'을 사용하는 우리는 상황이 어떨까?

한글과 관련해서 우리가 절대로 간과해서는 안 되는 점은, 한글은 단일 패러다임만으로 설명이 되지 않는 문자라는 점이다. 단적인 예로, 단일 패러다임으로 설명이 되지 않기 때문에 한글이 총 몇 자냐는 질문에 24자부터 시작해 67자, 11172자, 심지어 160여만 자 같은 사람마다 뒤죽박죽인 대답이 나오는 것이다. 각각의 숫자가 한글의 규모를 어떤 관점에서 측정한 것이겠는지는 독자 여러분이 알아서 생각해 보시라.

차라리 한자는 총 몇 자냐는 질문에 대해 “아무도 모른다”라는 대답이라도 곧바로 나오지, 한글은 대단히 특이한 경우가 아닐 수 없다. 그래서 유니코드에는 고육지책으로 한글이 자모와 글자마디가 모두 등록되어 있으며 이것은 내가 보기에 나쁜 선택이 아니다. 그러나 한글을 바라보는 패러다임의 대립은 심지어 컴퓨터 전문가 사이에서도 거의 종교적인 신념의 대립에 가깝다. 이 말이 무슨 뜻인지 잘 모르겠으면, 본인에게 개별적으로 물으면 대답해 주겠다.

한글이 이런 유별난 위치에 있는 이유는 두 말할 나위도 없이 초-중-종성을 모아서 한 글자를 이루는 구조이기 때문이다. 만약에 한글이 IPA의 지위를 노리는 범용 음성 부호를 염두에 두고 만들어졌다면, 굳이 모아쓰기를 할 필요가 없다. 로마자의 예에서 볼 수 있듯, 풀어 쓰는 게 자음이나 모음의 중첩 같은 각종 외국어들의 변화무쌍한 음운 구조의 대처에 더 유리하다. 지금의 모아쓰기 체계는 모음의 발음이 분명하고 받침이 자주 등장하는 한국어의 음운 구조에 좀 더 최적화/로컬라이즈 전략을 선택한 귀결이다.

그래서 한글은 한국어의 음절 구분이 분명하며 시각성과 개성이 더 뛰어난 문자가 되었으며, 구조적으로는 알파벳 같은 계열보다 한자 계열과 좀 더 비슷한 형태가 되었다. 이 선택은 매우 큰 장점과 개성과 자부심을 가져온 것이 사실이다. 그러나 한편으로는 우리가 기술적으로 풀어야 할 과제도 많이 만들었다. 로마자처럼 소수의 글자를 최적화하고 품질을 다듬는 데 투자될 수 있는 기술과 노력이, 한글 조합 그 자체의 문제만을 푸는 데 다 소비되어 버리게 되었다. 입력이든 출력이든 모두에서 말이다.

다시 말해, 1만 개, 1백만 개, 심지어 1억 개의 글자를 조합해서 생성할 수 있다고 하는 한글의 그런 잠재성은, 알파벳처럼 개개의 글자마다 완전 정교한 힌팅, 커닝, 이탤릭, 필기체 따위로 최적화가 가능한 면모와 기술적으로 공존할 수가 없거나, 최소한 상호 조화시키기가 대단히 매우 어렵다는 뜻이다. 그렇다면 모아쓰기라는 걸 현실에서 반드시 절대적으로 일방적인 장점이라고만 간주해도 되는 것일까?

그래서 옛날 한글 선각자 중에는 로마자의 직관적인 기계화 기술과 먼치킨 급의 타이포그래피 최적화에 너무 한이 맺힌 나머지, “우린 안 될 거야 아마”라는 비관적인 결론으로 빠져서 아예 <글자의 혁명> 급으로 한글을 풀어쓰기 형태로 마개조할 생각을 한 분까지 있었다. 다중 패러다임이 독이라고 생각했던 것 같다.

물론 그 의도는 이해하지만 그건 너무 과격하고 비현실적인 주장이다. 개개의 한글 낱자는 마치 일본어 가나만큼이나 완성도가 부족하다. 가나가 한자와 섞어 쓰라고 만들어진 문자라면, 한글 낱자는 모아 쓰라고 만들어진 문자인 것이다. 한글 낱자만으로 풀어 쓰려면 진짜로 모음 ㅡ라면 U처럼 바꾸는 식으로, 글자 자형을 좀 더 변별성 있게 고쳐야 하고 맞춤법까지 대대적으로 손을 봐야 한다. 위험 비용이 너무 클 뿐만 아니라, 풀어쓰기를 실제로 오랫동안 시행해 본 분의 증언에 따르면, 한글 풀어쓰기의 시각적 능률은 모아 쓴 한글 음절을 도저히 따라갈 수 없었다고 한다.

4. 이제는 한글 자체의 고유한 특성을 살려서 입출력 기술을 발전시켜야

결국 이 모아쓰기에 따른 다중 패러다임은 우리가 한글을 고유 문자로 사용하는 한, 우리가 언제까지나 지고 가야 하는 숙제이다. 예전에 컴퓨터의 성능이 열악하던 시절에는 한글 같은 복잡한 문자를 심을 길이 안 보여서 풀어쓰기라도 생각해야 할 것처럼 상황이 암울했다. 그보다 상황이 약간 나아졌을 때에도 겨우 일본의 자국 문자 로컬라이즈 방식을 모방한 2바이트 한글 코드에다 전/반각 문자 따위밖에 선택의 여지가 없었다.

그러나 지금은 그런 기술적인 제약이 없다. 유니코드에, 화려한 OpenType 기술까지 완비되어 있는데 뭘 더 바라겠는가? 한글은 기계화가 유리한 문자인 건 명백한 사실이다. 그러나 딱 그거 하나만 믿고, 기계화 수준이라는 게 과거의 타자기 내지 2바이트 한글 코드 시절의 기술적 수준에서 멈춘 채 발전이 정지해 있다. 그런 낙후된 기술 수준은 한글에서 제한된 일부 패러다임밖에 수용을 할 수 없다.

일례로 입력부터 먼저 살펴보면, 15년도 더 전의 윈도우 95의 마소 한글 IME의 설정 대화상자와, 지금 윈도우 8의 한글 IME의 설정 대화상자는 제공하는 기능이 차이가 거의 없다. 이거 좀 문제가 있다.
어차피 조합이 필요하고 IME 같은 계층이 필요하다면 그걸 살려서 IME 계층이 있어야만 할 수 있는 일을 추가로 많이 지원해 줘야 한다.. 이것은 내가 <날개셋> 한글 입력기를 통해 어느 정도 기술적으로 실현시켰으며, 이 분야의 발전에 대한 필요성은 내 석사 논문에다가도 충분히 언급해 놨다.

출력 쪽도 마찬가지이다. 앞서 언급했듯이 라틴 알파벳은 적당히 꼬불꼬불하고 스스로 들쭉날쭉해서 보기가 좋으며, 일본어는 한자와 가나가 어우러져서 보기 좋다. 그렇다면 한글은 단일 종류의 문자가 빽빽하게 모였을 때 어떤 미를 추구해야만 할까?
이제는 한글도 한자 중심의 획일적인 정사각형 타이포그래피를 벗어나서 커닝도 생각하고, OpenType 기술을 적극 활용한 다이나믹 글꼴이 더 많이 나와야 한다. 한글은 굳이 한자가 섞일 필요가 없는 stand-alone, self-contained 문자이기 때문이다.

한글은 각 낱자는 직선 아니면 원밖에 없어서 기하학적으로 의외로 무척 추상적이고 단순하다. 그러면서 초중종성의 개성이 아주 분명하니, 한자나 로마자와는 달리 각종 로고타입이나 픽토그래픽으로 형상화하기가 좀 까다로운 면모가 있다(여전히 그림이나 아이콘 같아 보이지 않고, 글자처럼 보임). 그러나 그런 식으로 모아 쓰는 한글의 특성 때문에 오로지 한글에만 적용할 수 있는 글꼴이 나올 수도 있다. 모아쓰기를 그저 거추장스럽게 한글 자모를 정사각형에다가 예쁘게 끼워 넣는 overhead, burden으로만 받아들이지 말고 좀 더 창조적으로 활용할 수는 없을까? 이것이 내가 현재 고민하고 있는 분야이다.

요컨대,

  • 한글을 굳이 여타 문자와 더 비슷하게 만들어서 단점을 상쇄하려 하기보다는, 한글의 개성과 장점을 더 살린다. “넌 그걸 할 수 있냐? 난 그걸 못 하는 대신이 완전히 새로운 이걸 할 수 있다. 놀랍지?”를 지향한다는 뜻이다.
  • 한국어의 특성은 배제하고 오로지 한글의 형태 자체만을 생각한다.

이것이 내가 전통적으로 생각해 온 연구 방향이다. 입력기도 그렇고 글꼴도 그렇다. 더 이상의 자세한 설명은 생략한다. 연구 결과물이 다 나온 뒤에 빵! 터뜨려야 하는 것이기 때문에 당분간은 비밀이다. 그렇다고 해서 그렇게 심하게 거창한 건 아니고.. <날개셋> 한글 입력기도 겨우 1.x~2.x 시절에는 아이디어만 새로웠지, 기술적으로는 그다지 거창하지 않았으며 허접함 그 자체였었다.

이런 식으로 입력과 출력 모두에서 한글의 기술적 가능성을 한 걸음 확장하는 시도를 골고루 달성하고 나면, 그것이 대중적으로 성공하든, 아니면 너무 과격하거나 시장성이 없어서 실패하든 난 대한민국이라는 나라에서 태어난 보람을 느낄 것이고 죽어도 여한이 없을 것 같다.

Posted by 사무엘

2013/03/27 19:38 2013/03/27 19:38
,
Response
No Trackback , 13 Comments
RSS :
http://moogi.new21.org/tc/rss/response/811

윤곽선 글꼴과 아이콘 이야기

1. 윤곽선 글꼴의 기술 디테일

옛날에 인쇄가 물리적인 활자로 행해졌고 컴퓨터에서도 비트맵 글꼴이 대세이던 시절에는, '폰트 한 벌'이라 하면 여기에는 서체뿐만 아니라 고정된 크기라는 개념까지 포함되어 범위가 더욱 제한적이었다.
진짜 말 그대로 활자 한 벌이다. 그 폰트가 제공하는 서너 종류의 크기로만 글자를 쓸 수 있는 것이다. 더욱이 컴퓨터용 서체의 경우 화면용과 인쇄용이 따로 있기도 했고 말이다. 한 서체를 나타내는 그런 각 크기별 폰트들을 모두 통틀어서 자족(font family)이라고 불렀다.

오늘날처럼 트루타입, 오픈타입 같은 베지어 곡선 기반의 윤곽선 폰트 기술이 보편화된 관점에서 보면, 다양한 크기를 얻는 건 너무 당연하고 하나도 특별할 게 없는 특성이지 않은가. 과거의 관행은 상상조차 하기 어려운 것 같다.
허나 과거에는 오히려 한 폰트가 혼자서 다양한 크기의 font family의 역할을 다하는 게 보통일이 아니었다. 그래서 글꼴 대화상자를 보면 트루타입 글꼴을 선택했을 경우 “이 글꼴은 트루타입 글꼴로, 화면과 프린터에서 동일한 글꼴이 사용됩니다”가 떴었다.

윤곽선 기술을 통해 크기 문제가 해결되고서야 영문 서체의 경우, font family는 다양한 크기의 집합이 아니라 bold나 italic 같은 변형의 총칭을 일컫는 개념으로 변모했다. 트루타입 글꼴이 도입되기 전엔 bold/italic은 그냥 원글꼴을 산술 연산으로 변형해서 구현했을 뿐, 별도의 글꼴로 만든다는 걸 생각하기 어려웠다. 조합 가짓수가 감당을 못 할 정도로 너무 많아지니 말이다.

인간이 쓰는 글자는 글자 하나하나가 생각보다 꽤 정교한 벡터 드로잉이다. 수많은 윤곽선 글꼴 자형을 화면에다 래스터라이즈 하려면 비트맵 글꼴만 상대하면 될 때보다 훨씬 더 많은 계산량과 메모리가 필요하다. 쉽게 말해 게임에서 2D 스프라이트가 3D 폴리곤으로 바뀌는 것과 비슷하다.

(지금이 아무리 컴퓨터의 성능이 좋아져도 3D 폴리곤으로 옛날의 스타크래프트 같은 수십· 수백 마리의 저글링 개떼 블러드를 구현하는 건 좀 찰진 맛이 안 난다. ㄲㄲㄲㄲㄲㄲ 또한 둠 2에서 둠 3으로 넘어가면서 가장 먼저 사라진 게, 예전 같은 광활한 개방된 맵에서 쏟아져 나오던 몬스터 개떼들이지 않던가. 뭐 어쨌든..)

그래서 자동차에 변속기가 필수인 것처럼 윤곽선 글꼴을 찍는 시스템은 운영체제든 무슨 프로그램이든간에 글꼴 캐시(font cache)가 반드시 있어야 한다. 쉽게 말해 자주 쓰이는 윤곽선 글꼴은 래스터라이즈된 비트맵 결과를 미리 저장해 놓고 재사용하라는 소리다.

제아무리 강한 엔진이라도 3~4단 기어에서 바로 출발 가능한 자동차는 없듯, 제아무리 날고 기는 고성능 폰트 엔진이라도 글꼴 캐시 없이 윤곽선 글꼴을 비트맵과 별 차이 없는 속도로 찍을 수는 없다.
폰트 캐시는 각종 운영체제나 소프트웨어가 잡아먹는 메모리에서 생각보다 많은 비중을 차지하고 있다. PC의 성능이 시원찮던 1990년대 중반에는 운영체제의 한글판과 영문판의 요구 시스템 사양의 차이를 만들 정도였다.

2. 힌팅

윤곽선 글꼴을 찍는 시스템은 이것만으로도 굉장히 복잡해지는데 또 하나 간과할 수 없는 것은, 바로 저해상도에서 심각하게 보기 안 좋아지는 품질 문제였다.
수백~수천 픽셀의 EM 크기에서 만들어진 매끄러운 윤곽선 패스를 수~수십 픽셀대로 축소하여 래스터라이즈하다 보면 획이 빠지거나 뭉개지거나 굵기가 뒤죽박죽이 되어 버린다. 컴퓨터의 래스터 디스플레이는 연속적인 실수가 아니라 유한한 정수 개의 픽셀로 구성되어 있으니 말이다.

요즘 유행하는 서브픽셀(ClearType)이라든가 그레이스케일은 한 픽셀에 담을 수 있는 정보량 자체를 흑백보다 더 늘려서 글자를 좀 더 부드럽게 보이게 하는 anti-aliasing 방법이다. 그러나 그 전에는 monochrome 디스플레이에서도 최대한 글자가 예쁘게 래스터라이즈 되게 하려면...

일단, 싱거운 결론이지만 이것은 원론적으로 100% 완전한 해결이 불가능한 문제이다.
래스터라이저를 아무리 귀신같이 잘 만든다 해도 이 획과 저 획이 어느 크기로 scale했을 때 간격이 같고 굵기가 같아야 할 기준을 스스로 찾을 수는 없다. 그 기준 자체가 아주 모호하고 인위적이기 때문이다.

결국, 서양에서 만들어 낸 것은 '힌팅'이라고 불리는 기술이다.
트루타입 폰트의 경우 이 힌팅이 특허로 등록되어 있었을 정도로 고급 핵심 기술이었다.
폰트 래스터라이저의 동작 알고리즘을 다 안다고 가정하고, 특정 크기에서 특정 글자는 윤곽점을 빼거나 추가하거나 위치를 옮겨서 인위적으로 이런 식으로 래스터라이즈되게끔(= 사람 눈에 보기 좋게) 윤곽선을 변조한다.

쉽게 말해 부가 정보를 덧붙인다는 뜻이다. 그래서 명칭도 힌트, 힌팅이다. 이건 100% 자동화를 할 수 없으며 장인의 정교한 수작업이 동원해야만 넣을 수 있다.
Times New Roman 같은 서체를 6~11포인트 크기로 anti-aliasing이 없이 보면 정말 하나하나 수작업으로 비트맵을 만든 게 아닌가 하는 생각이 들 정도로 모양이 예쁜 걸 볼 수 있는데, 그건 내장 비트맵이 아니라 힌팅만으로 주어진 윤곽선을 변형하여 만들어 낸 결과물이다. 래스터라이저의 범용적인 알고리즘만으로 만들 수 있는 결과물이 결코 아니다!

오늘날은 픽셀 자체를 anti-alias하는 기술이 발달하여 예전보다는 힌팅의 필요성이 줄어들었지만, 그래도 힌팅을 해 주면 윤곽선의 제어점이 래스터라이즈 기준 지점에 더 가까이 옮겨지기 때문에 뿌옇게 찍힐 것이 더 깔끔하고 배경과 글자 사이가 더 높은 채도로 찍히는 긍정적인 효과를 얻을 수 있다.

다만, 화면의 해상도까지 예전의 도트 프린터 수준으로까지 올라간다면 힌팅은 정말로 할 필요가 없고 그냥 anti-aliasing만으로 충분한 지경이 될 수 있다. 힌팅은 마치 옛날의 256색 팔레트 제어 기술만큼이나 legacy로 전락하는 날이 올지도 모른다.

그리고 한글이나 한자처럼 문자 집합의 크기가 커서 일일이 수제 힌팅을 도저히 줄 수 없는 문자는.. 애시당초 크기별로 내장 비트맵을 일일이 만들어 넣는 게 속 편하다. 뭐 요즘은 그 관행도 '맑은 고딕'을 시작으로 서서히 변하고 있긴 하지만 말이다.

3. 아이콘과 아이콘 패밀리

글꼴이 비트맵에서 윤곽선으로 넘어가면서 겪은 변화와 비슷한 맥락의 변화를 겪고 있는 곳이 또 있으니, 그건 바로 아이콘이 아닌가 싶다.

원래 응용 프로그램의 아이콘은 32*32 16컬러 크기만 있었다. 그러던 것이 Windows 95 이래로 16*16이 활발히 쓰이기 시작해서 메뉴나 작업 표시줄 같은 데서 좋은 인상을 주려면 오히려 16*16을 심혈을 기울여 잘 만들어야 하는 지경이 되었다. 아이콘 하나 때문에 Windows API에는 윈도우 클래스 등록용으로 WNDCLASSEX라는 구조체가 새로 만들어졌고 RegisterClassEx 함수가 도입되었다.

그러다 아이콘의 색깔은 256색 이상으로 늘고, 윈도우 XP에서부터는 트루컬러 정도가 아니라 알파 채널이 들어간 32비트 색상 아이콘이 등장했다. 덕분에 아이콘 하나도 크기가 수만 바이트로 늘고 프로그래머가 대충 발로 만들 수 없는 물건이 되어 버렸다. Visual Studio IDE는 최신 2012버전까지도 32비트 아이콘은 내용을 볼 수만 있지 고칠 수는 없다. 전용 그래픽 에디터가 필요해졌다.

그리고 윈도우 비스타부터는 32*32보다도 더 큰 48*48이 표준 크기로 또 추가되고, 아예 크기가 세 자리 수로 진입한 png 이미지가 아이콘 안에 들어가는 경지가 되었다. 이젠 아이콘 이미지도 예전 관행처럼 압축 없이 저장했다간 크기가 너무 커지기 때문이다.
XP까지만 해도 수만 바이트에 불과하던 간단한 메모장 프로그램이(notepad.exe) 별로 기능이 추가된 것도 없는데 비스타 이후부터 크기가 세 배로 뻥튀기 된 건 전적으로 아이콘 이미지 때문이다.

이렇게 아이콘의 크기가 커졌음에도 불구하고 아이콘은 역시나 본문 글자만큼이나 16*16의 작은 크기에서도 자신의 본분에 충실해야 한다. 이 점에서 아이콘은 글꼴과도 비슷한 구석이 있다. 단지, 크기뿐만 아니라 색상까지 고려해야 한다는 차이가 있을 뿐.

요즘은 굳이 16색까지 갖출 필요는 거의 없어졌지만, 프로그램의 한 아이콘은 똑같은 컨셉이더라도 자고로 최소한 256색과 32비트 트루컬러, 그리고 16, 32, 48과 심지어 경우에 따라서는 24나 40 같은 그 중간 크기까지 따로따로 갖추고 있어야 한다. 옛날에 크기별로 비트맵 글꼴을 따로 만들던 거랑 정확히 같은 맥락이니, 그야말로 font family에 착안하여 icon family라는 말을 만들어야 할 판이다.

그리고 작은 크기일 때는 수제 도트 노가다 말고는 정말 답이 없다. 큰 이미지를 무식하게 축소시켰다가는 품질이 그야말로 개판이 되기 때문. 아이콘에 무슨 힌팅 같은 게 있는 것도 아니니 말이다.
오늘날 아이콘은 점점 벡터 이미지처럼 되고 있는 면모가 있지만, 그렇다고 도트 노가다가 필요하지 않은 것도 아니니 참 오묘한 존재가 되어 간다는 생각이 든다.

language bar에 표시되는 각종 IME 아이콘들의 경우, 담겨 있는 정보는 단색이더라도 무조건 32비트 알파 채널 이미지로 만들지 않으면 운영체제가 아이콘을 화면에 제대로 표시해 주지를 않는다(Vista 이상 기준). 아이콘 출력을 재래식 GDI가 아니라 GDI+ 같은 다른 계층으로 하는 것 같다.

Posted by 사무엘

2013/03/16 19:31 2013/03/16 19:31
, ,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/807

명조(바탕)체의 역사

오늘날 인쇄물에서 본문용으로 타의 추종을 불허하는 압도적인 지위와 인지도를 자랑하고 있는 한글 서체는 명조, 혹은 바탕체이다.

너무 흔하게 보는 서체여서 잘 모를 뿐이지, 명조는 상당히 미려하고 잘 만든 서체이다.
붓글씨 계열과는 미묘하게 다르고 그렇다고 펜글씨 계열과도 완전히 같지는 않은 그 획과 삐침들은, 명조와 같은 계열로 곁들여져 쓰이는 알파벳이나 한자 서체와는 성격이 다르다. 예를 들어, 한자의 삐침을 그대로 적용한 한글 서체는 '순명조'라고 따로 있지, 일반적인 명조가 아니다. 한글의 명조와 조형이 가장 비슷한 계열을 찾자면 차라리 일본 문자의 명조인지도 모르겠다.

그런데 이 명조체는 생각보다 역사가 굉장히 짧다. 역사가 100년도 채 안 됐다.
영문의 Times체가 1931년에 나와서 Garamond나 Bodoni에 비해서 굉장히 젊은 서체 소리를 듣는다만, 명조는 더 어리다.

한글 서체는 20세기 이전에는 전부 흔히 말하는 옛체든 궁서체든 목판체든 어쨌든 붓글씨 형태가 전부였다.
그러다가 일제 강점기 때 흔히 말하는 성경체(산돌성경체..!) 같은 궁서와 명조 사이의 짬뽕 과도기를 거친 후,
1939년에 소년조선일보를 통해 발표된 '박경서체'에서 그나마 명조의 전신이라 할 수 있는 프로토타입이 나왔다.
이제야 붓글씨 서체가 아닌 활판 인쇄용 한글 서체가 논의되기 시작한 것이다.

그 후 1958년에 국정 교과서 활자체로 지정된 '최정순체'가 오늘날의 모든 명조 파생형의 원조라 할 수 있는 명조다운 명조로 자리잡았다.
그리고, 한글 서체 디자인의 아버지인 최 정호가 원도를 그린 '동아출판사체'도 비슷한 시기에 나와서 해당 출판사에서 나온 책과 사전의 본문에 쓰였다.

사용자 삽입 이미지
* 출처: 명조체의 역사를 한눈에 잘 정리해 놓은 곳

아하! 나 이 서체 기억한다. 'SM세명조'는 이 '동아출판사체'를 얇게만 고친 버전과 거의 일치한다. 어쩐지 비슷하더라. 옛날에 동아 출판사의 책들만 본문 서체의 모양이 약간 다른 게 이유가 있었다.
훗날 1991년에는 명조 계열 한글 표준 서체라는 타이틀로 '문화바탕체'가 나온다. 문화바탕은 동아출판사체 이래로 ㅈㅊ의 세로 꼭지가 오른쪽 끝이 아니라 중앙에서 시작하는 명조 계열을 계승했다.

1990년대엔 PC에서는 아래아한글이 보급한 한양 시스템 명조가 히트를 쳤으나, 출판계의 대세는 최 정호의 원도를 바탕으로 만들어진 SM계열 명조였다.
그러다 21세기에 들어서야 더 동글동글한 명조인 윤명조 시리즈가 유행을 주도하며 오늘날에 이르고 있는 중. 그 전에는 산돌이나 윤 디자인 서체들은 사실상 매킨토시에서나 볼 수 있었다. PC에서도 그런 서체들을 쓸 수 있게 된 건 빨리 잡아도 90년대 후반부터이다.

2000년대 이후부터야 최 정순의 명조 원도에서 더욱 변화를 준 나눔명조, 함초롬바탕 등 여러 본문용 서체들이 계속해서 발표되고 있는 중이다.

이런 우리나라에 비해, 북한은 서체 하나만 봐도 정말 시간이 수십 년 전에서 정지해 있음을 알 수 있다.;;
북한 서체는 여전히 남한으로 치면 1970년대 같고, 틀에 박힌 동일한 조합 로직에다 글자 꼴만 양산형으로 바꿔서 찍어 내는 것 같다. =_=;;
글쎄, 이런 것도 우열이 아니라 문화적 상대성이라고 존중해 줘야 하는 건가..?

북한에서 쓰이는 본문용 서체는 청봉이나, 역시 우리나라 서체와는 형태가 살짝 다르다.
그리고 우리나라의 순명조에 해당하는 서체로 북한에는 '광명'이 있다.
남과 북은 글꼴도 서로 이질적으로 바뀌고 있는 셈이다.

Posted by 사무엘

2013/01/17 08:33 2013/01/17 08:33
, , ,
Response
No Trackback , a comment
RSS :
http://moogi.new21.org/tc/rss/response/784

한글 입력기에 이어 다음은 글꼴 쪽 소식이다.

사용자 삽입 이미지
이게 과연 가능할까 나 자신도 장담할 수 없었는데 결국은 해냈다.
스크린샷의 프로그램은, 아래아한글 2.0 전문용에 들어있는 영문 신명조 HFT 파일을 읽어서 거기에 있는 글자를 찍은 모습이다.
TTF로 존재하지 않는 아래아한글만의 독창적인 글꼴--공한체나 휴먼옛체, 강낭콩 등--을 인증샷으로 보여야 더 재미가 있을 텐데, 아래아한글 2.0 시절에는 독창적인 글꼴이 아직 흔치 않았었다.

궁극의 오덕질의 승리.
뭐, 아예 압축 파일 포맷을 혼자 Reverse engineering만으로 알아낸 사람도 있는데, 이 정도 가지고 내가 딱히 RE의 귀재이거나 한 건 아니다.

아래아한글 2.0은 윤곽선 글꼴이 도입된 첫 버전이었고(무려 1992년 발매!), 지금의 아래아한글이 사용하는 '통합 글꼴' 포맷이 완전히 제정되기 전이었다. 글꼴 파일 내부에 아직 이름이나 제조사 같은 정보도 없고, 파일 포맷도 별도의 추상적인 계층이나 미래 확장 대비 공간이 전혀 없이 아주 아주 단순했다. 헥스 에디터로 딱 들여다보면, 이건 글자별 글립 데이터 오프셋 정보, 이건 글자별 폭(영문 가변폭 글꼴 기준) 이런 식으로 구간이 나뉘어 있겠다는 게 눈에 들어왔다. 구간을 나누는 데 성공한 것만으로도 최하 30% 이상은 성공이었다.

글립 데이터를 들여다보고 있으니, 처음 부분은 고정된 헤더인 듯하다. 그 지점 이후부터 가변 길이의 인스트럭션들이 나오는데(직선을 그어라, 곡선을 만들어라, 다음 폴리곤으로 넘어가라, 등의 그래픽 명령) 이건 알기가 쉽지 않았다.
그래서 가장 간단한 글자인 중고딕 . I L - _ (다 사각형 하나만 달랑 나오는-_-)가 어떻게 돼 있는지 분석하는 걸 시작으로, + = / : 을 이어 추적했다.

가장 마지막으로 원리를 알아 낸 건 물론 곡선 부분이다. 다행히 이 HFT는 트루타입(TTF)보다는 구조가 훨씬 더 단순했다. TTF 정도의 복잡도만 돼도 나 혼자서는 포맷을 못 알아냈을 것이다.
내가 이미 TTF 같은 더 복잡한 글꼴 파일 포맷의 구조에 대해 어느 정도 알고 있고, 그러니 뭐가 나올지 어느 정도 예상을 하고 있으며, HFT는 그보다 단순할 거라고 예상도 했기 때문에 해킹에 성공할 수 있었다.

다음 관심사는, 물론 아래아한글 2.1부터 지금까지 쓰이고 있는 통합 글꼴이다.
아래아한글 2.x 확장팩 글꼴들을 ttf로 바꿔서 윈도우 다른 프로그램에서도 쓰는 게 소원이다. -_-;;
언뜻 들여다본 바로는, 2.0하고는 인스트럭션들의 포맷이 살짝 다른 듯하다.

같은 한양 시스템 글꼴을 2.0 것과 통합 글꼴 것을 대조해 보면 분석이 훨씬 더 쉽겠지만, 안타깝게도 현재 아래아한글의 한양 시스템 hft 글꼴은 빡세게 암호화되어 있어서 분석을 할 수 없다. 파일 크기와 처리 성능으로 미뤄 보건대 내가 보기엔 압축은 아니고, 그냥 단순 암호화이다. HFT 중에서도 암호화가 안 된 글꼴만이 추후 분석 대상임.

아마 나는 아래아한글의 소스를 본 적이 전혀 없는 사람 중에서는,
글자 입출력과 관련하여 아래아한글이 사용하는 각종 데이터 파일의 구조를 우리나라에서 제일 잘 아는 사람일 것이다.
당장 <날개셋> 한글 입력기에 역대 아래아한글이 사용한 모든 custom 글쇠배열 파일을 읽어들이는 기능이 있으며,
바탕, 가는샘물, 필기는 도스용 아래아한글의 화면용 글꼴 파일을 추출한 것이다.

1월 10일 추가:
오늘 새벽. 통합 글꼴 HFT도 뚫는 데 성공. 단, 이건 내 혼자 힘만으로 한 건 아니다.
인증샷 대상 글꼴은 '신명 신명조'이다.

사용자 삽입 이미지

Posted by 사무엘

2012/01/08 19:23 2012/01/08 19:23
,
Response
No Trackback , 15 Comments
RSS :
http://moogi.new21.org/tc/rss/response/624

Times 서체 이야기

Times라는 단어가 쓰이는 곳이 어딜까?
수학에서는 '곱하기'를 나타낸다. 5 times 3 equals 15처럼. 디즈니의 만화영화 라이온 킹에는 I'm ten times the king Mufasa was! 라는 스카의 대사도 있다.

그리고 Times는 영미권에서 왠지 신문의 이름을 나타내는 경향이 있다. 뉴욕 타임즈가 대표적이고, 영국에도 The Times라는 신문사가 있다.
하긴, 신문 이름에 쓰이는 단어로 Herald도 있긴 하다. 성경에서는 딱 한 번, 다니엘서에서 느부갓네살 왕의 황금 형상에다 다들 절하라고(안 그러면 뒈진다고) 대국민 담화를 선포하는 자가 herald라고 나온다(단 3:4).

옛날에 윈도우 95 CD에는 Good times bad times라는 노래의 뮤직비디오도 있었는데 이건 그냥 잡설이고..

다시 Times라는 단어로 돌아오면, 이 단어는 오늘날 영미권에서 쓰이는 가장 유명한 본문용 서체의 이름이기도 하다. 워낙 너무 유명해서 이미 아시는 분들도 많을 것이다.
이 서체의 이름 역시 영국의 The Times 신문사 이름에서 유래된 것이다. 그렇다, 이건 신문사에서 만든 서체이다. 서체의 공식 명칭은 Times Roman인데 이건 우리로 치면 '조선일보명조', '한겨레결체' 이런 것과 완전히 동일한 작명법이다.

more..


Times가 만들어진 때는 1931년. 컴퓨터가 발명되기 전에 만들어지긴 했지만 Bodoni나 Baskerville만치 오래 된 서체는 아니다.
생김새가 기존 세리프 계열 서체들과 비교했을 때 사뭇 이질적이다. 이것 때문에 등장 당시에는 비판도 받았다고 한다.

가령, 2자의 모양을 보자. 세리프 계열이라면 좌측 상단 끝부분의 획에 동그란 세리프가 달리는 게 통념일 텐데 Times는 그렇지 않다. 사실은 6이나 9도 마찬가지. Times는 전반적으로 / 모양의 붓으로 글자를 그렸을 때 생기는 모양을 형상화했다.

그런데 전반적으로 모양이 무척 미려하고 아름답긴 하다. 무난하면서도 참신하고 잘 만든 서체이다. 컴퓨터 시대가 되면서 Times는 그야말로 신문을 넘어서 전세계 본문 서체를 평정했다. 거의 모든 책과 문서들이 이 서체로 만들어지게 되었다. 한국은 신문 명조와 일반 본문 명조 사이의 경계가 아직도 뚜렷한 편인데 이는 좋은 대조가 아닐 수 없다. 과거에는 신문용 서체가 세로쓰기에 맞춰져서 더 납작하고 뚱뚱한 편이기라도 했지만, 요즘은 세로쓰기도 다 없어졌는데 말이다.

Times는 한글 명조와 같이 쓰기에는 약간 어울리지 않고 혼자 튀는 경향이 있다. 뭐, 대다수의 영문 서체들이 그렇지만, 이들이 한글 서체와 잘 어울리려면 좀더 홀쭉하고 가늘어야 한다. 하지만 그런 전반적인 디자인을 차치하고라도 Times의 세리프는 뭐랄까, 좀 보수적이다. 그냥 명조보다는 문화바탕과 더 어울리는 것 같고, 윤명조 같은 파격적인 명조와는 어울리기 힘들다. Times보다는 Century Schoolbook 같은 부류의 세리프가 명조와 더 잘 맞을 것 같다.

그래서 Times의 획을 한중일 문자에 맞게, 아니 심지어 불변폭 서체 형태로 바꾼 변종이 있다. 과거 윈도우 3.1 시절의 바탕체에 포함된 영문· 숫자 글꼴이 그 예이며, 오늘날 MingLiu라는 한자 서체도 영문· 숫자 글꼴을 보면 딱 그렇다. 참고로, 불변폭은 아니지만 과거에 신명 세명조라는 서체가 내가 생각한 문화바탕+Times 컨셉과 굉장히 비슷한 모양을 세명조답게 아주 가늘게 변형한 형태였다.

Times는 그 중후하고 보수적인 분위기 덕분에, 문화바탕을 넘어 붓글씨 서체인 궁서와도 의외로 잘 어울린다. 사실, 오늘날 한글 서체에 같이 들어있는 영문· 숫자의 궁서체는 Courier 같은 딱딱한 타자기체-_-를 더 굵게 하고 눈꼽만치 기교를 넣은 뒤, 적당히 가변폭 서체로 바꾼 것에 더 가깝다.
어째 세리프 계열의 한글 서체에다가 산세리프 계열의 영문 서체를 집어넣었나 싶다만-_-, 어차피 영문은 붓글씨 테크닉이 정착해 있지도 않으니 붓으로는 아무 기교 없이 그렇게 글자를 그린다 해도 이상할 건 없겠다.

그 반면, 오늘날 역명판이 코레일체 대신 궁서체로 기재되어 있는 경춘선 김유정 역은, 궁서와 더불어 영문이 Times 서체로 기재되어 서로 잘 어울리고 있으며, Chick tracts 같은 미국의 전도지도 성경 구절은 Times로 적고 있다. 우리가 산돌성경체 같은 개역성경 붓글씨체를 보수적인 성경 본문체로 생각하듯이, 걔네들은 그게 보수적인 성경 본문체인 것이다.

여담이다만, 오늘날 타이포그래피의 대세는 산세리프와 세리프의 경계를 깨고(뭐, 굳이 하나만 고르자면 역시 세리프에 더 가깝지만) 화면 표시용 튜닝이 잘 된 그런 서체가 차지하고 있는 것 같다. 맑은 고딕, Segoe, 서울 남산 같은 서체들이 그런 유행을 따르고 있다.

옛날에는 그런 하이브리드 서체로 그래픽체가 아주 유명했고 참신했는데 지금은 그것도 너무 outdate돼 있다. 2, 30년 전의 TV 화면에서 그래픽체 자막을 보니 얼마나 격세지감이 느껴지던지!
오늘날은 Times 신문사도 Times가 아닌 다른 본문 서체를 사용한다는데, 이 Times에도 먼 미래에는 오늘날 우리가 중세 서체를 생각하는 것처럼 그런 고전 서체가 되어 있을지도 모르겠다.

Posted by 사무엘

2011/09/05 19:07 2011/09/05 19:07
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/565

탈네모 글꼴에 대한 생각

한글 타이포그래피에서 탈네모 글꼴은 만년 떡밥인 것 같다. 지금 까지 그래와꼬 아패로도 그렇겠지

한글 가변폭 글꼴: 한글 글꼴 중에서 명조, 고딕 내지 한자 같은 부류와는 달리, 글자의 폭이 획일적이지 않고 글자마다 차이가 있는 글꼴을 일컫는다. 본문용으로는 잘 쓰이지 않고 특이한 제목이나 장식용으로 쓰인다. 아래에서 설명될 세벌식 글꼴과는 살짝 다른 개념으로, 세벌 글꼴은 굉장히 높은 확률로 한글 가변폭 글꼴이지만 모든 가변폭 글꼴이 세벌 글꼴은 아니다.

세벌식 글꼴: 공 병우 세벌식으로 만들어진 기계식 타자기로 글자를 쳤을 때 찍혀 나오는 자형과 같거나 최소한 상당히 유사한 구조를 하고 있는 글꼴. 일명 샘물체 내지 안상수체, 공한체 계열이다. 초중종을 이루는 벌수가 매우 적으며 글꼴 크기가 대체로 아주 작고 가볍다. 세벌식 글꼴은 거의 필연적으로 가변폭 글꼴이 되며, '가'과 '강'에서 '가'의 모양이 같아서 세로로도 기복이 크다는 특성상 '탈네모 글꼴'이라고도 분류된다.

그런데 문제는, 획일적인 정사각형을 탈피한 한글 글꼴에 대한 개인 호불호 편차가 굉장히 크다는 것이다. 국어학자, 타이포그래피 디자이너, 한글 기계화 연구인 중에서도 그런 발상 자체를 완전 개혐오하는 분이 좀 있다. 수 년 전, 한겨레 신문사가 이질감을 최소화하려고 무늬만 세벌 글꼴 흉내를 살짝 낸 한겨레결체로 본문 서체를 과감하게 바꿨는데, 당시엔 그것만으로도 “이거 도대체 뭐야?”(성경에 나오는 '만나'의 의미가 정확하게 이것이다-_-) 하는 반발이 벌써부터 터져나오기도 했다고 한다.

애초에 과거 기계식 타자기 시절에 네벌식, 다섯벌식 같은 불편한 입력 방식이 있었던 것도, 세벌식만으로 타자를 하면 자형이 너무 들쭉날쭉하고 못생겼기 때문이었다. 그만큼 사람들의 문자 습관이라는 건 무척 보수적이다.

그 반면에 서양 먹물 좀 먹었거나 일말의 선각자 자질이 있는 분은, 한글 자형이 정사각형 일색이기만 해서는 로마자(p, d, v 같은 들쭉날쭉 다양한 글자가 있는) 같은 가독성이 살아나질 않는다면서 그래도 탈네모 글꼴에 희망을 걸고 있는 경우가 있기도 하다. 그렇잖아도 국어 정서법에는 대문자도 없고, 고유명사도 없고, 영문 정서법 같은 엄격한 띄어쓰기가 정착해 있지 않으며, 문장 부호의 활용이 활발한 것도 아니다. 어찌 보면 굉장히 난감한 상황이 아닐 수 없다. 한글 전용론자라면 맨날 한글이 우수하다고 자뻑만 할 게 아니라, 현실에서 드러나는 한글의 단점을 한글로 해결하는 방법도 연구해야 하지 않겠는가?

컴퓨터용으로 만들어진 세벌식 글꼴은 최소한의 보정을 거친다. 가령, 간의 ㄴ은 감의 ㅁ보다 약간 위로 올라가며(공간이 너무 벌어지니까), 진짜 곧이곧대로 타자기 FM대로 1*1*1벌이라기보다는 최소한 2*1*2벌(특히 글자별 폭의 격차를 줄여서 디자인할 때) 이상이 시도되기도 한다.
<날개셋> 편집기에 존재하는 샘물이나 타자기 같은 글꼴은 에디팅 엔진의 한계 때문에 폭은 불변폭이나, 너그럽게 보면 세벌식 글꼴의 범주에 들어간다.

세벌식이라는 이념은, 한글을 풀어쓰기 형태로 파괴하지 않고 최소한의 형태와 원리를 유지하는 한편으로, 또 사람과 기계 모두에게 편리한 간결한 방법으로 한글을 입출력할 수 있는 정점을 찍은 일종의 교리이다.
탈네모 가변폭 한글 글꼴이라는 개념 자체는 글자판과는 별개로 일부 디자이너들이 시도하기도 했지만, 세벌식이 한글 글꼴에 그런 맥락의 변화를 시도하는 데에도 응당 영향을 끼쳤다고 볼 수 있는 셈이다.

이 이념의 영향을 받아 1980년대에 이미 안 상수 교수가 캐드를 이용한 디자인으로 안상수체 내지 안체를 개발했으며, 1990년대에는 한 재준 교수가 공 병우 박사와 합작으로 공한체와 한체 시리즈를 내놓았다. 대표적인 가변폭+세벌 글꼴이다.
안상수체는 아래아한글 2.1 (1993)에서 처음으로 도입되었고, 공한체/한체는 아래아한글 96에서 도입되어 우리에게 친숙해졌다.

여러분은 이런 탈네모, 세벌, 가변폭 한글 글꼴에 대해서 어떻게 생각하시는가?
일단, 이런 글꼴들은 생김새가 이질적일 뿐만 아니라 기존 네모 글꼴과는 디자인된 metric이라고 해야 하나, 전반적인 크기가 전혀 어울리지 않아서 같이 쓰기가 더욱 힘들다. 같은 크기로 맞췄을 때 저 글꼴은 여타 네모 글꼴들보다 훨씬 더 작아 보인다.

탈네모 글꼴을 처음으로 시도한 디자이너들은, 단순히 '생소하고 디자인이 정착해 있지 못하며, 완성도 높은 탈네모 글꼴이 아직 나오지 않아서 거부감이 드는 것일 뿐이다'라고 생각했다. 즉, 시간이 탈네모 글꼴의 문제를 점차 해결해 줄 거라고 생각했다. 실제로 2011년이 된 오늘날, 굳이 세벌이 아니더라도 가변폭 글꼴에 대한 국민적인 이질감은 예전보다는 줄어든 것 같다.

그러나 그래도 갈 길이 멀다. 아무래도 탈네모 글꼴이 명조· 고딕의 벽을 완전히 넘을 수 있을 것 같지는 않다. 특히 정사각형 안에 차곡차곡 자모가 질서정연하게 배치되는 명조· 궁서· 문화바탕 같은 미려한 서체의 완성도는, 탈네모 글꼴 주장자들이 결코 무시해서는 안 된다.
그런 글꼴이 괜히 수십~수백 년의 짬밥을 먹으면서 국민들로부터 사랑받고 살아남은 게 아니다. 탈네모 글꼴은 여전히 세리프 계열 글꼴이 빈약하며, 그나마 세리프 축에 드는 공한체는 진짜 무늬만 세리프이지 명조 같은 급에 비할 바가 못 된다. 즉 여전히 실험적인 수준을 벗어나지 못하고 있다는 뜻 되겠다.

하지만, (또 반전을 해야겠다)
그럼에도 불구하고
한글은 한자 같은 아예 픽토그램급의 상형문자가 아니고 일정한 규칙과 체계가 있는 '자질문자' 시스템인데..
천편일률적인 정사각형에만 맞춰 쓰는 건 많이 아까운 것도 사실이라고 본인은 생각한다.
이것이 앞으로 한글 타이포그래피가 풀어야 할 숙제 중 하나이다.

믿거나 말거나. MS 워드는.. 2007의 바로 직전의 2003 버전까지만 해도 가변폭 한글 글꼴이 전부 불변폭처럼 고정폭으로 찍혔다! 한글은 한자와 마찬가지로 무조건 정사각형이라고 전제를 했던 것 같다.
워드패드--정확히 말하면 그 밑에서 돌아가는 리치 에디트 컨트롤-- 도 초창기 버전은 마찬가지였는데, 이건 아마 윈도우 2000/XP 타이밍 무렵부터 개선되었지 싶다.

과거의 아래아한글 97은 정사각형 글꼴을 쓸 때는 안 그런데 공한체나 안상수체 같은 가변폭 글꼴로 한글을 입력하면 매번 줄 전체가 번쩍거리며 바뀌는 게 보여서 불편했다. 이 문제는 차세대 엔진 기반인 워디안/2002부터 바로 개선되긴 했다.

Posted by 사무엘

2011/08/25 09:23 2011/08/25 09:23
,
Response
No Trackback , 7 Comments
RSS :
http://moogi.new21.org/tc/rss/response/560

MS 제품들의 글꼴

1. 비주얼 C++의 글꼴

과거의 비주얼 C++ 4~6은 IDE의 글꼴 체계가 좀 특이했다.
영문 윈도우에서는 각종 UI 글꼴이 MS Sans Serif 8포인트로 나오고, 코드 에디터의 기본 글꼴은 Courier 10포인트로 나왔다. 트루타입 글꼴인 Courier New가 아님.

그 반면, 한글 윈도우에서는 코드 에디터의 기본 글꼴은 FixedSys 12포인트였고, 대화상자의 기본 글꼴은 무려 System으로 설정되었다. 글씨 크기부터가 다르다.
참고로, 비주얼 C++과 동봉된 Spy++ 유틸리티도 대화상자의 글꼴이 동일한 형태로 나왔다.
둘 다 MFC를 써서 개발된 것도 동일하니, 뭔가 동일한 UI 라이브러리를 공유라도 하지 않았나 추정된다.

이 윈도우 3.1스러운 System 폰트는, 비주얼 C++이 더욱 추레하고 꼬질꼬질하게 보이게 하는 데 큰 기여를 했다. -_-;;;
사실, 윈도우 3.1 시절에도 영문판에서 원래 MS Sans Serif 8포인트로 맞춰졌던 UI가 한글 윈도우에서는 한글 때문에 글씨 크기를 더 키워서 System으로 나왔으니, 비주얼 C++도 이와 동일한 관행을 답습하고 있었던 것 같다.

사용자 삽입 이미지

사용자 삽입 이미지

이후 버전인 닷넷은 그 글꼴 체계가 개선된 것만으로도 외형이 훨씬 더 깔끔해 보인다.
물론 MS 오피스 97 스타일의 UI가 오피스 XP 스타일로 바뀐 것도 작용했겠지만 말이다.
그 당시 윈도우 XP와 오피스 XP의 UI 디자인은 정말 파격적이었다. XP라는 브랜드 이름이 아깝지 않을 정도였다.

닷넷의 IDE는 신기하게도 에디터의 기본 글꼴이 돋움체 10포인트이다.
한글 윈도우에서는 자동으로 한글 서체를 찾아 쓰는 모양인데, 그럼 한글 글꼴이 없는 영문 윈도우에서는 뭐가 설정되는지 모르겠다.

2. 운영체제의 글꼴

한글 윈도우에서는 그저 굴림 일색이지만, 영문 윈도우에서는 MS Sans Serif에서 Tahoma로 UI 글꼴이 바뀌어 왔다.
MS 오피스도 그 구닥다리 97 버전도 영문판은 대화상자의 글꼴이 Tahoma이다. 보기에 꽤 참신하다는 생각이 들었다.

비주얼 C++이나 포토샵처럼 특정 계층의 전문 종사자들이나 쓰는 소프트웨어가 영문판인 것은 아주 흔한 일이다. 언어라는 숲이 중요한 게 아니라 해당 프로그램이 다루는 분야의 용어라는 나무가 훨씬 더 중요하기 때문에, 번역이 오히려 거추장스러울 정도이다.
그러나 운영체제나 오피스 스위트는 워낙 불특정 다수가 쓰는 녀석인 만큼 한글판이 널려 있다. 그렇기 때문에, 일부러 구하지 않는 이상 이런 프로그램의 영문판을 국내에서 접하기란 꽤 어렵다.

영문 윈도우 XP는 창의 제목의 글꼴이 일반 UI의 글꼴과는 달랐다. 제목 글꼴이 그 이름도 유명한 Trebuchet MS이었다. 온통 맑은 고딕이나 Segoe UI로 획일화되어 버린 윈도우 비스타/7조차도 그렇지는 않은데 말이다.
물론 한글 윈도우 XP는 제목의 글꼴이 역시나 '굴림+진하게'이기 때문에 영문판의 감흥을 느낄 수 없을 것이다.

그리고 더 신기한 것은 Trebuchet MS 글꼴이 한글 윈도우 XP에도 분명히 존재함에도 불구하고, 한글판은 디스플레이 글꼴 설정에 이 글꼴이 뜨지 않으며, 사용자가 강제 지정조차도 할 수 없다는 것이다. 그 글꼴 목록에는 모든 글꼴이 나타나지 않으며, 왜 그런지는 모르겠다.
마치 명령창(콘솔)의 글꼴도 왜 자유롭게 지정이 안 되는지 알 수 없는 것처럼 말이다.

3. 트루타입 글꼴의 역사

윈도우 운영체제에서 속이 채워진(=래스터라이즈가 되는) 윤곽선 글꼴이 처음으로 도입된 것은 무려 윈도우 3.1부터이다. 멀티미디어 API가 처음으로 도입된 것과 비슷한 시기이고, 공교롭게도 아래아한글 2.0이 출시된 것과도 비슷한 시기이다.
그 전에 존재하던 글꼴들은 몇몇 단계별로 지정된 크기 이외에서는 계단현상이 나타났다.
Script, Modern, Roman처럼 곡선이 그려지는 벡터 기반 글꼴도 없지는 않았으나, 그건 선만 그려지고 래스터라이즈 과정이 없는 원시적인 수준에 불과했다.

제대로 된 윤곽선 글꼴 기술의 명칭은 바로 트루타입(Truetype)이다.
Courier와 Times Roman은 영문권에서 워낙 유명한 글꼴이고 윈도우 1.0부터 있었던 잔뼈 굵은 글꼴인데, 이때 윤곽선 글꼴 버전이 새롭게 만들어졌다고 해서 Courier New와 Times New Roman이라고 new라는 단어가 중간에 붙었다. 한글 글꼴 '신명조'의 '신'과 비슷한 맥락인 건지도 모르겠다. 정리하자면 이렇게 된다.

  • Arial: 처음부터 윤곽선 글꼴로 도입되었고 예전의 Helvetica를 대체한 것으로 보인다.
  • Courier: Courier New와는 별개로 아직까지도 비트맵 글꼴의 형태로 공존한다. 두 글꼴은 폭이 살짝 다르고 제각기 용도가 있다.
  • Times New Roman: 이름에 new가 붙은 채, 기존 비트맵 글꼴을 윤곽선 글꼴로 대체

아울러, 한글 윈도우는 3.0부터... 영문 윈도우보다 한 발짝 일찍 트루타입 글꼴이 도입되었다. 그런데 그때 한글 글꼴들은 비표준 헤더를 썼기 때문에 정상적인 트루타입 글꼴이 아니었다. 그리고 시스템 비트맵 글꼴은 트루타입이 아닌 별도의 경로로 출력...-_- fallback 글꼴 같은 개념도 전혀 없고, 윈도우 95에 비해서 글꼴 시스템이 훨씬 더 열악하고 원시적이었다.

Posted by 사무엘

2011/05/01 08:35 2011/05/01 08:35
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/504


블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2020/07   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Site Stats

Total hits:
1403452
Today:
367
Yesterday:
520