한글 노래 (2004/10/9)

사용자 삽입 이미지
저의 손글씨.. 2004년 한글날에 쓴 것입니다.

Posted by 사무엘

2010/01/13 00:13 2010/01/13 00:13
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/124

타자기 별 글꼴 비교

그림은 김 정수 지은 <한글의 역사와 미래> (열화당, 1990)에 있는 화보를 스캔한 것입니다.

1. 공 병우 세벌식 타자기

눈보다는 손의 편의를 철저하게 추구한 능률적인 타자 방식입니다. 글자를 알아보는 데는 지장이 없지만, 글자꼴이 뭔가 어설픈 느낌이 있습니다.

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

2. 표준 네벌식 타자기
가장 '타자기 글꼴'다운 글자꼴이 나옵니다.
사용자 삽입 이미지

3. 김 동훈 다섯벌식 타자기
손으로 쓴 글씨와 별 차이가 없을 정도로 꽤 볼 만한 사각형 글자꼴이 나옵니다. 그 대신 다섯 벌이나 되는 타법을 배우기는 어렵겠죠.
사용자 삽입 이미지

Posted by 사무엘

2010/01/12 23:55 2010/01/12 23:55
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/123

도스 시절의 한글 윤곽선 글꼴

사용자 삽입 이미지

도스 시절에 한글(한글에만 국한은 아니겠지만)을 출력하는 기법은 비트맵 아니면 벡터(윤곽선) 이렇게 두 갈래로 양분화해 있었다.

비트맵은 도깨비 한글의 8*4*4벌 규격에 맞게 만들어진 16*16 한글 글꼴을 찍는 것으로 사실상 통합이 되어 있었고, 윈도우 시대가 도래하기까지 널리 쓰였다. 뭔가 좀 아마추어스러운 냄새가 나고 상업/출판용 글꼴만치 고품질의 글자를 만들 수는 없지만, 그래도 가격 대 성능이 굉장히 뛰어난 좋은 방법이었기 때문이다.

본인이 아는 한, 한컴이나 MS 같은 회사가 아니라 개인이 만든 싸-_-제 프로그램이 이와 다른 기법으로 한글을 출력하는 것은 본 적이 없으며, 저 방식대로 수많은 싸제 글꼴들이 쏟아져 나오기도 했다. <날개셋> 편집기는 도깨비 글꼴도 지원하고, 임의의 조합 테이블을 가진 글꼴에다 2350 완성형 글꼴까지 지원함으로써, 한글 출력에서 그런 비트맵 글꼴 처리 분야는 완전히 마스터를 했다.

윈도우로 넘어가서도 이야기, 새롬 데이타맨처럼
그나마 고정폭 글꼴이 널리 쓰이는 VT 기반 통신 프로그램에서 비트맵 글꼴이 한동안은 명맥을 이어 나갔으나,
이마저도 이제 역사 속으로 사라져 버렸고, 오늘날 이런 16*16 한글 내지 8*16 영문 고정폭 비트맵 글꼴을 고수하고 있는 프로그램은 <날개셋> 편집기 뿐이다. ㄱㅅㄱㅅ

그럼 윤곽선 글꼴 분야로 가면 사정이 어떨까?
그 때에 도스에서 윤곽선 글꼴은 그래픽이나 워드 프로세서, 또는 그 둘의 중간에 해당하는 배너 같은 아주 특수한 분야의 전문 프로그램에서나 볼 수 있었다.

터보 C가 제공하던 BGI 라이브러리도 소위 벡터 글꼴을 지원은 했으나, 영문밖에 지원되지 않았고, 기술적으로도 진정한 의미의 곡선이 표현되지 못하며 내부 채움(래스터라이즈)도 안 되는 그냥 직선 나열일 뿐이었다.

그런 척박한 시절에 한글을 윤곽선 글꼴로 표현해 낸 프로그램이 있었으니 본인은 관심이 끌리지 않을 수 없었다. 아래의 프로그램들은 모두 1991~92년 그 시기에 제작되었다.
자형 디자인은 어떻게 하고 글꼴 파일 포맷은 어떻게 설계했을지, 래스터라이즈 루틴은 어떻게 작성했을지 모든 것이 그저 신기하게만 보인다.
(참고로 윈도우 운영체제도 3.x에서 윤곽선 트루타입 글꼴이 첫 도입된 건 이 시기이다!)

1. 하늘 (경북대 동아리)

