KR900007799B1

KR900007799B1 - 폰트데이타 함축방법

Info

Publication number: KR900007799B1
Application number: KR1019870013670A
Authority: KR
Inventors: 정정오
Original assignee: 주식회사 금성사; 최근선
Priority date: 1987-11-30
Filing date: 1987-11-30
Publication date: 1990-10-20
Also published as: KR890008669A

Abstract

내용 없음.

Description

폰트데이타 함축방법

제1도는 종래의 폰트 데이타 저장구조 설명도.

제2도는 본 발명에 따른 줄 바이트의 비트 분할 구성도

제3도는 본 발명에 따른 폰드 데이타 저장구조 설명도.

제4도는 레이저 프린타의 콘트롤러 블록도.

제5도는 본 발명에 따른 폰트 데이타를 함축시키는 방법의 플로우챠트.

* 도면의 주요부분에 대한 부호의 설명

1 : MPU 2 : 시스템 램

3 : 래스터 메모리 4 : 어드레스 버스

5 : 데이타 버스 6 : I/O 포트

7 : 시스템 롬 8 : 폰트롬

본 발명은 레이저 프린터의 폰트 데이타(Font Data) 함축방법에 관한 것으로, 특히 비트 이미지(Bit Image) 상태의 폰트 데이타를 함축시키는 방법으로서 위아래 두줄의 데이타를 바이트(Byte) 단위로 비교하여 윗줄과 다른 바이트만을 기억하여 폰트 데이타를 함축 저장하는 방법에 관한 것이다.

종래에는 폰트 데이타를 바이트 단위로 분할하여 각 메모리에 할당하여 데이타를 저장하는 방법을 사용하여 왔다.

즉, 폰트 데이타에 대한 특정정보를 표시하지 않고 데이타 바이트들로만 구성되었었다.

종래의 방법에 따라 폰트데이타를 저장한 것을 제1도에 따라서 설명하면, 제1도에 도시된 바와같이 단순히 8도트(Dots)씩 분할하여 메모리에 저장했으므로 32 X 32 폰트의 데이타를 저장하는 데는 128바이트의 메로리가 필요했었다.

즉, 제1도에서 "밝"자를 저장하기 위해서는 16진수로 표기된 우측의 "데이타 바이트"에서와 같이 총 128바이트가 필요하게 된다. 예로서 15번째 바이트에는 16진수 "7"의 데이타가 저장되어 있는데 이는 2진수 "0000 0111"데이타 이다.

또한 122번째 바이트에는 16진수 "30"의 데이타(2진수 "0011 0000"의 데이타)가 저장되게 되는 것이다.

따라서 폰트 데이타를 비트 이미지 상태로 저장하려면 메모리 용량이 커지고 가격이 비싸졌다.

또한 메모리가 PCB상에서 차지하는 면적이 커져서 콘트롤러를 소형화하기가 어려운등 여러가지 문제점이 있었다.

본 발명은 이러한 종래의 문제점을 개선하기 위해 비트 이미지 상태의 폰트 데이타를 함축 시키는 것으로서 위, 아래 두줄의 데이타를 바이트단위로 비교하고 윗줄과 다른 아랫줄의 바이트만을 기억하게 하는 방법인 것이다.

여기서 기억된 바이트가 그줄의 몇번째 바이트인가 그리고 그줄에는 윗줄과 다른 바이트가 몇개나 있는가를 알아야 한다. 따라서 각줄 마다 그줄에 대한 정보를 지니고 있는 바이트가 별도로 필요하게 된다.

각줄에 대한 정보를 지니고 있는 바이트의 각 비트는 제2도에 도시된 바와같이 분할되었으며, 상위의 5비트는 몇번째 바이트의 데이타가 윗글과 다른가를 나타내고 있으며, 하위의 3비트는 그줄에 윗줄과 다른 바이트가 몇개 있는가를 나타낸다.

가령 예를들면 현재줄과 윗줄과의 데이타를 비교해 볼때 두번째, 세번째, 네번째의 바이트가 윗줄과 다른 경우 현재줄의 정보 바이트의 내용은 '0111 0011'이 된다.

