1. 과거의 1바이트 기반 문자 코드

유니코드란 게 없던 옛날에 한중일이야 한자처럼 글자수 많고 획수 많은 정방형의 문자를 사용하다 보니, 코드 길이와 글자수가 잘 맞아 떨어지는 2바이트 기반 문자 코드를 사용했다.
그러나 유럽 각국에서는 1바이트 8비트에서 상위 비트가 1인 수십~100여 자의 문자만 자기 사정에 맞게 customize한 꽤 간단한 문자 코드 바리에이션이 여럿 쓰였다. CJK 2바이트에 쩔었던 채로 어린 시절을 보낸 본인으로서는 이해나 상상이 쉽지 않다.

IBM PC에서 쓰인 미국 원판은 일명 cp437이라고 알려져 있다. 그러나 이것 말고도 1바이트 기반 코드 페이지는 700~800대 번호로 여럿 존재한다. 가령, cp850은 오리지널 cp437과 대부분 일치하지만, 겹줄과 홑줄이 섞인 괘선 문자, 그리고 그리스 문자가 있던 곳에 모음 알파벳의 바리에이션이 더 배당되어 있다. 신기하다.

사용자 삽입 이미지사용자 삽입 이미지

128번 이후 영역에 온갖 알파벳+악센트 문자와 괘선· 기호가 들어가 있는 것, 1부터 31 사이에도 기호가 들어있는 것은 아스키 코드 오리지널 작품이 아니라 일종의 확장 규격인 셈이다. cp437과 파생형의 확장 규격은 최초에 어디에서 유래되었나 궁금해진다.

사실, 2바이트 한글 코드도 단순히 2바이트 문자만 정의한 건 아니다. 도대체 왜 그런 짓을 했는지는 모르겠지만 한국과 일본에서는 역슬래시를 잘 알다시피 원화/엔화 기호로 바꾸기도 했으며, 1~31 사이에 원래 있던 기호 대신에 반각 괘선 문자를 넣기도 했다. 전각 괘선만 있으니 공간 낭비가 심하고 불편했던가 보다. 이런 반각 괘선은 국제적으로 인정된 표준이었던 걸까? 뭐 그렇긴 했을 것이다.

흥미롭게도 과거에 쓰였던 1바이트 문자 코드 페이지들만 나열해 놓은 웹사이트가 있다. 마치 256색 시절에 쓰였던 다양한 팔레트들을 보는 느낌이다. 그것도 256개의 엔트리에다 고안자의 철학과 원칙을 담아서 색을 배당한 것이니까 말이다. 그러다가 색깔은 팔레트 따위 필요하지 않은 트루컬러로 바뀌고, 문자 인코딩은 유니코드 기반으로 다 바뀌게 됐다. 배고프고 암울하던 시절은 다 끝났다.

2. 이모지(emoji)

이모지란 글자처럼 취급되지만 글자를 가장한 각종 아이콘 그림이다. 원래는 기술적으로 갈라파고스화된 일본 내부에서만 문자 메시지나 채팅용으로 통용되었으며, 유니코드에서도 사용자 정의 영역에서나 머물 듣보잡에 불과했다. 그랬는데.. 갑자기 무슨 돈과 빽을 등에 업기라도 했는지 2010년대부터는 이게 유니코드에 정식 잔뜩 등재되고 전세계의 문자 입출력 기술의 변화를 주도하는 거물로 등극했다.

사용자 삽입 이미지

하긴, 이모지의 국제화 표준화에는 그 이름도 유명한 소프트뱅크 손 정의 회장이 크게 관여했다는 것이 알려져 있다. 오오~ 그래도 이것 덕분에 SNS나 채팅에서 일일이 번거로운 그림을 새로 올리지 않고도 간단한 표정 정도는 아주 간편하게 주고받을 수 있게 됐으며(특히 복사/붙이기까지!), 이로써 채팅의 편의성이랄까 감성지수도 더 올라갈 수 있게 됐다. 이모지는 온갖 듣보잡 한자들보다는 국제적으로 일상생활에서 쓸 일이 훨씬 더 많을 것이다.

오늘날 PC와 스마트폰에서 이모지 입출력은 필수 기능이 됐다. 이모지 때문에 (1) 만년 마이너 듣보잡 문자들로나 파묻혀 있었을 유니코드 확장 평면에 대한 인지도가 확 올라갔다. 그리고 한편으로 (2) '컬러 폰트'라는 것이 대중화됐다. 이전에도 이런 기술 자체는 있었지만 "그럴 바에야 그냥 전용 그림을 쓰고 말지, 저런 게 있어서 뭐해?" 수준이었다.

그러던 와중에 이모지는 글자와 그림의 경계를 한층 모호하게 만들었다. 마치 가수는 원래 오디오의 영역인 음악 잘 만들고 노래만 잘 부르면 되던 것이 언제부턴가 뮤직비디오 찍는 것에도 신경 쓰고 춤과 안무까지 해야 하는 것과 비슷해진 격이다.

OpenType 글꼴 파일 내부에 새로운 테이블이 추가되어 png 비트맵 이미지나 svg 벡터 이미지가 들어가게 됐다. 아이콘이 색상과 해상도가 올라가면서 png를 내장하게 되긴 했는데, 그 다음으로 글꼴도 뒤를 따르기 시작한 셈이다.
Windows(벡터 위주)와 mac(비트맵 위주), 안드로이드(??) 같은 진영 간에 컬러 폰트를 표현하는 기술이 좀 제각각 따로 노는 것처럼 보이는데, 몇 년 안으로 교통정리가 되지 않을까 싶다. 뭐, 그래 봤자 전부 그대로 표준이 될 듯하지만 말이다.

글꼴에 비트맵이라는 건 과거에 컴퓨터의 메모리가 부족하고 디스플레이의 해상도가 낮던 시절, 안티앨리어싱도 없던 시절에 동아시아 한글· 한자 같은 문자를 처리하기 위해서 존재하던 기술이었다. 허나 그게 쌩 컬러 이미지를 표현하기 위해 다시 쓰이게 됐다. 이제 다음으로는 간단한 애니메이션까지 취급하게 될지 궁금해진다.

맥OS는 별다른 조치 없이 일반적인 라벨 UI 컨트롤이나 텍스트 출력 함수만 쓰면 컬러 이모지가 잘 찍힌다. API가 바뀐 것 없이 기능만 자연스럽게 확장됐다.
그러나 레거시 호환성이 깡패급인 Windows는 그렇지 못하다. GDI, GDI+, Uniscribe 같은 레거시 기술로는 컬러 폰트를 출력할 길이 전~혀 없다. 컬러 폰트를 사용하려면 반드시 Direct2D 내지 그 휘하의 DirectWrite을 동원해야 하니 몹시 번거롭다. 거기서도 컬러 폰트를 사용하라는 옵션을 따로 준 뒤 출력해야 된다..!