내장하고 있는 싸제 글꼴은 형태가 심하게 조잡하긴 하다. =_=;; 이 글에서는 <하늘>만 예를 들지만, 과거 <수채화>도 글쓰기 기능의 퀄리티가 하늘과 굉장히 비슷했다. 단, <수채화>는 상업용 프로그램답게 얼추 배너 프로그램처럼 글자의 레이아웃을 변형하는 기능도 지원한다.

2. 한글 배너 (동국대 동아리?)

BannerMania라는 외산 상업용 프로그램으로부터 영감을 받아 개발된 게 분명한 프로그램이다. 영문 글꼴은 B에 있는 녀석을 그대로 쓴다. 즉, 이 프로그램의 개발자는 B의 글꼴 파일 포맷에 대한 정보를 입수했다는 뜻이다. 그 반면 한글 글꼴은 본인이 들여다본 바로는 B의 글꼴과 관계가 없는 자체 포맷이다.

학술 학회 명의로 되어 있지만 실질적인 개발은 개인이 혼자서 한 듯하다. 원전인 B보다 기능은 훨씬 더 뒤떨어지지만, 혼자서 저 정도 난이도의 프로그램 clone을 만든 거라면 지금 봐도 정말 대단한 거다.

글꼴 디자인도 개인 작품인지 궁금하다. 명조는 좀 어설픈 느낌이 나지만, 다른 글꼴인 고딕, 안상수, 샘물 등은 배너 용도로도 적합하고 은근히 볼 만하다.

3. 키다리 (개인+알파)

마우스로 조작하는 UI가 무척 특이하긴 한데, 이것도 상당히 잘 만든 공개 소프트웨어이다. 지금 <날개셋> 편집기에도 내장하고 있는 "키다리체"는 이 프로그램이 UI 출력용으로 쓰던 비트맵 글꼴이다. 그래픽체 비슷한 느낌을 낸 게 무척 참신하게 느껴지지만 좀 엉성한 느낌도 많이 들어 아쉬운 글꼴이다.

이 프로그램의 진면모는 바로 배너를 출력할 때 나오는 키다리 특유의 그래픽체이다. 신명 태그래픽을 연상시키는 이 글꼴은 개인이 디자인한 싸제이지만, 상당히 품질이 좋으며, 글꼴 전문 업체에서 만든 보급-_- 글꼴과 견주기에도 손색이 없다. 그러면서도 한글 11172자는 모두 표현 가능하다. 그래픽체는 비슷한 분위기의 영문 글꼴에서 착안하여 최초 원도를 최 정호 씨가 만든 것으로 잘 알려져 있는데, 자형 자체가 무척 깔끔하고 본문으로나 배너 장식으로나 적합해서 본인 역시 좋아한다.

엄청 옛날에 <자유>라는 프로그램도 있었다. 한번에 한두 줄짜리 배너만 출력하는 프로그램과는 달리, 얘는 한 페이지 안에 여러 배너 형태 문구들을 마치 벡터 드로잉처럼 배치하여 출력이 가능했는데 역시 윤곽선 글꼴과 다양한 효과를 지원했다. 본인이 본 버전은 무려 허큘리스에서 돌아가는 놈이었다.

4. 아래아한글 2.0 전문용

민간인이 열악한 여건 속에서 오로지 열정만으로 만들어 낸 "싸제" 글꼴과 공개 프로그램을,
한양 시스템이라는 번듯한 업체 글꼴을 사용한 상업용 프로그램과 동일선상에서 비교하는 것은 물론 무리가 있다. 그래도 역사 기록이니까 소개해 본다. 보급 글꼴은 2350자를 일일이 디자인한 것들이니, 싸제하고는 근본적으로 격이 다를 수밖에 없다. -_-;;;

그래픽체는 아래아한글 2.0 전문용에 원래는 없던 녀석이고, 아마 묵향 같은 한양 시스템 추가 패키지를 설치해야 추가되었지 싶다. (2.1 이후에 추가됨) 2.0 때는 아직 윤곽선 글꼴 파일 포맷도 굉장히 초보적이었으며, hft 파일 내부에 자기의 이름이나 제조사, 저작권/코드 페이지 정보 같은 것도 없었다. 오로지 윤곽선 벡터 드로잉의 컬렉션이었으며 이를 활용하는 방법은 전적으로 상위의 응용 프로그램에 달려 있었던 것이다.