즉, '0111 0011'중 상위의 5비트 '01110'에는 2, 3, 4번째 바이트가 다름을 나타내고 1번째와 5번째 바이트는 같음을 나타내며 하위의 3비트 '011'는 서로 다른 바이트가 3바이트 임을 나타낸다.('011'은 십진수 3이므로)

본 발명에 따른 폰트데이타를 저장한 예를 제3도에 따라 설명하면, 첫줄의 경우에는 그윗줄이 없으므로 그 윗줄은 모든 비트가 0이었다고 가정하고 비교한다.

그 까닭은 대개의 폰트가 가장자리엔 데이타가 없으므로 첫줄이 간단히 1바이트로 표시될 수 있다.(0000 0000)

두번째줄의 경우 첫째줄과 같음으로 줄정보 바이트 하나로 표시가 가능하다.(0000 0000=1byte)

세번째의 경우 세번째 바이트가 두번째줄의 데이타와 다르므로 하나의 줄정보 바이트(0010 0001)와 1바이트의 데이타 바이트(0000 0111)로 표시할 수 있다.

즉 줄정보 바이트 '0010 0001'는 3번째 바이트('00100')하나 ('001')만 다름을 표시하며, 다른 1바이트의 데이타는 '0000 0111'임을 나타낸다.

같은 방법으로 네번째, 다섯번째, 여섯번째줄을 표시할 수 있다.

여섯번째줄 부터 아홉번째줄 까지가 모두 그 윗줄과 같으므로 각줄이 정보 바이트 하나로 표시될 수 있다.

또한 4번째줄은 3바이트 '32 03 80'로 구성되어 있는데 32(0011 0010)는 3번째, 4번째 바이트가 다르며(00110), 따라서 2바이트가 다름을 나타내고(010), 서로다른 2바이트의 데이타는 각각 03(0000 0011)과 80(1000 0000)임을 나타낸다.

이상과 같은 방법으로 제3도에서와 같은 32 X 32 폰트 데이타를 단지 52바이트로 저장할 수 있다.

종래에는 이 경우 128바이트로 저장해야 하기 때문에 메모리의 용량이 커졌다.