이런 이유로 인해, 카톡도 PC Windows용 버전에서 대화창, 특히 입력란에서 컬러 이모지를 보기란 쉽지 않을 것 같다. 운영체제에서 대대적인 업데이트를 하지 않는 한 말이다. 브라우저도 Edge와 달리, IE에서는 컬러 이모지가 지원되지 않는다.

이모지는 인물(얼굴, 손가락), 동물, 음식, 사물, 운동, 여행, 심벌, 깃발 등의 카테고리로 나뉘는데, 이모지의 입력 기능은 그렇게 카테고리별 (1) 문자표 형태로 제공되는 편이다. 이건 워드 프로세서나 IME들이 신경 쓸 필요 없이 운영체제가 보편적으로 기본 제공해 주는 추세이다. 마치 필기 인식 기능과 비슷한 급이다.

이에 덧붙여 단어· 문장 단위의 composition이 발달한 중국어와 일본어 IME에서는 이모지가 (2) DB와 함께 통합되어 있기도 하다. 자기 나라 언어로 '사과'를 입력하면 사과 이모지, '자동차'를 입력하면 자동차 모양 이모지가 같이 뜬다. ^^;; :O 이런 건 당연히 그 표정에 해당하는 이모지로 치환해 주고 말이다.
한국어 IME는 composition이 글자 단위이고 자체 UI가 뜰 일이 없다 보니 이런 관행이 생소하겠지만.. PC가 아닌 모바일 환경에서는 저런 기능도 고려할 만하다.

그런데 이모지 문자표가 단순 유니코드 문자표와 다른 점은.. 그렇게 고유한 카테고리가 존재한다는 것 외에도, 2개 이상의 복합 코드 포인트가 결합된 놈이 무진장 많다는 것이다. 2글자에서 심지어 7글자까지 붙어서 한 개의 이모지가 되기도 한다.
뭐가 붙느냐 하면 주로 variation selector이다. 손가락 이모지 뒤에 이 손가락의 피부색을 결정하는 selector, 사람 얼굴 뒤에 사람의 성별을 결정하는 selector.. 이런 게 그냥 뒤따르는 것도 아니고 U+200D zero width joiner와 붙어 있다.

그러니 이모지는 글자의 컬러화뿐만 아니라 결합에도 옛한글에 준하거나 그 이상의 complex script 기술을 요구하는 셈이다. 채팅 앱에서나 존재할 법한 컬러 그림문자 처리 기능이 웹브라우저와 텍스트 에디터에서까지 볼 수 있게 된 것에는 이런 기술적인 변화가 있었던 것이다. 날개셋 한글 입력기에도 이번 최신 버전에서 이모지 문자표가 간단하게나마 추가됐지만.. 편집기가 애초에 컬러 폰트를 지원하지 않는 환경이기 때문에 거기서는 제대로 된 지원이 근본적으로 불가능하다.;;

3. Windows 기본 한글 글꼴의 변화

이모지 얘기가 좀 길어졌는데, 다음 주제로 넘어가면..
Windows 8인지 아니면 10의 특정 업데이트인지 정확하게 언제부터 이렇게 됐는지는 잘 모르겠다.
시스템 차원에서 기본 한글 fallback 글꼴이 구닥다리 '굴림/바탕' 대신 '맑은 고딕'으로 바뀌었다.
한글 글립이 존재하지 않는 Times, Arial, Verdana 같은 영문 전용 글꼴을 쓰는 상태에서 한글을 찍었을 때 맑은 고딕이 쓰인다는 뜻이다.

그리고 property sheet나 위저드 같은 UI들은 자기 내부에 나타나는 대화상자들에 대해 리소스 템플릿에 지정돼 있는 글꼴을 무시하고 무조건 굴림 9포인트로 지정하곤 했는데(이것을 소프트웨어적으로 따로 금지하지 않는 한..) 그 기본 글꼴도 맑은 고딕으로 바뀌었다.

일본어 글꼴을 베꼈네 하는 논란과 함께 15년을 넘게 존속해 온 오래된 글꼴을 좀 신선한 걸로 대체하려는 그 의도 자체는 인정한다. 그런데 맑은 고딕은 같은 크기일 때 통상적인 정사각형 기반의 글꼴보다 더 홀쭉하며, 내부 metric이 많이 다르다. 그렇기 때문에 같은 포인트에서는 다른 문자나 글꼴보다 작게 보인다.

그걸 무시하고 fallback 폰트를 바꿔 버리면 한글의 가독성은 안드로메다로 가 버린다. 안 그래도 알파벳보다 획이 더 많은데 상대적인 크기까지 더 작아져 버려서 알아보기 매우 어렵기 때문이다.;; 그나마 Times 같은 폰트는 알파벳도 워낙 조밀하고 작기 때문에 한글과 같이 크기를 나란히 키우기 용이하지만, 알파벳이 글자 단위로 납작하고 큼직큼직한 코딩용 불변폭 글꼴은 한글과 도저히 같이 쓸 수 없다.

사용자 삽입 이미지

위의 그림은 Windows 7에서 Lucida Sans Typewriter라는 불변폭 글꼴과 맑은 고딕으로.. 한글과 영문을 찍은 모습이다. 크기, 아니 정확히 높이는 위의 한 쌍은 20을, 아래의 한 쌍은 -20을 주었다. Windows의 LOGFONT 구조체는 높이를 음수로 지정하면 글자 자체의 높이만 그런 것으로 지정되고, 양수를 지정하면 상하의 자체 여백까지 감안한 높이가 그런 것으로 지정된다. 그렇기 때문에 아래의 쌍이 글자 크기가 더 크다.
어느 경우건 Lucida Sans Typewriter가 훨씬 더 납작하고 큼직해 보이며, 한글도 그에 상응하게 바탕체로 그것도 약간 납작하게 찍혔음을 알 수 있다.

사용자 삽입 이미지

그런데 Windows 10에서는..
Lucida Sans에서 fallback으로 쓰였을 때나, 순수 맑은 고딕을 지정했을 때나 한글의 폭이 하나도 다름없이 동일할 뿐만 아니라, 20을 줬든 -20을 줬든 그거 보정마저 없이 글자 크기가 동일하다! 그래서 같은 높이에서도 영문에 비해 한글은 터무니없이, 민망할 정도로 너무 작게 찍힌다. 이 문제를 좀 개선할 수 없으려나 모르겠다.

내 기억이 맞다면 기본 fallback 글꼴은 레지스트리를 통해 변경할 수 있다. 하지만 정확한 방법은 잘 모르겠다.
그나저나, 옛날 구식 글꼴인 굴림체 계열은 20을 주나 -20을 주나 크기에 아무 차이가 없다.

Posted by 사무엘

2019/11/25 08:36 2019/11/25 08:36
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1687

스텐실 폰트

* 굉장히 오랜만에 폰트 분야에 글을 하나 추가하게 됐다.

지금은 실생활에서 좀 보기가 힘들다만.. 30대 이상의 나이가 좀 있으신 분들 중에는 요런 투박한 모양의 글자 내지 숫자를 각종 표지판이나 벽면, 차량의 외부에서 본 적이 있을 것이다. 양각· 음각 형태로 새겨지거나 오려 붙여진 게 아니라, 물감· 페인트로 칠해진 형태로 말이다.