그 당시 아래아한글 2.0 일반용 수준의 퀄리티와 가격에다, 윤곽선 글꼴 표현으로 아래아한글과 경쟁하던 프로그램으로 "21세기 워드"라는 게 있었다. 오늘날 말도 많고 탈도 많은 알툴즈의 개발사로 유명한 이스트소프트의 작품이다. 얘를 구경 못 한 채 어린 시절을 보낸 건 좀 아쉽다.

Note:

윈도우 3.1이 도입한 트루타입 글꼴은 어마어마하게 정교한 힌팅으로 유명했으며 이 기술을 이용하여 작은 크기에서도 상당히 좋은 품질의 자형을 제공했다. Arial이나 Times New Roman 같은 글꼴이 12포인트 이하의 작은 크기에서 antialiasing이 없을 때도 마치 비트맵 글꼴처럼 품질이 좋은 동시에 ClearType도 잘 받는 이유가 여기에 있다. 아예 굴림체처럼 내장 비트맵을 쓰는 글꼴은 ClearType의 영향은 받지 못한다.

윈도우 3.1 글꼴을 납품한 업체는 당시 우리나라의 유망 중소기업이던 큐닉스 컴퓨터이다. 아예 비트맵을 내장하는 게 아니라 힌팅만으로 바탕, 굴림, 돋움, 궁서 자형을 작은 크기에서 꽤 좋은 품질로 잘 만들었던 걸로 기억한다. 물론 윈도우 95 이후의 한양 시스템 서체는 아예 전부 내장 비트맵으로 대체를 해 버렸지만 말이다.

하지만 도스에서 윤곽선 글꼴을 구현하던 "싸제" 프로그램들은 그런 힌팅까지 구현할 정도로 전문적일 수는 없었다.

Posted by 사무엘

2010/01/11 10:20 2010/01/11 10:20
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/91

가는달, 굵은달, 버금달, 둥근모, 뻗음, 짧은둥근모, 짧은뻗음 (도깨비):
  모두 90년대 김 중태 님의 작품이다. 도스용 PC 통신 프로그램 이야기에도 이런 계보의 글꼴을 다수 볼 수 있었다.
특히 둥근모와 뻗음 류의 글꼴은 개인적으로도 무척 좋아하며, 심지어 전철 전광판에서도 볼 수 있다.

바탕, 가는돋움, 가는샘물, 필기 (custom):
  도스용 아래아한글 1.x가 제공하던 화면용 글꼴의 명조, 고딕, 샘물, 필기에 각각 해당한다. 고정된 도깨비 식 조합 테이블이 아니라 <날개셋> 5.3에서 첫 도입된 custom 조합 테이블을 사용했으며, 바탕과 샘물은 아래아한글 1.x 수준의 간단한 옛한글도 표현할 수 있다.
글꼴에 맞게 튜닝된 조합 테이블을 내장하고 있을 뿐더러 상업용 프로그램에서 사용되기도 한 만큼 글꼴의 품질은 무척 좋은 편이다. 다만, 다음에 나올 5.31에서 가는돋움은 아래아한글의 그 고딕체과 유사한 느낌이면서 더 깔끔하고 보기 좋은 다른 글꼴로 대체될 예정이다.

이야기체 (도깨비):
  한메 타자교사와 이야기 5.3이 사용하여 아주 널리 알려진 그 글꼴이다. 식상한 명조 고딕 류에서 탈피했고 나름 가독성도 좋아서 무척 잘 만든 글꼴이란 생각이 든다.

한솔바탕 (도깨비):
  도스용 수채화 2.x에서 유일하게 본 걸로 기억한다. 이것도 꽤 참신한 디자인이고 그럭저럭 쓸 만하다.

파도, 가는파도, 흘린둥근고딕 (도깨비):
  이 글꼴들은 화면용 16*16뿐만 아니라 출력용 자형도 있어서 아래아한글 HFT로도 변환되어 쓰였던 것 같다.

마소바탕 (custom):
  과거 MSHBIOS가 내부적으로 사용하던 글꼴을 완벽하게 재현한 것으로, 윈도우 3.1의 완성형 바탕체 글꼴의 짝퉁이라 할 수 있다. 조합 규칙이 도깨비와 살짝 다른 면이 있다. 미려한 것 같으면서도 철저하게 테스트를 안 하고 대충 어설프게 디자인을 끝냈다는 느낌을 지울 수 없다. 뭔가 2% 부족한 게 느껴지는 글꼴이다.