본 발명에서 사용하는 레이저 프린터의 콘트롤러를 제4도의 브록도에 따라 설명하면 MPU(1)와 시스템램(System Ram)(2), 래스터 메모리 (Raster Memory)(3), 입출력(I/O) 포트(6), 시스템롤(Rom(7), 폰트롬(Rom)(8)으로 구성된 콘트롤러에서 MPU(1)와 시스템 램(2), 래스터 메모리(3)는 어드레스 버스(4)와 데이타 버스(5)를 거쳐 입출력 포트(6)와 시스템롬(7), 폰트롬(8)에 연결된다.

따라서 기존의 폰트 이미지는 데이타 함축 절차를 밟아 압축된 폰트이미지로 된다.

본 발명에 따라 폰트데이타를 함축시키는 방법을 제5도에 표시된 것과 같은 플로우챠트에 따라 설명하면 다음과 간다.

먼저 폰트스타트(font-Start : 함축되기전 폰트데이타가 저장되어 있는 메모리의 첫번째 번지), 폰트 바이트(font-byte : 함축되기전 폰트데이타의 한줄이 몇바이트로 구성되어 있는가를 표시), 폰트로우(font-row : 함축되기전 폰트데이타가 몇줄로 구성되어 있는가를 표시), 뉴스타트(New-start : 함축된 폰트 데이타가 저장되는 메모리의 첫번째 번지)를 읽어 들인다.

다음에 폰트스타트(font-start)를 폰트 어드레스(font-addr : 함축되기전 폰트 데이타가 들어 있는 메모리 번지)로 지정하고, 뉴스타트(new-start)를 커 어드레스(Cur-addr : 함축된 폰트 데이타가 저장되는 메로리번지)로 지정 한다음 i=O으로 하고, 먼저줄의 데이타를 저장해두는 어레이(array)인 기준데이타(ref-data)를 순서대로 확인해서 회수를 거듭하여 i가 폰트바이트보다 작을때까지 반복 확인을 한다.

이것은 폰트 바이트수 만큼 기준데이타의 바이트를 0으로 해서 초기화하는 것이다.

다음에 j=0으로 하고 한줄의 비트 이미지 데이타를 줄정보바이트와 데이타 바이트로 함축하여 저장하는 절차로서 줄정보 바이트인 로우바이트(row-byte)를 0으로 하고 윗줄과 다른 데이타 바이트수를 표시하는 데이타 바이트릍 0으로 하고 커 어드레스를 하나 중가시킨 다음 K=0으로 초기화 한다. 폰트어드레스 기준데이타[K]를 읽어서 폰트 어드레스와 기준데이타[K]가 같은가를 판단한다.

이때 폰트 어드레스와 기준데이타가 다르면 로우바이트는 로우 바이트가 윗줄과 다른 데이타 바이트의 위치를 나타내는 비트 세트(row-byte bit set[K]와 로우바이트를 오아링(Oring)한 값이되고, 데이타 바이트는 1증가(data byte=data byte+1)하며, 기준데이타[ref-data(k)]는 폰트 어드레스 메모리 번지의 내용인 폰트 어드레스(*font-addr)가 된다.

커 어드레스(*Cur-addr)는 폰트어드레스(*font-addr)가 되고, 커어드레스는 하나씩 증가한다.(Cur-addr=cur-addr+1)

다음에는 K=K+1로 한 상태에서 폰트어드레스 또한 1증가(font-addr=font-daar+1) 한다.

만약 폰트 어드레스(*font-addr)가 기준데이타[ref-data(k)]와 같으면 바로 K=K+1로 된 상태에서 폰트 어드레스는 폰트어드레스+1이 된다.(font-addr=font-daar+1)

따라서 K=0으로 부터 K가 폰트 바이트보다 작은 상태에 까지는 이러한 절차를 반복 수행해서 K가 폰트바이트와 같아지거나 커지면 로우 바이트는 로우바이트와 데이타 바이트를 오아링한 값이되고 커어드레스는 커 어드레스에서 "데이타 바이트+1"를 뺀 상태가 되고, [cur-addr=cur-addr-(data-byte+1], 커어드레스(*cut-addr)는 로우 바이트(row-byte)가 되고, 커 어드레스(cur-addr)는 커어드레스에 "데이타바이트+1"를 더한것 [cur-addr=cur-addr+(data-byte+1)]과 같게 된다.

이러한 절차를 j의 증가에 따라 반복하되 j가 폰트로우 보다 크거나 같아질때 까지하며 이것이 커지면 한글자가 완전히 표시 되었는가를 체크하게 된다.

따라서 제4도와 같은 레이저 프린터 콘트롤러의 내장되는 폰트 저장에 있어서 연속되는 위 아래 두줄의 데이타를 비교하여 윗줄과 다른 데이타 바이트만을 현재줄의 데이타 바이트로 폰트롬(8)에 저장하고, 그줄에 저장된 데이타 바이트의 인자위치 및 갯수를 나타내는 줄정보 바이트를 폰트롬(8)에 저장하는 폰트데이타의 함축 저장이 가능해진다. 그러므로 본 발명에 따른 폰트 데이타 함축 저장방법을 사용하면 작은 메모리에 많은 폰트 데이타를 저장할 수 있어 가격이 싸지고 메모리를 적게 사용하므로서 콘트롤러 PCB 크기가 작은 경우에도 많은 폰트를 내장할 수 있는 이점이 있는 것이다.

Claims

레이저 프린터 콘트롤러의 내장 폰트 저장에 있어서, 연속되는 위아래 두줄의 데이타를 바이트 단위로 비교하여 서로다른 바이트의 위치와 바이트수를 폰트롬(8)의 줄정보 바이트에 저장하고, 윗줄과 아랫줄의 데이타가 다른경우의 데이타 바이트만을 현재줄의 데이타 바이트로 폰트롬(8)에 저장하여 함축 저장되도록한 것을 특징으로 하는 폰트 데이타 함축방법.