사용자 삽입 이미지

이 글꼴의 컨셉은 글자가 가독성을 해치지 않는 한도 내에서 획의 일부가 규칙적으로 끊어지고 단절돼 있다는 것이다. 특히 O 대신 ()이고, ㅁ 대신 [] 모양이다.

미술· 디자인 쪽으로 조예가 있는 분이라면 이미 다 눈치 채고 아시겠지만, 이건 '스텐실'이라고 불리는 인쇄 내지 칠하기 기법에 맞춰진 글꼴이다.
투명한 필름지 같은 것에다가 도안을 그려서 선이나 면을 잘라내고, 그걸 종이 위에다 올린다. 그 뒤 필름에다가 칠을 하면 필름이 없어서 종이가 노출된 영역에만 색이 칠해진다. 이 필름지를 이용하면 동일한 그림도 여러 번 쉽게 찍어낼 수 있다.

판화와는 접근 방식이 다르다. 판화는 개념적으로 도장과 비슷하며, 찍는 과정에서 좌우가 바뀐다. 하지만 스텐실은 칠하는 방식이 다르니 그런 mirroring이 발생하지 않는다. 판화와 달리 칠을 더 다채롭고 다이나믹하게 할 수 있다.
그러나 스텐실은 판화에는 해당사항이 없는 한계도 존재하는데, 내부의 구멍을 구조적으로 표현할 수 없다. 그렇기 때문에 내부의 구멍이 존재하는 글자는 부득이하게 획의 일부를 끊어서 구멍 내부도 외부와 연결되게 해야 한다.

기왕 획의 일부를 끊었으니 이걸 일관된 개성과 컨셉으로 삼아서 스텐실용 글꼴을 만들어 보자는 발상은 서체 디자이너들이 누구나 할 수 있었던 생각이다.
저 영문 Stencil 글꼴에서 보듯, 획 굵기의 기복이 있는 세리프 계열 글꼴이 단절감이 덜하고 좀 더 어울린다. 어차피 획이 최대한 가늘어지는 곳에다가 단절을 시키면 되기 때문이다.

하지만 산세리프 계열에도 스텐실 글꼴이 얼마든지 존재한다.

사용자 삽입 이미지사용자 삽입 이미지

디지털 글꼴이 없던 옛날에 이런 글자들은 스텐실 기법으로 만들어지고 복제된 도안들이라고 생각하면 된다.

사용자 삽입 이미지

버스의 경우, 동일한 노선을 달리는 버스가 수십 대 이상 있었을 테니 이렇게 행선지를 인쇄하는 게 합리적이었을 것이다.

사용자 삽입 이미지사용자 삽입 이미지

옛날에 군부대 근처에 있던 "접근금지", "위험" 표지판도 다 이런 식이었던 것 같다.
지금이야 옛날 같은 투박함과 엉성함은 사라지고 스텐실 컨셉을 일부러 흉내 낸 깔끔한 글꼴을 골라 쓰는 시대가 됐지만 말이다.

일반적인 책과 문서에서는 Times 같은 평범한 본문용 서체를 쓰는 반면,

  • 타자기나 코딩용으로는 딱딱한 불변폭 서체를 쓰고,
  • 기계가 인식하기 편하라고 타자기와 비슷하면서 획을 간소화시킨 그 특유의 OCR용 서체도 만들고,
  • 멋을 내기 위해서는 기울이고 날리고 최대한 한붓그리기를 추구한 필기용 서체를 쓰고,
  • 열악한 디지털 기계에서는 8픽셀도 채 안 되는 높이 내지 7-segment 같은 극도로 단순한 형태로 문자 외형을 간소화도 하고,
  • 스텐실용으로는 이렇게 구멍이 없는 서체를 쓰는 등..
문자를 용도에 따라 다채롭게 활용 가능하게 하는 것이 타이포그래피의 묘미임이 틀림없다.

그나저나 오늘날 같은 디지털 인쇄와 복사 기술이 발달하기 전에 등사처럼 아날로그 판화· 인쇄술이 어떠했는지에 대한 의문과 관심이 문득 생긴다.

Posted by 사무엘

2019/03/26 08:36 2019/03/26 08:36
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1601

본인은 우리나라 근현대사와 한글 기계화에 모두 관심이 지대한 사람으로서,
6· 25 휴전(정전?) 협정 문서라는 엄청난 역사적인 문서가 '공 병우 세벌식 타자기'로 작성되었다는 사실에 입이 떡 벌어지며 그야말로 엄청난 전율과 감격을 느낀다.

사용자 삽입 이미지

이것은 한글이 역사상 거의 최초로 기계화가 된 결과물이다. 이 사진을 내 블로그에다가도 소개해 놓을 생각을 왜 지금까지 안 하고 있었나 모르겠다.
후대에 등장한 병신 같은 받침 키 두벌식 타자기가 아니라, 지금의 컴퓨터와 거의 동일한 방식으로 입력 가능한 타자기가 그것도 6· 25 전쟁도 터지기 전의 그 혼란스러운 시기에 핵심 아이디어가 완성되고 제품이 나왔다는 건 참으로 경이로운 일이 아닐 수 없다. 이게 다 넘사벽급의 천재 선각자 공 병우 박사 덕분이다.

저 타자기 자형은 훈민정음 해례본의 인쇄 글씨체만큼이나, 또 8*4*4 도깨비 조합형 비트맵 글꼴만큼이나 한글의 역사에서 빠질 수 없는 중요한 획을 그은 자형이다. 다시 말하지만 저건 197, 80년대도 아니고 1953년에 작성된 문서이다.

비슷한 시기이던 전쟁 중에 살포된 삐라들을 살펴보면 본인은 진작부터 유의미한 차이를 발견할 수 있었다.
삐라 중에는 단순히 적군 디스 흑색선전이나 프로파간다를 담고 있는 찌라시 말고, 뭔가 유엔군 사령관의 싸인이 있고 언어도 한중영 3개로 기재된 '안전 보장 증명서' 같은 것도 있었다. "이 증서를 들고 귀순하면 귀관들은 영예로운 전쟁 포로로서 안전을 절대적으로 보장받을 것이다" 이런 내용이 담겨 있었다. 아래 삐라는 그 중 한 예이다.

사용자 삽입 이미지

그런데... 이 증서를 보면, 한국어와 중국어는 날림 손글씨 붓글씨이지만 영어만은 꼬부랑 필기체가 아니라 또박또박 타자기 글씨였다. 삐라 하나를 봐도 그 시절에 문자의 기계화 수준은 동서양이 격차가 벌어져 있었다는 게 느껴졌다.
전에도 얘기한 적이 있지만, 서양에서 나치를 반대하던 백장미단은 그래도 삐라를 타자기를 쳐서 만들었지만, 반도에서 항일 전단지를 만들던 독립 운동가들은 여전히 붓글씨를 쓰지 않았던가?

