1992.6.8.
SUBJECT: 완성형과 조합형 코드체계와 폰트에 대하여
STATUS OF THIS MEMO:
코드체계(Codeset)과 폰트로 나누어 완성형과 조합형을 설명한다.
TABLE OF CONTENTS:
0. Codeset의 조합형과 완성형에 관하여
1) 한글 코드 체계의 기본 원리
2) 한글 코드 의 종류
3) 한글 코드 체계와 국제 규격의 문제
4) 2 바이트 완성형 한글(KS 완성형)
5) 2 바이트 조합형 한글
1. Font의 조합형과 완성형에 관하여
0) 완성형 폰트와 조합형 폰트의 크기
1) 완성형 폰트
2) 조합형 폰트
2. 참고 자료
DESCRIPTION:
0. Codeset의 조합형과 완성형에 관하여
1) 한글 코드 체계의 기본 원리
* 한글의 특성을 살펴 보면, 크게 자음과 모음으로 나뉘어 각각 14개, 10개로
전체 24개의 기본적인 자소로 글자를 형성한다.
* 더 나아가 쌍자음(5개),복자음(11개),복모음(11개) 등도 형성된다.
* 한글 자모체계
초성 : 자음(14) + 쌍자음(5) = 19 개
중성 : 자음(10) + 쌍자음(11) = 21 개
종성 : 자음(14) + 쌍자음(11) + 쌍자음(2) = 27 개
( 따라서 5 bit 만 가지면 각 성을 표현할 수 있고, 조합형 2바이트 한글은
각 성을 표현하는데 5비트씩 할당하고 있다.)
전체자수 :
받침 없는 글자 : 초성(19) x 중성(21) = 399 자
받침 있는 글자 : 초성(19) x 중성(21) x 종성(27) = 10,773 자
2) 한글 코드 의 종류
* n 바이트 한글이니 3 바이트 한글이니 7 bit 2 바이트 완성형 한글이니 하는것들이
있으나 현재 별로 사용되지 않음.
* 2 바이트 완성형 한글(KS 완성형): 4)에서 설명.
* 2 바이트 조합형 한글: 5)에서 설명.
3) 한글 코드 체계와 국제 규격의 문제
* ASCII codeset 사용시 0에서 127까지만 있어도 프로그램 제작에 별 지장이 없고
나머지 128에서 255까지는 그래픽 문자코드에 해당된다.
* 바로 이와 같은 특성을 이용 대분분의 영문 소프트웨어는 코드값 128번지 이후부터는
즉 총 8개의 비트중 MSB(Most Significant Bit:최상위 비트를 의미)라 불리우는 비트가
1로 시작하는 코드들에 각기 필요한 특수 기능을 할당하여 이용하기도 한다.
* 이런 관계로 8비트 2바이트 조합형이나 8비트 2바이트 완성형 한글은
영문 소프트웨어에서 한글을 표시할 수 없게 되는 것이다.
* 현재 ISO에서는 영문자를 표현하기 위해 국제적으로 널리 사용되고 있는 아스키 코드를
ISO-646이라는 규격으로 정의하고 있다. 아스키 코드는 7비트로 정의되어 128개의
문자를 포함하는데 이 128개의 문자는 영문자 문화권에서는 큰 불편이 없지만
글자의 수가 많은 동양권에서는 글자를 표현하는데 커다란 어려움이 있다.
* 이 때문에 ISO에서는 아스키 코드를 확장하여 두 바이트 이상의 코드체계를 사용할 때
지켜야 할 부호확장법에 대한 규격을 ISO-2022라는 이름으로 정의하고 있다.
* ISO-2022의 구조는 다음과 같다.
먼저 아스키 코드값 0부터 31까지의 각종 제어문자 영역을 C0영역이라 하며,
128부터 159까지 C0영역 외에 확장된 제어코드를 두고 C1영역이라고 한다.
ISO-2022에서는 C0와 C1영역에 문자를 배당할 수 없도록 제한하고 있다.
또 아스키 32와 160은 공백(SPACE)문장이며, 아스키 127과 255는 지움(DEL)문자로
정의하고 있다. 따라서 이 규정에 따를 경우 각 바이트에서 문자를 배당할 수 있는
영역은 아스키 33-126과 161-254의 두 영역이 된다. 이를 두 바이트로 표시하면
아래 그림과 같다.
----->
두번째 바이트
0 32 128 160 255
0 +--------+-------------------------+--------+-------------------------+
| | C0 영역 | | C0 영역 |
32 +--------+-------------------------+--------+-------------------------+
| | A영역(제1상한) | | B영역(제2상한) |
| C0 | 첫째 바이트 < 128(0x80) | C1 | 첫째 바이트 < 128(0x80) |
첫 | 영역 | 둘째 바이트 < 128(0x80) | 영역 | 둘째 바이트 > 128(0x80) |
번 128 | | 아스키 영역 | | |
| 째 +--------+-------------------------+--------+-------------------------+
| | | C1 영역 | | C1 영역 |
| 바 160 +--------+-------------------------+--------+-------------------------+
V 이 | | C영역(제3상한) | | D영역(제4상한) |
트 | C0 | 첫째 바이트 > 128(0x80) | C1 | 첫째 바이트 > 128(0x80) |
| 영역 | 둘째 바이트 < 128(0x80) | 영역 | 둘째 바이트 > 128(0x80) |
| | 조합형 한글 | | 완성형 한글 |
255 +--------+-------------------------+--------+-------------------------+
* ISO-2022에서는 2바이트 확장문자의 경우 각 바이트의 MSB(최상위비트)가
모두 같을 것을 요구하고 있으므로 A영역과 D영역만을 한글 코드로 사용할 수 있고
A영역의 경우 두 바이트의 MSB 모두 0이 되고 D영역은 두바이트 모두 MSB가 1이 된다.
아스키와의 충돌을 피하다 보니 실제 확장문자를 위해 사용되는 영역은 D영역만이 된다.
* 결국 한글 표준은 제4상한을 이용한 완성형 KS C5601이 되었고 이를 1수준 한글이라 한다.
그러나 ISO-202에서 허용하는 제4상한선의 제약으로 한글표현의 제한된 표현을 보완코자
두 개의 확장 세트안을 KS C5657로 만들어 발표한다.
이는 제4상한에서 모자란 글자를 제3상한을 이용해 확장한 코드체계로
2수준 한글이라고 한다.
4) 2 바이트 완성형 한글(KS 완성형):
* 이는 KS C5601의 일부이다.
KS C5601은 한글 2350자, 한문 4888자, 특수문자 1128자를 표현한다.
* 한글 2350자는 조합형으로 만들어 낼 수 있는 음절 수인 11,172자의 20%에 불과.
평소 사용하는 한글의 99.999%를 포함한다고 한다.
초성,중성,종성의 3성의 조합으로 구성된 한글은 자주 사용되지 않는 글자가 거의
70% 가 되고 이러한 점을 이용하여 나온 것이 완성형 한글이다.
| First Byte | | Second Byte |
| | | |
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 | | | | | | | | | 1 | | | | | | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| |
MSB MSB
* 위의 MSB를 제외한 비트들에 글자를 음절 단위로 할당한다.
* 장단점 :
- 완성형 한글 코드의 장점이자 표준안으로 채택된 가장 큰 이유는 ISO-2022의
규약에 가장 적합하기 때문이었다.
- 반면 완성형 한글 코드는 ISO-2022에서 허용하는 제4상한선의 제약으로
한글 표현에 제한이 있고, 설사 확장 세트로서 한글을 추가시켜 놓았다고 해도
어디까지나 정보 교환용으로 만들어 놓았기 때문에 정보 교환용 코드와 정보 처리용
코드의 분간이 애매한 개인용 컴퓨터에서는 큰 도움이 되지를 않는다.
- 이 코드는 다른 프로그램 및 통신 등에 이용되는 것을 피해 작성되었기 때문에
통신에는 매우 적합하다고 할 수 있지만,
한글 조합의 원리를 무시하고 한글을 상형문자처럼 취급한 관계로
자수의 제한이라는 문제가 제기되고 결과적으로 표시할 수 없는 글자가 생긴다.
- 정열(Sort)는 가능하나 자소별 통계나 성별 통계를 내는 데 난점이 많으며
자소마다 각각의 코드를 갖지 못하기 때문에 키입력을 받아서 완성형 코드로
만들어 주는 소프트웨어가 대단히 복잡하다.
5) 2 바이트 조합형 한글:
| First Byte | | Second Byte |
| | | |
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 | | | | | | | | | 0 | 0 | 0 | 1 | 1 | 0 | 1 | 1 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | | | | |
| +---------------+ +------------------+ +---------------+
| 초성 중성 종성
MSB(한글/영문 표시)
* 2바이트 조합형 한글은 연속된 2개의 바이트를 뒤에서 부터 5비트씩 묶어
각각 초성,중성,종성을 표시하는 원리로,
나머지 한 비트에는 1을 설정하여 한글 코드임을 컴퓨터에 알리고 있다.
* 상위 바이트의 MSB가 1(즉, 128이상)이면 한글 0(128 이하)이면 영문이 된다.
MSB가 1인 상태에서 초성이 정상적일지라도 중성이 잘못 배열되어 있다면 하위 바이트가
제어 코드가 될 수 있다.
중성의 하위 3비트가 모두 0이면 종성이 무엇일지라도 하위 바이트는
ASCII 코드의 제어코드(Control Character - 0x1f 즉 31 이하)가 되어 버린다.
위 그림의 Second Byte는 한 예를 들기 위해 각 비트값을 주었다.
위의 Second Byte의 경우 컴퓨터가 인식하기를 한글 중성 하위 비트와 종성으로 인식하는
것이 아니라 ASCII code Decimal 27 인 ESC 로 인식한다.
따라서 여러 회사에서 각기 만들어 사용하는 조합형 한글들을 보면 대개가
중성 하위 3비트와 종성의 5비트에 할당되는 몇개의 코드값을 피해 코드테이블이 만들어 진다.
* 장단점 :
- 조합형 코드의 경우에는 ISO-2022에서 쓸 수 없도록 하고 있는 제3상한선을
쓰고 있기 때문에 국제 규격과 완전한 호환이 될 수 없으며,
가종 메타 문자와 충돌하는 문제점들이 있다.
- 조합형은 한글이 가지는 특성을 모두 살리는 동시에 컴퓨터의 논리성에도 부합되는
코드체계라고들 한다.
- 가장 큰 장점은 현재 사용되는 모든 한글 자수를 표현할 수 있고, 한자도 약 5000자
정도까지 표현 가능하다는 점이다.
- 또한 한글 모아 쓰기 부분인 Automata 작성이 매우 용이하다.
1. Font의 조합형과 완성형에 관하여
0) 완성형 폰트와 조합형 폰트의 크기
* 여기서는 bitmap 폰트를 예로 들겠다.
* 폰트의 종류는 대체로 8x8,10x10,12x12,14x14,16x16,20x20,24x24,32x32,40x40,48x48등이 있다.
* Bitmap 폰트는 한 글자를 display하는데 1 pixel 당 1 bit를 사용한다.
* 16x16 폰트 한 글자를 위해 16비트 x 16바이트 = 32바이트가 필요하다.
* 완성형 한글 16x16 폰트 화일의 크기 : 32바이트 x 2352자 = 75,264바이트 즉 75K 정도
* 조합형 한글 16x16 폰트 화일의 크기 :
。초성 : 19자 x 10벌 = 190자 --+
。중성 : 21자 x 2-4벌 = 84자 | 544자 x 32바이트 = 21,440바이트 즉 21K 정도
。종성 : 27자 x 10벌 = 270자 --+
* 이상에서 조합형 한글 폰트의 사용이 완성형에 비해 상대적으로 얼마만큼의 Memory load를
줄일 수 있는지 상상할 수 있겠다.
* 8x8 폰트가 보여지는 예를 든다.
각 bit에서 1로 되어 있는 부분이 화면의 pixel에 검은색으로 보여주는 부분이다.
|----------- 8 column ----------|
+---+---+---+---+---+---+---+---+ --- 여기서는 "나"라는 글자가
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | bitmap file에 저장되었다 표현되는
+---+---+---+---+---+---+---+---+ | 경우이다.
| 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | | 실제 폰트 화일은 byte stream으로
+---+---+---+---+---+---+---+---+ | 저장되었다.
| 0 | 1 | 0 | 0 | 0 | 1 | 0 | 0 | | column으로는
+---+---+---+---+---+---+---+---+ | 8x8의 경우 8/8 byte로 표현된다.
| 0 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | | 16x16의 경우 16/8 byte로
+---+---+---+---+---+---+---+---+ 8 rows 32x32의 경우 32/8 byte등으로
| 0 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | | 표현된다.
+---+---+---+---+---+---+---+---+ |
| 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | |
+---+---+---+---+---+---+---+---+ |
| 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | |
+---+---+---+---+---+---+---+---+ |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | |
+---+---+---+---+---+---+---+---+ ---
1) 완성형 폰트
* 한 글자(음절) 마다 폰트를 가진다.
* 그러므로 모양은 좋으나 많은 space를 차지한다.
2) 조합형 폰트
* 초성,중성,종성에 대해 종류별 폰트를 가진다.
* 완성형에 비해 조합된 글자 모양이 좋지 않으나 space가 작음.
* 조합형 한글 폰트를 사용하는 한글 Application의 경우, 한 글자를 보여 주는데 있어
Application내에 초성,중성,종성의 폰트를 조합하는 routine이 있어야 한다.
개발자의 입장에서 볼 때 조합형 폰트를 사용해 Application을 개발한다 함은
완성형 폰트에 비해 귀찮은 과정이긴 하나 그 필요성이 점증하는 환경이라 하겠다.
폰트가 예쁘기는 하지만 값이 매우 비싼 완성형 한글 폰트를 구매하여
Application을 개발한다 함은 예외적인 경우를 빼고는 대개 무지의 소치거나
아주 게으르고 돈많은 개발자의 경우라는 말들이 있는데 이는 아래 예를 통해 판단하시라 !
* 조합형 폰트의 필요성에 대해 살펴 본다.
- 기존의 Workstation의 경우 Main Memory가 8-16M가 기본이고 충분한 Disk Size를
가짐에 따라 완성형 폰트를 사용하여도 별 문제가 없었다.
- X Terminal과 같은 경우 Main Memory 기본이 4M 밖에 안되고
따라서 완성형 폰트를 사용하는 Application이라면 크기가 큰 폰트를 load 하는 경우
Memory 부족 현상이 발생한다.
- Labtam X Terminal에서 한글 X11을 띄워 24x24 폰트를 load 하려면 안된다던지
한글 Alis를 띄우지 못한다던지 하는 경우가 대표적인 예이다.
- 한편 Visual X Terminal과 같은 경우 이러한 문제가 발생치 않음은 Visual Xserver가
Memory 부족시 swapping을 하기 때문이다. 이처럼 기능이 좋은 Xterminal만을 상대로
Application을 개발할 수 있다면 조합형 폰트니 완성형 폰트니 하는 문제는 그 의미가
많이 축소될 것이나 Labtam X Terminal을 판매하고 있는 회사의 현실이 문제이다.
- 이상의 문제들은 일견 해석하기를 Memory와 Disk Size가 작고 부족한 PC level에서
완성형 폰트보다 조합형 폰트를 선호하는 경향이 Workstation level에서도 발생하게
된 것이라고도 한다.
- 물론 이는 Workstation 자체의 문제는 아니지만
Workstation에서 수행되는 한글화된 Application이 늘어나고 있고
또 이들 Application이 X Window와 같은 network based window를 지원하는 추세라
Workstation이 아닌 적은 양의 Memory를 가진 X Terminal에 load되는 한글 폰트에 대해
어떤 종류의 폰트를 사용할 것인지 개발시 충분한 고려를 해야 한다 하겠다.
특히 Application의 속성상 여러 종류의 한글 폰트들을 load해야 하는 경우라면 더욱
그렇다.
2. 참고 자료
* 김정민DL,정창훈씨 설명
* 한글 코드체계 그 알파와 오메가 ( 박현철, 마이크로소프트웨어 89년 3월)
* PC에서 쓰이는 글자모양에 관한 글 ( 이찬진, 마이크로소프트웨어 89년 1월)
* PC에서 쓰이는 글자모양에 관한 글 ( 이찬진, 마이크로소프트웨어 89년 2월)
* PC에서 쓰이는 글자모양에 관한 글 ( 이찬진, 마이크로소프트웨어 89년 3월)
* 다시 불붙은 한글 코드 논쟁 무엇이 문제인가 ? (안범수, 퍼스널컴퓨터 92년 5월)
Revision History
Created on June 8. 1992.
Updated on June 17. 1992.