샘물2 (custom):
  박 정만 님이 제작한 2*1*2벌 샘물 계열 글꼴로, 도깨비 조합 규칙도 너무 널널하기 때문에 자체 조합 테이블을 내장시켜 글꼴 파일의 크기를 4KB가 채 안 되게 줄였다. 정사각형 안에서 공간을 최대한 활용하다 보니 다른 샘물 계열 글꼴에 비해 글자가 좀 납작하다는 인상은 받는다. 현재 <날개셋> 한글 입력기의 내장 글꼴은 정 재민 님이 이 글꼴을 다듬어 굵기를 줄이고 옛한글 자모를 추가한 것이다.

굽은샘물 (custom):
  도깨비 조합 규칙을 쓰는 공개 글꼴인데 실제로 사용되는 벌수는 3*1*2벌밖에 되지 않기 때문에 자체 조합 테이블 방식으로 파일 구조를 대체했다. 글자의 전반적인 느낌은 무척 깔끔하고 참신하지만 ㅔ, ㅐ, ㅗ 같은 모음과 자음을 변별하기 어려운 점이 좀 아쉽다.

타자기 (custom):
  무려 2*1*1벌로, <날개셋> 한글 입력기가 제공하는 글꼴 중 구조가 가장 초단순하다. 아래아한글 1.x 수준의 옛한글 자모까지 일부 있음에도 불구하고 크기는 겨우 4KB밖에 되지 않는다.

굴림옛한글 (custom):
  트루타입 글꼴의 내부에 있는 옛한글 비트맵 자형을 추출한 것으로, <날개셋> 5.x가 지원하는 유니코드 5.2 옛한글을 거의 다 그것도 네모꼴 글꼴로 표현할 수 있는 유일한 글꼴이다. 물론 초중종 벌수는 6*2*4벌로, 도깨비보다도 벌 수가 적으며 글자가 전반적으로 좀 엉성하긴 하다.

유사굴림 (custom):
  다음 5.31 버전에서 추가될 예정인 글꼴로, "굴림체" 16픽셀을 얼추 조합형 글꼴로 본뜬 짝퉁이다. 현대 한글 11172자밖에 표현할 수 없지만 크기는 무려 40KB를 넘어서 "굴림 옛한글" 수준에 육박하는데, 이는 조합 테이블의 크기가 굉장히 크며 초성 하나, 모음 하나가 10여 벌, 20여 벌에 달하는 경우도 있기 때문이다. 가장 정교하고 복잡한 조합 테이블을 사용하는 글꼴이다.
다른 글꼴들은 초성은 겨우 ㄱㅋ, 종성은 ㄴ 정도만 따로 분리하여 그룹을 나누는 반면 이 글꼴은 거의 모든 자소들이 분할되어 있으며 자형 활용의 폭이 가장 크다. 가령 다른 글꼴들은 농과 논, 통과 톤에서 ㅗ의 위치가 다 같지만, 이 글꼴은 다 다르다. 그렇기 때문에 글자 하나의 완성도 하나는 이 글꼴이 가장 뛰어나다.

도깨비 방식,
그리고 도깨비보다 간단한 글꼴 내지 더 복잡한 글꼴.
<날개셋> 편집기는 한글 입력 방식뿐만 아니라 출력 방식도 과거와 현재의 만남의 장이 되고 있다.

Posted by 사무엘

2010/01/11 09:56 2010/01/11 09:56
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/77

TTF의 글립 개수 제한

오늘날 운영체제의 표준 글꼴 포맷으로 널리 쓰이고 있는 TTF 내지 OTF는 내부적으로 쓰는 각종 구조체들이 기술하는 글립의 영역 크기가 16비트로 제한되어 있다.

이것은 TTF 파일이 제정되던 초창시에는 아주 넉넉하고 인심 쓴 공간이었다. 겨우 8비트 크기의 코드 페이지에 맞춰진 글꼴밖에 없던 서양에서, 그나마 “수천 자의 2바이트 한자를 써야 하는 동아시아 문자권”까지 국제화 차원에서 고려한답시고 크기를 넓힌 게 16비트였다. 무슨 포스트스크립트 글꼴은 그것마저 지원 안 돼서 한글 글꼴은 여러 파일로 나눠서 표현해야 하지 않았던가. 쓸데없이 비트 수가 크면, 쓰는 영역에 비해 불필요한 0만 뒤에 잔뜩 달라붙고 글꼴 래스터라이저를 더욱 ‘무겁게’ 만들게 된다.