그랬는데 동북아의 어느 좁아 터진 듣보잡 전쟁 폐허 국가에서.. 영어나 알파벳을 공식적으로 쓰지도 않는 주제에 자국 문자를 빠르게 찍어 내는 기계식 타자기가 짠 나타났으니 이건 깜짝 놀라 까무러칠 노릇이 아닐 수 없었다.
군대는 타자기의 편리함을 인지하고서 이미 1950년대부터 "유능한 장교라면 영어, 운전, 타자에 능숙해야 한다" 같은 지침이 나돌았다고 한다. 그러나 사회 전반에는 문자의 기계화와 속도 향상, 시간 절약의 필요성 자체를 인지하지 못하던 미개한 분위기가 오랫동안 유지되었다.

모바일은 아무래도 두벌이니 세벌이니 하는 이념과는 거리가 멀며, 애초에 크기도 너무 작다 보니 타자기의 직계 후손이라 할 수 있는 컴퓨터 글자판만치 빠르게 글자를 입력하기는 어렵다. 하지만 언제 어디서나 다룰 수 있다는 점, 그리고 모바일에서는 대개 채팅이나 자기 자아 표현 같은 가벼운 글만 주로 입력한다는 점 때문에 컴퓨터 글자판과는 용도가 양분되어 있다. 헬리콥터가 수직 이착륙과 공중 체류가 가능하다는 점 때문에 고정익기와는 별도의 영역이 있는 것과 비슷한 양상이다.

팥알 님의 블로그에는 이미 진작부터 한글 타자기를 세대별로 전문적으로 연구해 놓은 자료가 한가득이므로 관심 있는 분은 참조하시기 바란다. 저 자료에 비하면 내 블로그의 이 글은 한참 늦은 뒷북에 지나지 않는다.
그럼 휴전 협정 자체에 대한 사항만 몇 가지 언급하며 글을 맺겠다.

  • 1953년 7월 27일이 6· 25 전쟁이 끝나고 한반도의 군사분계선 일대에서 총성이 완전히 멎은 날인데, 정확하게는 저 문서에 나와 있듯이 아침 10시경에 공식 문서가 작성되어 그로부터 12시간 뒤, 일과가 다 끝난 밤 10시부터 효력이 발휘되기 시작한 것으로 보인다.
  • 휴전 협정이 벌어지고 저 문서가 작성된 장소는 오늘날의 그 판문점이 아니다. 옛날 오리지널 판문점은 지금 판문점보다 서쪽으로 1km쯤 더 떨어진 곳에 있었고 지금은 완전히 북한 땅이다. 그 건물 자체는 현재까지도 남아 있다.
  • 저 문서에 서명을 한 사람은 북한, 중국, 미국 대표밖에 없다. 그 당시 남한 측 대표는 알다시피 강경한 북진멸공덕후였던 관계로 휴전 따위에 결코 동의하지 않았기 때문이다.
"휴전 협정은 전쟁을 줄이는 것이 아니라 더 큰 전쟁의 준비 행위이고 더 많은 고난과 파괴를 의미하며, 전쟁과 내란에 의한 공산당의 더 많은 침략 행위의 서막이 된다는 나의 확신 때문에 나는 휴전 협정 서명에 반대하였습니다. 이제 휴전이 서명된 이 마당에 나는 그 결과에 대한 나의 판단이 틀렸던 것으로 나타나기만 기원할 뿐입니다.
그러나 북녘의 동포 여러분, 희망을 버리지 마십시오. 우리는 여러분을 결코 잊거나 외면하지 않을 것이고 반드시 여러분을 구출할 것입니다." (1953년 7월 29일자 민주신보, 그 당시 이 승만 대통령의 담화문 윤문 각색)


이 와중에 이 승만 대통령이 무슨 전쟁광 싸이코패스여서 휴전을 반대한 거라고 생각하는 바보 멍청이는 없을 것이다. 그는 “아.. 지금 이렇게 어정쩡하게 휴전을 해 버려서는 안 되는데.. 지금 악을 완전히 뿌리뽑지 않고 미뤘다가는 우린 북괴 빨갱이들의 도발 때문에 앞으로 계속 고생하게 될 것이고 더 큰 희생을 대가로 치르게 될 텐데.. 그래도 우리나라가 힘이 없어서 휴전이 되돌릴 수 없는 대세가 되어 버렸다면 차라리 내 예상이 틀리기를 바랄 뿐입니다.” 이런 차원에서 담화를 발표한 것이었다. (그리고 그 예상은 불행히도 정확하게 적중함)

그는 북괴는 악의 무리이며, 북괴 치하에 있는 동포들은 오늘로 치면 ISIL 같은 곳에 납치· 억류 당해 있는 불쌍한 구출 대상이고 자유와 해방을 선사해야 할 대상이라고 지극히 건전하고 바른 인식을 하고 있었다. 테이큰의 브라이언, 아저씨의 차 태식처럼 말이다. 지금 같이 악의 무리들과 무슨 교류와 협력, 불의한 평화 따위 구걸하는 태도는 전혀 찾을 수 없었다.

Posted by 사무엘

2017/08/20 08:30 2017/08/20 08:30
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/1395

HONDA와 SONY의 로고타입

'혼다'랑 '쏘니'.
1946년에 설립된 일본의 기업이라는 공통점이 있으나, 전문 분야는 다르다. 혼다는 자동차· 오토바이 등 엔진 달린 탈것 전문이고 쏘니는 전자 쪽 전문이다. 우리나라로 치면 마치 현대 자동차와 삼성 전자처럼. 종전 후에 설립되었기 때문에 미쓰비시 같은 기업과는 달리 전범 논란이 없다.

혼다와 쏘니는 둘 다 납작한 로만체 계열의 서체로 로고타입을 표현한다.
그래서 혹시 "완전히 동일한 서체인가?"란 의문을 품고 로고타입을 자세히 살펴봤다.

사용자 삽입 이미지

그런데 동일하지는 않다. N자 모양을 보면 차이가 명백하다. 단순한 폭이나 진하기 같은 산술적인 차이가 아니다.
혼다가 글자 모양에 변화를 더 줬다고 볼 수 있다. 보통은 N에서 대각선 획이 오른쪽 수직선에 완전히 붙지 혼다의 것처럼 아래에 독자적으로 닿지는 않기 때문이다.

이들의 서체는 운영체제에서 흔히 보는 서체들 중에서는 Bookman Old Style과 비슷하다. Bookman도 Times 같은 다른 서체들에 비해서는 꽤 납작한 편이지만, 로고타입은 그것보다 더욱 납작하다.
이것 말고 또 서체가 유사한 기업 로고타입의 쌍이 무엇이 있는가 궁금해진다. 아주 오랜만에 글꼴 관련 짤막한 기록을 하나 남겼다.

Posted by 사무엘

2016/10/06 08:30 2016/10/06 08:30
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1280

이탤릭체 이야기

라틴 알파벳에는 다른 문자와는 달리 이탤릭이라고 약간 기울이고 흘려서 쓴 변형 서체 유형이 있다. 획을 진하게 하는 '볼드'와 더불어, 산술적인 변형뿐만 아니라 아예 별도의 폰트를 만들어서 제공 가능한 글자 속성 중 하나이다.

옛날에 비트맵 글꼴 시절에는 윗첨자· 아래첨자와 더불어 이탤릭은 아예 별도의 글꼴(폰트 패밀리)로 제공되는 게 보통이었다. 그러나 출력 장치의 해상도가 올라가고 결정적으로 윤곽선 글꼴 기술 덕분에 글자의 크기 제약이 없어지면서 이탤릭과 윗첨자· 아래첨자는 모두 아무 글꼴에나 추가로 적용 가능한 '변형 속성'으로 바뀐 지 오래다.

우리는 지금까지 이탤릭을 아마 수학식에서 가장 자연스럽게 보고 써 왔을 것이다. 수학에서 일종의 '예약어'라 할 수 있는 sin, lim, log 같은 단어은 반드시 regular 정자체로 쓰고, 나머지 임의의 변수명은 이탤릭으로 썼으니 말이다. 단, 소문자 이탤릭을 너무 흘려서 쓰면 그리스 문자와 구분이 어려워지기도 하므로 주의가 필요하다. 예를 들어 a와 알파, n과 η, x와 χ 같은 것.

개인적으로 20여 년 전, 아래아한글 2.1이던가 2.5에서 처음 도입된 수식체를 아주 좋아했다. regular 모양은 신명조와 별 다를 바 없지만 이탤릭이 굉장히 미려했기 때문이다. 실제로 각종 수학 교재나 상업용 출판물에서 쓰인 서체이기도 했다.
지금 아래아한글은 수식의 서체가 뭔가 LaTex스러운 서체로 바뀌었고 마소 제품의 경우 한때는 그냥 타임즈이다가 지금은 다른 걸로 바뀌었는데... 난 아래아한글의 원조 수식체가 지금도 그립다.

사용자 삽입 이미지

한편, 킹 제임스 성경 신자라면 원문에 없는 단어를 뜻하는 이탤릭체 표기가 아주 친숙할 것이다. (사실은 옛날 한글 개역 성경에도 본문보다 "약간 작게 쓴 글자"가 있어서 개념적으로 동일한 역할을 하긴 했다.)

이탤릭 서체는 세로 중심선이 사선 모양으로 기울어질 뿐만 아니라, 세리프 계열의 경우 세로획의 위· 아래 끝 부분이 살짝 둥글게 삐친 형태로 바뀐다.
이탤릭 전용 서체가 없는 글꼴은 응용 프로그램이 글자 모양을 그냥 수학적인 일차 변환으로 기울여서 찍어 준다. 이것은 엄밀히 말하면 (1) Oblique라고 불리는 다른 모양일 뿐 이탤릭이 아니다.

산세리프 계열에 속하는 서체들은 딱히 이탤릭이나 오블리크나 모양 차이가 별로 없어서 굳이 이탤릭 전용 서체가 필요한가 하는 의문이 들기도 한다. 뭐, 두 글자의 모양을 한데 포개서 차이를 비교해 봐도 되겠지만. 또한 알파벳 말고 숫자 역시 Times 같은 세리프 계열 서체를 봐도 그냥 그대로 기울인 오블리크와 별 차이가 없어 보인다. 숫자는 딱히 italic-ready 문자는 아닌 듯하다.

이탤릭은 정자체보다야 날려 쓴 듯한 느낌을 주지만, 모든 글자들이 한 획으로 완전히 이어진 (2) 필기체를 표방하는 것도 아니다. 가령, 소문자 i나 l의 이탤릭은 세로선이 기울어지고 위와 아래에 동그란 삐침까지만 있지, 필기체처럼 두 선이 한 점에서 만나는 획이 생긴다거나 하지는 않는다.
Brush Script 같은 필기체 계열의 서체들은 정자체 모양이 태생적으로 이미 좀 기울어진 형태이기 때문에 또 이탤릭을 적용하는 것은 무의미하다.

끝으로, 세로 중심선은 90도 수직선인데 이탤릭체에 적용되는 삐침만 적용한 (3) upright italic이라는 것도 타이포그래피 용어로는 있는 모양이다. 실용적인 의미나 가치가 무엇이 있는지는 잘 모르겠고 그냥 이런 게 있다는 것 정도이다.

이탤릭체는 글자의 수직 높이는 변함없는데 중심선이 약간 기울어짐으로써 실질적으로 글자의 크기가 약간 더 커지는 효과를 낸다.
그런데 여기서 궁금한 게 있다. 이탤릭체는 중심선을 정확하게 몇 도 기울이는 것이 정석일까? 여기에 통일된 규격이 있긴 할까?

MS Word의 경우, 이탤릭체가 적용된 글자로 마우스 포인터를 가져가면 신기하게도 포인터의 I자 모양도 이탤릭체 모양으로 기울어진 모양으로 바뀐다. 그리고 cursor(캐럿) 역시 단순 수직선이 아니라 기울어진 사각형 모양으로 바뀐다. 사선 모양이 굉장히 엉성하고 못생기긴 했지만 말이다.

화면 캡처를 해서 들여다보면, Arial, Verdana처럼 이탤릭 전용 서체가 있는 글꼴들은 세로선의 기울기가 5인 듯하다. 즉, 오른쪽으로 1픽셀 움직이는 동안 세로로는 대략 5픽셀이 움직인다. 이것은 각도로 환산하면 약 78.7도(수직선이 90도)이며, 따라서 11~12도 정도 기울이는 셈이 된다. 기울어진 cursor의 기울기도 이것과 얼추 일치한다.

한편, 이탤릭체 모양의 마우스 포인터는 화면을 확대해서 자세히 들여다보면 기울기가 4이다(약 76도).
흥미로운 것은 전용 서체가 없이 프로그램이 기본으로 구현하는 이탤릭이다. 얘는 기울기가 거의 3(약 71.5도)에 가까워서 누운 정도가 위의 글자들보다 더 과격하다. 따로 새로 만들어진 획이 없이 전적으로 산술적인 변형만으로 기울어짐을 구현하는 것이기 때문에 더 기울여 준 건지는 모르겠다. 아무튼 내부적으로 이런 차이가 있다는 것도 알면 흥미로울 것이다.

지금까지 설명한 모든 개념들의 예를 그림으로 정리하면 다음과 같다. Arial은 bold에 대해서도 전용 이탤릭 서체가 있는 반면, Arial Black은 전용 서체 없이 산술 연산으로 오블리크가 이탤릭의 역할까지 하고 있으며 기울기가 더 과격하다는 걸 알 수 있다.

사용자 삽입 이미지

Posted by 사무엘

2015/07/16 08:44 2015/07/16 08:44
,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1116

여러가지 글꼴 생각