하지만 지금은 시대가 달라졌다. 아무리 작은 임베디드 기기라도, 일단 사람과 직접적인 의사 소통을 하는 기계의 CPU는 일단 최하 32비트는 기본으로 먹고 들어간다. 실용적으로 가장 적합하면서도 가상 메모리라든가 현대적인 운영체제 기본 개념을 제대로 구현할 수 있는 최소한의 CPU 규모가 32비트가 아닌가 한다.

메모리 자원은 넉넉해지고 국제화의 중요성은 엄청 커졌다. 그래서 한컴바탕이라든가 Arial Unicode MS처럼, 모든 유니코드 영역 글꼴을 모두 담고 있는 글꼴의 필요성이 대두되고 있다.

아직 모든 문자가 16비트 안의 BMP에 있던 유니코드 2~3.0 시절까지는 그럭저럭 별 문제 없었고 6만 5천여 개라는 글립 개수 제한은 현실적으로 별 영향이 없었다. 하지만 이제 유니코드가 surrogate 영역까지 쓰고 집합 크기가 16비트 크기를 넘어서면서, 이제 단일 글꼴에다 유니코드 전영역 문자를 담을 수가 없어져 버렸다.

더구나 이 16비트라는 크기는 글자 코드 단위가 아니라, 글립이라는 그림 단위이다. 한 코드 페이지에 해당하는 글자가 여러 글립을 차지할 수가 있다. 조합형 한글 글꼴처럼 한 글자를 여러 글립의 묶음으로 표현하는 글꼴이 있다면, 그렇게 부품 글립이 들어가는 자리를 글립 인덱스 상으로 제외해 줘야 한다. 아랍어처럼 한 글자가 상황에 따라 여러 글립 중 하나로 달리 표현되는 문자가 있다면, 그런 것까지 고려해야 하기 때문에 실질적으로 표현 가능한 문자 개수는 더욱 줄어든다.

지금 컴퓨터의 두뇌가 32비트와 64비트 사이에서 달랑달랑 거리는 것처럼, 글꼴 쪽은 16비트 크기라는 글립 개수 한계를 어떻게 초월해야 할지 고민 중이다. 당연히 TTF 규격상으로 각종 구조체의 필드를 확장하고 새 버전 식별자만 부여하면 문제는 해결된다. 하지만 온갖 테이블들의 내부에서 바꿔야 하는 게 너무 많고 이 새로운 TTF는 이전의 어떤 운영체제/응용 프로그램에서도 인식 못 하는 듣보잡 포맷이 되고 말 것이다. 결국 문제는 호환성이다. =_=;;

Posted by 사무엘

2010/01/11 09:49 2010/01/11 09:49
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/71

베지어 곡선으로 표현한 원

사용자 삽입 이미지
밝은 초록색 선은 정석적인 원그리기 알고리즘으로 그린 진짜 원.
파란색 선은 제어점이 2개인 3차 베지어 곡선 하나로 사분원을 흉내낸 것,
그리고 빨간색 선은 제어점이 하나인 2차 베지어 곡선 두 개로 사분원을 흉내낸 것입니다.

베지어 곡선으로 원을 수학적으로 100% 정확하게 기술할 수는 없습니다.
단지 제어점을 잘 배치해서 원과 굉장히 비슷하게 생긴 곡선만을 그릴 수 있을 뿐입니다.

그래도 곡선이 그려진 곳에 초록색 점을 거의 찾을 수 없는 걸 알 수 있는데요, 3차 베지어 곡선(파란)만 해도 원하고 실용적으로 아무 차이가 없을 정도로 잘 근사해 냅니다.

빨간 선인 2차 베지어 곡선도 파란 선(≒ 원)과 상당히 일치하긴 하지만 그래도 파란 선이 초록 선과 일치하는 것만치 일치하지는 못합니다. 미묘하게 서로 살짝 어긋나는 오차가 보이죠?
(2차 곡선 여러 개를 모아도 3차 곡선을 근사만 할 수 있을 뿐 정확하게 일치시킬 수는 없습니다.)

컴퓨터의 벡터 드로잉에서 쓰이는 곡선들은 다 베지어 곡선(또는 이와 수학적으로 동일한 형태로 변형할 수 있는 다른 스플라인)입니다.
특히 트루타입 폰트가 쓰는 곡선은 2차 베지어 곡선이기 때문에 이렇게 빨간 선을 표현하는 방식과 동일한 방식으로 O, 이응, ● 같은 글자가 표현된다고 생각하시면 정확합니다.

Posted by 사무엘

2010/01/11 00:20 2010/01/11 00:20
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/49

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

블로그 이미지

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

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2021/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:
1698889
Today:
10
Yesterday:
537