1.
요즘 대세가 복고풍 타이포그래피인지? 옛날목욕탕체, 배달한나체가 정말 인기 많다. 영화 국제시장도 그 성격상 복고풍 서체로 포스터가 만들어졌다.
옛날에는 복고풍 서체라 하면 정말로 궁서체와 휴먼옛체 정도밖에 선택의 여지가 없었는데 이런 분야에도 다양한 서체가 존재한다는 건 그만큼 우리나라가 문화적으로 풍족해졌음을 의미한다. 게다가 라틴 알파벳과는 달리, 한글 서체는 주 사용 인구가 1억도 채 안 되는 내수 시장에서밖에 수요가 없는데도 말이다.

한글에 대해서 옛날 스타일 서체를 꾸준히 고집하고 있는 곳이 최소한 두 곳 떠오르는데
하나는 철없는 전직 부사장이 저지른 땅콩 회항 사건 때문에 이미지를 제대로 구겼던 대한항공이고, 그리고 다른 하나는 육사 부대 마크이다.

사용자 삽입 이미지

비행기 동체의 윗부분에 큼직하게 KOREAN AIR라고 써 놓은 거 말고, 앞부분 아래에 자그맣게 '대한항공'이라고 쓴 부분이 내게는 오래 전부터 인상깊게 와 닿았다. 저 한글 로고그래피는 대한항공이 지금과 같은 치약 하늘색 도색과 영문 CI를 도입하기 전부터 계속 써 오던 물건이다.

육사 부대 마크는 무려 1947년부터 써 오던 것이니 보수적인 군대에서 앞으로도 당연히 계속 쓸 테고.
대한항공이든 육사든, 한번 정한 서체는 자기 정체성을 걸고 안 바꾸고 계속 썼으면 좋겠다.
개인적으로는 서울 지하철 초롱테크 지하철체.. 시각적으로 아무 문제 없는데 무단으로 뜯어고치고 바꾸는 거 마음에 안 든다.
그나저나 옛날 철도 간이역 역명판 서체들도 디지털로 복원하고 싶다. 자료를 많이 모아야 할 텐데.

2.
요건 출근길 지하철 안에서 본 광고판이다.
이 정도면 복고풍 서체가 아니라 혹시 북한 서체이지 않나 싶어서 원전을 찾아보니..
ㅇ의 모양, 그리고 '교'의 모양이 북한 서체를 아슬아슬하게 비껴 가긴 한다.
하지만 첫인상이 여전히 서로 굉장히 닮아 보인다.

사용자 삽입 이미지

3.
베트남은 언어는 중국어와 비슷하게 성조도 있고 1음절 1형태소 1글자 고립어 형태인 것 같은데 그럼에도 불구하고 문자는 프랑스 선교사의 주도로 개혁을 해서 한자를 완전히 없애 버리고 라틴 알파벳을 쓴다. 그래서 분위기가 이색적이었다.
단, 성조를 표기하려고 알파벳의 위· 아래에 이상한 부호들이 많이 달려 있다.

그리고 베트남이 자체적으로 서체를 만들 만한 나라는 아니니, 간판들을 보면 다들 MS Word 95나 아래아한글 96처럼 10년, 20여 년 전부터 기본으로 내장돼 있던 듯한 1990년대 기성 서체들 위주이다.
Cooper Black을 정말 많이 봤고, 그 외에 Copperplate Gothic, Impact, Matura MT Script도 있었다.
그 글꼴이 처음 만들어지던 시절에는 굉장히 참신한 디자인이긴 했지만, 이것도 익숙해지니까 식상하다.

사용자 삽입 이미지

그건 그렇고, 이건 뭘까?

사용자 삽입 이미지

대문자 A의 외곽 획이 활처럼 둥글게 휜 윗줄의 서체도 많이 쓰이는 편이었는데 개인적으로는 좀 낯설다. 그 반면 아랫줄 서체는 우리에게도 비교적 친숙할 것이다.
바로 한미디어에서 개발하고 MBC가 2000년대 초까지 자사 CI에다 썼던 문화방송체이기 때문이다.
저 사람들이 설마 한국산 서체를 썼을 리는 없으니 저것도 영문 원도가 따로 있는가 보다. 알고 보니 원조는 Banco라는 별도의 서체라고 한다.

4.
본인은 직접 써 본 경험은 전무하지만, 클래식 맥 OS에 대해 어느 정도 동경을 하고 있다. 특히 쟤네들의 기본 서체가 참 개성 있다고 생각해 왔다. 아래 그림에서 File, Edit 같은 메뉴, 그리고 System Tools/Folder를 표현하는 서체 말이다. 맥 OS의 Windows System 같은 서체나 마찬가지이다.

사용자 삽입 이미지

이 맥 OS의 서체 이름은 Chicago이다. Windows 95의 코드명인 그 시카고. 나중에는 비트맵뿐만이 아니라 윤곽선 글꼴로도 만들어졌다. 특히 V와 w 같은 글자의 모양을 보노라면 비트맵과 윤곽선 글꼴이 싱크가 잘 맞는 것 같다.

사용자 삽입 이미지

그러고 보니 타이포그래피와 디자인을 좋아하고 컴퓨터를 하드/소프트 독점 일체형으로 만들었던 애플에서는 OS가 이름이 없이 그냥 System이고 애플 전속 서체는 이름이 있었던 반면, 처음부터 소프트웨어에 초점을 뒀던 마소의 Windows는 프로그램이 이름이 있고 서체는 딱히 이름이 없이 그냥 System이다. 아주 재미있는 차이가 아닐 수 없다.

Windows쪽 얘기를 좀 하자면, 1과 2 시절에는 시스템 기본 글꼴이 고정폭이었다. 그러다가 3.0때부터 오늘날과 같은 가변폭 System이 도입되고 예전의 글꼴은 그 유명한 Fixedsys라는 이름으로 개명당했다. 모노크롬 시절에는 byte align이 힘들어서 성능 오버헤드가 더 크기도 했을 텐데 맥은 처음부터 과감하게 1.0때부터 가변폭 글꼴을 채용했다.

Fixedsys는 Windows 1.0 시절에 비트스트림이라는 유명한 서체 회사에 외주를 줘서 개발한 것인 반면, 오늘날의 가변폭 시스템은 마소에서 자기네 정체성을 담아 자체 개발한 글꼴이다. 그러니 System을 그 모양 그대로 윤곽선화해서 이름을 붙일 법도 했을 텐데 마치 현대 자동차에서 포니, 엑셀, 스텔라 같은 이름에 애착이 없는 것만큼이나 마소에서는 그 옛날 글꼴에는 더 애착을 갖고 있지 않은 듯하다.

이미 구닥다리의 상징에, 시스템 리소스가 다 떨어졌을 때에나 나오는 fallback 이미지가 너무 굳어져서인 듯. 게다가 NT 계열 부터는 리소스 제약도 없어져서 더 볼 일이 없어졌다. -_-;; 동아시아 Windows에서 이상하게 MS Sans Serif 대신 System을 쓰던 구닥다리 Visual C++ 6.0 IDE가 마지막이다.

System, Fixedsys 같은 건 트루타입 글꼴이 개발되기 전부터 도입됐기 때문에 당연히 TTF 형태가 아니다. 그래도 운영체제에 완전히 하드코딩으로 박힌 물건은 아니고, 오늘날도 Windows\Fonts 디렉터리에서 vgasys.fon, vgafix.fon이라고 실물 파일을 확인할 수 있다. 1980년대까지는 '장치 독립적인 글꼴'이라는 개념이 없었기 때문에 신기하게도 글꼴 이름이 저런 형태이다. 맥은 그 시절에 어떠했나 모르겠다.

뭐 그런 것과는 별개로, 본인은 한글 전산화의 역사와 추억이 깃든 과거의 16*16 비트맵 조합형 글꼴들도 윤곽선 글꼴로 리메이크가 많이 됐으면 좋겠다. 이야기체나 둥근모 같은 것들. 가장자리를 동그랗게 혹은 적절한 곡선으로 복원해 주면 이런 것이야말로 진정한 복고풍 서체의 위업을 달성할 수 있지 않겠나 싶다.

Posted by 사무엘

2015/05/10 08:27 2015/05/10 08:27
Response
No Trackback , 4 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1091

요즘 운영체제들에 GUI 셸이 없는 물건은 없고, GUI에는 그림보다도 먼저 문자를 찍는 기능이 반드시 필요하다. 옛날에는 그런 출력 기능이 겨우 비트맵 글꼴밖에 지원되지 않았지만, 오늘날은 트루타입(TTF)이라고 불리는 규격의 윤곽선 글꼴이 세계를 평정한 지 오래다(오픈타입은 TTF의 superset에 해당함). 심지어 재래식 비트맵 글꼴이 필요하다 해도 일단 TTF 방식으로 저장하고서 출력한다.

게임처럼 완전 독자적인 GUI 노선을 가는 프로그램이 아닌 이상, 거의 모든 응용 프로그램들은 운영체제가 제공하고 운영체제에 기본으로 설정되어 있는 글꼴만을 사용하여 글자를 출력한다. 새로운 글꼴을 받아서 설치하는 건 사용자의 몫이다. 그러나 가끔은 응용 프로그램이 직접 글꼴을 설치해서 써야 하는 경우도 있다.

워드 프로세서 같은 오피스 프로그램이라면 운영체제 전체에 새로운 글꼴을 번들로 제공할 수 있다. 이건 global한 글꼴 추가이다. 한편, 자기 프로그램 내부에서만 특수한 custom 글꼴을 추가해서 쓰는 건 local (private)한 글꼴 추가이다.

윤곽선 글꼴 출력 엔진은 힌팅과 캐싱 기능이 곁들여진 일종의 고성능 범용 단색 벡터 그래픽 엔진이다. 그렇기 때문에 다른 프로그램들에 노출되지 않는 local 글꼴도 용도가 매우 다양하다. 수식이나 악보에서 쓰이는 비문자 기호를 찍는 건 물론이고, ‘입꼴 워드’처럼 자기만 사용하는 특수한 문자를 찍을 때도 전용 글꼴을 활용하면 된다.

당장 운영체제 자신도 이걸 잘 활용하고 있다. 테마가 도입되기 전에 Windows 창에 달린 사각형 모양의 최소화(_)/최대화/닫기(X) 그림은 글꼴 출력이고, Visual Studio 같은 데서 창을 도킹시키는 주사기/핀 모양의 그림도 글꼴이다. 아마 본인이 옛날에 블로그 글에서 언급한 적이 있을 것이다.

Windows 8은 부팅 시나 작업 중일 때 다섯 개의 구슬이 동그란 궤도를 그리면서 슝슝 돌아가는 애니메이션이 출력되는데, 이것도 애니메이션 GIF나 플래시 같은 기술이 아니라 글꼴 출력이다~! 구슬이 싹 들어갔다가 나오기도 하는 게 은근히 복잡하며, 이 애니메이션은 무려 100수십 프레임에 달한다. 유니코드 PUA 영역에다 미리 계산된 각 프레임의 모양을 그려 넣은 뒤, 그 글자를 순서대로 찍은 것이다. 놀랍지 않은가?

보급이 아닌 싸제 글꼴의 등록 및 해제를 위해 Windows는 AddFontResource와 RemoveFontResource라는 간단한 함수를 제공한다. 인자로는 등록하거나 해제하고 싶은 글꼴 파일의 경로만 달랑 주면 된다. '일단은' 말이다. 그러다 나중에는--Windows 9x 라인 말고 2000에서부터-- 두 종류의 함수가 더 추가되었다.

첫째, 바로 저 두 함수의 이름 끝에다 Ex가 붙은 버전이다. Ex 버전은 인자를 두 개 더 받는데, 하나는 아직 reserved 상태니 별 의미가 없고, 다른 하나는 사소한 비트 플래그들이다. 등록하는 이 글꼴을 시스템 전체가 아니라 우리 프로세스 내부에서만 사용하게 하는 FR_PRIVATE 옵션, 그리고 글꼴의 접근 가능 여부를 떠나서 일단 이게 EnumFontFamilies(Ex)에서 집계가 되지 않게 하는 FR_NOT_ENUM 옵션이다. 즉, 이 글꼴의 독특한 이름을 아는 프로그램만 이 글꼴을 사용할 수 있게 되는 것이다.

그리고 둘째로, 글꼴을 파일 이름이 아니라 아예 메모리 상의 데이터로 받는 AddFontMemResourceEx도 추가되었다. 이 함수로 추가되는 글꼴은 파일로 실체가 존재하지도 않고 특정 프로세스의 주소 공간에 매여 있으므로 극도로 private하며, FR_PRIVATE|FR_NOT_ENUM 속성이 언제나 선택의 여지 없이 붙는다.

요컨대 글꼴을 좀 더 가볍게 private 형태로 추가하는 기능은 Windows 2000에 와서야 새로 도입된 셈이다. 여담이지만, 이것 말고도 Windows 2000은 9x/NT4 시절에 비해 프로그램의 국제화 수준이 크게 강화된 첫 버전인지라 다국어 IME와 complex script를 포함해 글꼴을 저수준에서 조작하는 API들도 크게 추가되었다.
트루타입 글꼴의 테이블 데이터를 있는 그대로 뽑아 내는 GetFontData라든가, 글꼴이 지원하는 문자 집합을 유니코드 번호로 얻어 오는 GetFontUnicodeRanges도 이때의 산물임.

뭐 그건 그렇고 다시 글꼴 등록 얘기로 돌아오자면..
local/private 말고 전통적인 global한 글꼴 추가도 여전히 필요한 절차이다.
그런데 문제는 이게 사실 함수 호출만 한다고 완전히 끝나는 게 아니라는 것이다. 절차가 생각보다 굉장히 지저분하며 문서화가 제대로 돼 있지 않다.

1. global 글꼴은 Windows\Fonts 디렉터리에 있어야 한다. 결국 파일을 복사해 넣어야 하는데, 이 디렉터리에 read가 아닌 write를 하려면 관리자 권한이 필요하다.

2. Fonts 디렉터리에 복사된 파일을 상대로 AddFontResource(Ex) 함수를 호출한다.

3. 이 글꼴이 다음 부팅 때에도 제대로 인식되게 하려면, 글꼴 리스트를 레지스트리에다가도 등록해 줘야 한다. 위치는 다음과 같다.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts
과거 9x 시절에는 Windows NT 대신 그냥 Windows이고. 저 레지스트리도 read가 아닌 write를 하려면 관리자 권한이 필요하다.


레지스트리에 등록하는 형식은 대충 보면 짐작할 수 있지만, 문제는 이 뻔한 패턴의 작업을 자동으로 대행해 주는 함수가 없다는 것이다. 등록하고자 하는 TTF 파일을 직접 파싱해서 name 테이블에 있는 이름을 얻어 와야 하나? ActiveX 컨트롤을 등록해 주는 regsvr32 유틸리티처럼 글꼴을 명령 프롬프트에서 바로 설치하거나 제거하는 유틸리티도 운영체제에 있어야 할 것 같다.

옛날에는 트루타입 글꼴을 설치하려면 CreateScalableFontResource 같은 이상한 함수도 호출해서 ttf에 대응하는 *.fot 파일이라는 걸 만들어야 했던 모양이다. 완전 불편하기 그지없는데 지금은 그럴 필요까지는 없는 듯. 20년 전 엄청 옛날의 Windows 3.1 시절에는 ttf/fot 파일 쌍이 필요했지만 95 이후로는 그런 건 없다.

반대로 이 글꼴을 제거하려면 먼저 RemoveFontResource(Ex)를 호출해 주고, 이게 성공하면 레지스트리 제거와 파일 제거를 수행하면 된다.
그런데 Windows는 파일 자체를 가상 메모리 주소 공간에다 직통으로 대응해서 쓰는(MMF) 걸 좋아하는 운영체제인지라, 시스템 공용 파일을 지우기가 더럽게 까다로운 운영체제다. 글꼴도 예외가 아니어서 파일 삭제는 access deny 에러가 뜨면서 잘 되지 않을 수도 있다. 이때는 MoveFileEx(file, NULL, MOVEFILE_DELAY_UNTIL_REBOOT)을 줘서 다음 재부팅 때라도 파일이 삭제되게 플래그를 주면 될 것이다.

local과는 달리 global 글꼴 등록과 삭제는 이렇게 번거로운데, 게다가 관리자 권한까지 필요하니 더욱 번거롭다.
관리자 권한은 한 프로세스가 필요한 때만 잠시 사용자의 동의 하에 취득했다가 반납하는 게 없다. 애초에 자기 프로그램을 더 높은 권한으로 재실행해야 한다.
잠시 다음 상황을 생각해 보자.

  •  어떤 일을 하는 동안에도 GUI는 매끄럽게 반응하고, 작업이 취소 가능하거나 진행 상황 같은 걸 별도로 표시해야 하는 경우: 작업 부분을 별도의 스레드로 떼어 내야 한다.
  • 다른 프로세스를 훅킹해서 정보를 얻어 오거나 실행을 조작해야 하는 경우: 훅 프로시저는 반드시 별도의 DLL로 만들어야 한다. DLL은 32비트와 64비트를 모두 신경 써서 만들어야 하니 더욱 번거롭다.

그리고,

  • 평소에는 일반 모드로 실행되지만, 잠시 관리자 권한을 얻어 와서 민감한 디렉터리나 레지스트리의 내용을 변경해야 하는 경우: 그 부분만 별도의 EXE(프로세스)로 만들어서 실행해야 한다. 물론 나 자신을 특수한 인자를 주고 재실행하는 것도 괜찮다.

참고로 권한이 낮은 프로그램은 권한이 높은 프로그램에다 메시지를 못 보낸다. 그러니 프로그램 간의 통신 메커니즘도 잘 생각해 봐야 한다. =_=;;

어지간하면 골치아플 일 없이 단일 모듈, 단일 스레드만으로 모든 일을 처리하고 싶은데 그럴 수가 없는 상황이 이렇게 요약되었다.
프로세스, 스레드, DLL이 시나리오별로 다 등장했다. 글꼴 설치는 '프로세스' 분리가 필요한 작업인 것이다.

Posted by 사무엘

2014/05/26 08:23 2014/05/26 08:23
, , ,
Response
No Trackback , 3 Comments
RSS :
http://moogi.new21.org/tc/rss/response/967

내 손글씨

내 손글씨는...

사용자 삽입 이미지

영문은 기본적으로 Times Roman을 표방하며 특히 숫자는 이를 더욱 엄격히 따른다. 소문자 a와 g도 언제나 Times 스타일의 정자체로 쓴다.
하지만 세부적인 획은 기분에 따라 Courier 또는 Century Gothic 스타일로 쓰기도 한다.

소문자 i, t, l 같은 글자를 보면 차이가 가장 크게 드러나는데..

  • Times 스타일은 세로획의 위쪽에 자그마한 / 모양의 삐침이 있고 글자가 대체로 홀쭉하다.
  • Courier 스타일은 세로획의 위쪽에 비교적 길게 - 모양의 삐침이 있고, 글자들의 폭이 대체로 균일하고 뚱뚱하다.
  • Century Gothic 스타일은 삐침이 전혀 없어서 t조차도 가로획과 세로획만 있다.

이 세 계열 중 어느 스타일을 따를지는 기분에 따라 달라지는 듯. 딱 하나로 떨어지지는 않는다.

한편, 한글은 바탕체를 표방하며 네모꼴 스타일과 샘물/세벌/빨랫줄 스타일 두 개가 존재한다.
내 손글씨를 정형화해서 디지털 서체로 만들고 싶은 소박한 바람이 있다.

한글은 라틴 알파벳보다 획이 (1) 더 많고 복잡하다. (따라서 한 글자를 표현하는 데 알파벳보다 일반적으로 더 많은 픽셀수가 필요하다.)
그리고 그렇게 복잡하긴 한데 (2) 개개의 획은 기하학적으로 더 단순하다. (로마자 같은 꼬부랑한 느낌이 별로 없다)

이런 이유로 인해, 글꼴에 라틴 같은 수준의 오동통한 개성이 들어갈 여지가 좀 덜하다.
한글 글꼴에 맞춰 만들어진 영문 글꼴은 순수 영문 글꼴보다 그런 기교가 neutralize된 경향이 있는 게 이 때문이 아닌가 싶다.

Posted by 사무엘

2014/05/23 08:27 2014/05/23 08:27
, ,
Response
No Trackback , a comment
RSS :
http://moogi.new21.org/tc/rss/response/966

작년 가을엔 <응답하라 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

« Previous : 1 : 2 : 3 : 4 : Next »

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/12   »
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:
1293972
Today:
623
Yesterday:
499