4.외곽선 추출

가.FT_Outline

외곽선 폰트의 글리프를 로드하면 글자의 모양을 정의하는 외곽선이 로드된다. 그러나 외곽선 정보는 좌표만으로 구성되어 있기 때문에 외곽선을 그리는 함수를 호출해야만 출력할 수 있다. 외곽선 수식이 워낙 복잡하기 때문에 이 속도는 상당히 느린 편이다. 그래서 외곽선을 바로 화면으로 출력하지 않고 비트맵으로 변환하는 과정을 거치는데 이 과정을 래스터라이징(Rasterizing)이라고 한다. 외곽선은 벡터이지만 글꼴을 출력할 모니터나 프린터는 래스터 장비이므로 비트맵으로 변환해야만 빠르게 출력할 수 있다.

FreeType 라이브러리는 외곽선을 비트맵으로 래스터라이징하는 랜더링 함수를 제공하므로 함수만 호출하면 비트맵을 쉽게 얻을 수 있다. 단순한 출력만을 목적으로 한다면 랜더링으로 생성된 비트맵을 사용하면 되지만 폰트를 좀 더 자유롭게 다루어 보고 싶다면 외곽선 정보를 직접 조작해야 한다. 외곽선 정보는 글리프 슬롯의 outline 멤버에 저장되는데 이 멤버는 FT_Outline 구조체 타입이다.

멤버	설명
n_contours	폐곡선의 개수이다. 글리프 하나는 여러 개의 폐곡선으로 구성된다.
n_points	전체 점의 개수이다.
points	외곽선을 구성하는 점의 배열이다. FT_Vector 타입이며 x, y 멤버를 가진다.
tags	각 점의 특성을 정의하는 배열이다.
contours	폐곡선의 시작과 끝에 대한 정보를 가진다.
flags	외곽선 자체의 특성값이다.

외곽선은 여러 개의 폐곡선(Contour)으로 구성되며 폐곡선은 직선과 곡선으로 구성된다. 글리프를 구성하는 폐곡선의 개수는 글리프마다 다르다. "S" 같은 알파벳은 한번에 그릴 수 있으므로 폐곡선 하나로 표현할 수 있는데 비해 ":" 같은 기호는 떨어진 두 개의 점으로 되어 있으므로 폐곡선도 두 개가 필요하다. "한" 같은 복잡한 글자는 폐곡선은 다섯개이지만 "ㅇ"의 안쪽, 바깥쪽 원이 별개의 도형이라 총 6개의 폐곡선으로 구성된다. 글리프의 폐곡선 개수는 종이에 글자를 쓸 때 펜을 떼어야 하는 회수 + 1와 거의 일치한다.

외곽선을 구성하는 점들은 모두 points 배열에 저장되어 있는데 이 배열 자체에는 폐곡선의 경계 구분이 없다. 단순히 좌표의 집합일 뿐이며 어디서부터 어디까지가 첫번째 폐곡선의 좌표인지는 기록되어 있지 않다. 대신 contours 배열에 각 폐곡선의 끝 첨자가 기록되어 있다. 예를 들어 세 개의 폐곡선이 저장되어 있다면 contours 배열에는 각 폐곡선의 끝 첨자 위치가 기록된다.

첫 번째 폐곡선은 당연히 첨자 0부터 시작하며 그 끝은 contours[0]인 4이다. 다음 폐곡선은 앞 폐곡선의 끝 다음인 contours[0]+1 부터 시작해서 contours[1]까지이다. 이런 식으로 n_contours 개수의 폐곡선을 그리면 전체 글리프가 완성된다. 그럼 이 정보를 읽어 글리프를 그리는 코드를 작성해 보자.

예 제 : DrawOutline

LRESULT CALLBACK WndProc(HWND hWnd,UINT iMessage,WPARAM wParam,LPARAM lParam)

{

HDC hdc;

PAINTSTRUCT ps;

FT_Face face;

unsigned index;

int c,p;

int cs,ce;

FT_Vector pt;

int x,y;

switch (iMessage) {

case WM_CREATE:

hWndMain=hWnd;

return 0;

case WM_PAINT:

hdc=BeginPaint(hWnd, &ps);

FT_New_Face(library,"c:\\windows\\fonts\\batang.ttc",2,&face);

FT_Set_Char_Size(face, 256 * 64, 0,

GetDeviceCaps(hdc,LOGPIXELSX), GetDeviceCaps(hdc,LOGPIXELSY));

index = FT_Get_Char_Index(face,L'한');

FT_Load_Glyph(face,index,FT_LOAD_DEFAULT | FT_LOAD_NO_BITMAP);

for (c=0;c<face->glyph->outline.n_contours;c++) {

// 폐곡선의 시작, 끝 인덱스 찾음

cs=(c==0 ? 0:face->glyph->outline.contours[c-1]+1);

ce=face->glyph->outline.contours[c];

for (p=cs;p<=ce;p++) {

pt=face->glyph->outline.points[p];

x=pt.x >> 6;

y=pt.y >> 6;

if (p==cs) {

MoveToEx(hdc,x,300-y,NULL);

} else {

LineTo(hdc,x,300-y);

}

Sleep(10);

}

// 폐곡선 닫음

pt=face->glyph->outline.points[cs];

x=pt.x >> 6;

y=pt.y >> 6;

LineTo(hdc,x,300-y);

}

FT_Done_Face(face);

EndPaint(hWnd, &ps);

return 0;

case WM_DESTROY:

PostQuitMessage(0);

return 0;

}

return(DefWindowProc(hWnd,iMessage,wParam,lParam));

}

글리프를 로드는 하되 비트맵으로 출력할 것은 아니므로 랜더링은 하지 않았다. 이 상태에서는 글리프 슬롯의 bitmap에는 아무 정보가 없으면 outline에만 외곽선 정보가 조사된다. outline의 점 배열을 순회하면서 하나씩 꺼내 출력하면 글리프 모양 비슷하게 출력할 수 있다.

폐곡선 개수만큼 루프를 돌면서 각 폐곡선의 시작, 끝 첨자를 조사한다. 그리고 조사된 첨자만큼 points 배열에서 좌표를 꺼내 선으로 연결한다. 폐곡선의 첫 점에 대해서는 이동만 하고 두번째 점부터는 선을 그으면 폐곡선을 구성하는 각 점이 순서대로 연결될 것이다. 그리는 순서를 천천히 보기 위해 Sleep을 적당히 넣어 두었다.

폐곡선이란 닫힌 도형이므로 모든 점을 순회한 후 시작점과 끝점을 연결해야 완전한 폐곡선이 된다. 이 과정을 폐곡선 개수만큼 반복하면 글리프의 외곽선이 완성된다. 다음은 "한"자의 외곽선을 그린 것인데 어떤 순서대로 획이 그려지는지 보려면 직접 실행해 봐야 한다. 우리가 일상 생활에서 글자를 쓰는 획순과는 좀 다르게 정의되어 있기도 하다.

폰트 디자이너들이 만들어 놓은 글리프 모양대로 외곽선이 출력되었다. 그러나 이 예제는 어디까지나 이해를 목적으로 대충 작성한 것이라 아직 완벽하지는 않다. 좀 더 정확한 모양을 그리려면 여분의 코드가 더 필요하다.

나.곡선 그리기

앞 예제의 실행 결과를 보면 외곽선이 그럭 저럭 잘 그려진 것 같지만 직전으로만 연결을 하다 보니 각진 부분이 있다. 폰트의 외곽선은 직선과 곡선으로 구성되는데 예제에서는 직선만 사용했기 때문이다. 제대로 그리려면 어디가 곡선이고 어디가 직선인지를 알아야 하는데 이 정보는 tags 배열에 들어 있다.

tags는 points 배열과 같은 크기를 가지며 각 점의 성질을 지정한다. b0(제일 왼쪽 비트)가 0이면 이 값은 곡선의 외부에 있는 점(off)이며 b0가 1이면 곡선의 내부에 있는 점(on)이다. b1은 b0가 0일때만 의미가 있는데 b1이 1이면 3차 베지어 곡선이며 0이면 2차 베지어 곡선이다. 각 점의 on, off 상태에 따라 어떤 곡선이 그려지는지 보자.

먼저 두 개의 연속된 점이 모두 on이면 이 선은 직선이다. 둘 다 선 위에 있으므로 직선일 수밖에 없다. on, off, on 순으로 연속되면 가운데 있는 off점은 선 위에 있지 않은 조절점이라고 볼 수 있으며 이 경우 2차 베지어 곡선이 된다. 조절점은 곡선 위에 있지는 않지만 일종의 중력점으로 작용하여 곡선을 조절점쪽으로 휘어지게 만드는 역할을 한다.

on, off, off, on 순으로 연속되는 경우는 가운데 두 개의 off점이 조절점이다. 이때 off점이 2차인지 3차인지에 따라 결과가 달라진다. 3차 조절점인 경우는 곡선이 두 조절점쪽으로 휘어진다. 2차 조절점인 경우는 두 off점의 중점에 on점이 하나 추가로 더 배치된다. 2차 베지어 곡선이니 3차 베지어 곡선이니 하는 것들은 수학적으로 정의되는 방정식인데 자세한 것은 그래픽 관련 서적을 참조하기 바란다.

좀 복잡해 보이기는 하지만 곡선을 정의하는 규칙이 명확하므로 이 규칙대로 좌표를 연결하여 곡선을 그리기만 하면 된다. 그러나 점들의 태그 속성을 일일이 파악하여 직선, 곡선을 연결해서 그리는 작업은 어렵다기보다는 무척 귀찮은 작업이다. 그래서 FreeType은 외곽선 정보를 해석하여 적당한 때 그리기 함수를 호출하는 곡선 분해 함수를 제공한다.

FT_EXPORT( FT_Error ) FT_Outline_Decompose( FT_Outline* outline, const FT_Outline_Funcs* func_interface, void* user );

첫번째 인수는 그리고자 하는 외곽선이다. 두 번째 인수는 각 점의 속성별로 호출할 콜백 함수의 포인터를 가지는 구조체이다. 함수 포인터 외에 각 점에 곱해지고 더해지는 값도 정의할 수 있다.

typedef struct FT_Outline_Funcs_

{

FT_Outline_MoveToFunc move_to;

FT_Outline_LineToFunc line_to;

FT_Outline_ConicToFunc conic_to;

FT_Outline_CubicToFunc cubic_to;

int shift;

FT_Pos delta;

} FT_Outline_Funcs;

이동, 직선, 2차 베지어, 3차 베지어 곡선을 만날 때마다 호출할 함수를 작성한 후 이 구조체에 대입해 놓으면 적당한 때에 함수를 호출한다. 물론 콜백 함수는 이 구조체에 정의된 원형대로 작성해야 한다. 예를 들어 선을 그리는 함수는 어디까지 선을 그을 것인지 목적지 좌표를 전달받아야 하며 곡선을 그리는 함수는 목적지 좌표뿐만 아니라 조절점의 좌표도 전달받아야 한다. Decompose 함수가 요구하는 원형대로 콜백 함수를 작성해 놓으면 이 함수는 외곽선에서 추출한 좌표를 콜백 함수로 전달하며 콜백 함수는 전달된 인수대로 그리기만 하면 된다.

마지막 인수 user는 콜백 함수로 전달될 사용자 정의 데이터인데 void *이므로 임의의 객체나 핸들을 전달할 수 있다. 각 콜백 함수에서 직선, 곡선을 출력해야 하므로 그리기에 필요한 어떤 값이 전달될 것이다. 예를 들어 DC의 핸들이나 Graphics 객체의 포인터 등이 전달되는데 콜백 함수는 user값을 원래 타입으로 캐스팅해서 사용해야 한다. 다음 예제는 곡선 분해 함수를 사용하여 완전한 외곽선을 그려낸다.

예 제 : DecompOutline

#include FT_OUTLINE_H

....

class DrawOutline

{

#define TOINT(a) ((int)(a >> 6))

public:

static POINT Base;

static int nSleep;

static int PathMoveTo(const FT_Vector *to, void *user)

{

HDC hdc=*(HDC *)user;

MoveToEx(hdc,Base.x + TOINT(to->x),Base.y - TOINT(to->y),NULL);

if (nSleep) Sleep(nSleep);

return 0;

}

static int PathLineTo(const FT_Vector *to, void *user)

{

HDC hdc=*(HDC *)user;

LineTo(hdc,Base.x + TOINT(to->x),Base.y - TOINT(to->y));

if (nSleep) Sleep(nSleep);

return 0;

}

static int PathConicTo(const FT_Vector *control, const FT_Vector *to, void *user)

{

HDC hdc=*(HDC *)user;

POINT pts[3];

pts[0].x=Base.x + TOINT(control->x);

pts[0].y=Base.y - TOINT(control->y);

pts[1].x=Base.x + TOINT(to->x);

pts[1].y=Base.y - TOINT(to->y);

pts[2].x=Base.x + TOINT(to->x);

pts[2].y=Base.y - TOINT(to->y);

PolyBezierTo(hdc,pts,3);

if (nSleep) Sleep(nSleep);

return 0;

}

static int PathCubicTo(const FT_Vector *control1, const FT_Vector *control2,const FT_Vector *to, void *user)

{

HDC hdc=*(HDC *)user;

POINT pts[3];

pts[0].x=Base.x + TOINT(control1->x);

pts[0].y=Base.y - TOINT(control1->y);

pts[1].x=Base.x + TOINT(control2->x);

pts[1].y=Base.y - TOINT(control2->y);

pts[2].x=Base.x + TOINT(to->x);

pts[2].y=Base.y - TOINT(to->y);

PolyBezierTo(hdc,pts,3);

if (nSleep) Sleep(nSleep);

return 0;

}

};

POINT DrawOutline::Base;

int DrawOutline::nSleep=0;

void OnPaint(HDC hdc)

{

FT_Face face;

unsigned index;

FT_New_Face(library,"c:\\windows\\fonts\\batang.ttc",2,&face);

FT_Set_Char_Size(face, 256 * 64, 0,

GetDeviceCaps(hdc,LOGPIXELSX), GetDeviceCaps(hdc,LOGPIXELSY));

index = FT_Get_Char_Index(face,L'한');

FT_Load_Glyph(face,index,FT_LOAD_DEFAULT | FT_LOAD_NO_BITMAP);

// 외곽선을 그린다.

FT_Outline_Funcs outline_funcs = {

DrawOutline::PathMoveTo, DrawOutline::PathLineTo,

DrawOutline::PathConicTo, DrawOutline::PathCubicTo, 0, 0

};

DrawOutline::Base.x=0;

DrawOutline::Base.y=300;

DrawOutline::nSleep=20;

FT_Outline_Decompose(&face->glyph->outline, &outline_funcs, &hdc);

FT_Done_Face(face);

}

LRESULT CALLBACK WndProc(HWND hWnd,UINT iMessage,WPARAM wParam,LPARAM lParam)

{

HDC hdc;

PAINTSTRUCT ps;

switch (iMessage) {

case WM_CREATE:

hWndMain=hWnd;

return 0;

case WM_PAINT:

hdc=BeginPaint(hWnd, &ps);

OnPaint(hdc);

EndPaint(hWnd, &ps);

return 0;

case WM_DESTROY:

PostQuitMessage(0);

return 0;

}

return(DefWindowProc(hWnd,iMessage,wParam,lParam));

}

외곽선 분해 함수는 FT_OUTLINE_H 헤더 파일에 선언되어 있으므로 먼저 이 헤더 파일을 인클루드한다. 각 선분을 그릴 4개의 콜백 함수 외에도 베이스라인과 시간 지연값도 필요하다. 함수와 변수 여러 개가 필요하므로 클래스로 캡슐화했는데 콜백 함수와 원형을 맞추기 위해 멤버 함수는 모두 정적이어야 하며 따라서 정적 함수에서 사용할 멤버 변수도 정적이어야 한다. 사실 전역 변수와 전역 함수로도 충분하기는 하지만 재활용성을 높이기 위해 클래스로 만들었다.

FT_Outline_Decompose 함수는 외곽선을 구성하는 점들을 분석하여 이 점이 곡선인지 직선인지를 판단하고 적당한 콜백 함수를 호출하며 이 함수로 points 배열에서 추출한 좌표값을 전달한다. 그리고 user 인수로는 그리기의 표면이 될 DC 핸들을 전달했다. 각 콜백 함수는 전달받은 인수대로 위치를 옮기고 직선을 그리고 베지어 곡선을 그린다.

각 콜백 함수의 그리기 코드는 지극히 평범한 Win32 그래픽 함수일 뿐이다. user로 전달된 DC 핸들을 먼저 추출하고 MoveToEx나 LineTo를 호출하여 현재 위치를 옮기고 직선을 긋는다. 실행 결과를 천천히 살펴볼 수 있도록 의도적으로 Sleep문도 넣어 두었는데 실제 프로젝트에서는 물론 필요없는 코드이다. 베지어 곡선을 그리는 코드가 좀 길어 보이는데 전달된 인수를 PolyBezier 함수가 요구하는 배열에 대입하는 문장일 뿐이다. 출력 결과를 보자.

앞 예제에 비해 곡선 부분이 부드럽게 그려지므로 제대로 품질이 나온다. 미스 박이 만든 글리프에 저런 모양의 글자가 수학식으로 부호화되어 있으며 FreeType 라이브러리는 이 부호를 해석하여 좌표로 변환해 준다. 우리는 분석된 좌표대로 그리기만 하면 된다. 만약 이 코드가 어렵게 느껴진다면 Win32의 그리기 함수나 C의 함수 포인터에 자신이 없어서일 것이다. 좀 길어 보여서 그렇지 결코 어렵거나 복잡한 코드가 아니다.

참고로 위 예제에서 PathCubicTo 함수는 실제로는 호출되지 않는 함수이다. 왜냐하면 윈도우즈의 기본 폰트인 TrueType은 3차 베지어 곡선을 사용하지 않기 때문이다. 모든 곡선은 2차 베지어 곡선으로 정의되어 있다. 물론 이론적으로 2차 베지어 곡선과 3차 베지어 곡선을 섞어서 사용하는 것도 가능은 하지만 그렇게 만들어진 폰트는 현존하지 않는다.

다.패스로 변환하기

글리프의 외곽선 정보를 곡선으로 바꾸어 그리기에 성공했는데 이런 식으로 외곽선만 그리면 내부를 채우기가 어렵다. 문자를 제대로 출력하려면 획의 안쪽까지 완전히 채워야 한다. 외곽선의 안쪽을 채우는데는 여러 가지 방법이 있지만 패스를 사용하는 것이 가장 빠르고 합리적이다. 일단 패스로 변환해 놓기만 하면 다양한 형태로 변형할 수 있어 응용의 묘미도 있다.

패스는 윈도우즈의 기본 그리기 엔진인 GDI에도 있고 GDI의 상위 버전인 GDI+에도 있으므로 어렵지 않게 사용할 수 있다. GDI의 패스는 여러 가지 면에서 GDI+에 비해 기능이 열악하므로 이번 예제에서는 GDI+의 패스를 사용해 보기로 하자. 당연한 얘기겠지만 이 예제를 제대로 이해하려면 GDI+에 대한 선행 학습이 되어 있어야 한다.

예 제 : FillOutline

#include <gdiplus.h>

using namespace Gdiplus;

#pragma comment(lib, "gdiplus")

class CGdiPlusStarter

{

private:

ULONG_PTR m_gpToken;

public:

bool m_bSuccess;

CGdiPlusStarter() {

GdiplusStartupInput gpsi;

m_bSuccess=(GdiplusStartup(&m_gpToken,&gpsi,NULL) == Ok);

}

~CGdiPlusStarter() {

GdiplusShutdown(m_gpToken);

}

};

CGdiPlusStarter g_gps;

class PathConverter

{

#define TOREAL(a) ((REAL)(a >> 6))

#define TO266(a) ((FT_F26Dot6)(a << 6))

public:

static PointF Current;

static PointF Base;

static int PathMoveTo(const FT_Vector *to, void *user)

{

GraphicsPath *pPath=(GraphicsPath *)user;

pPath->StartFigure();

Current.X = Base.X + TOREAL(to->x);

Current.Y = Base.Y - TOREAL(to->y);

return 0;

}

static int PathLineTo(const FT_Vector *to, void *user)

{

GraphicsPath *pPath=(GraphicsPath *)user;

pPath->AddLine(Current.X, Current.Y, Base.X + TOREAL(to->x), Base.Y - TOREAL(to->y));

Current.X = Base.X + TOREAL(to->x);

Current.Y = Base.Y - TOREAL(to->y);

return 0;

}

static int PathConicTo(const FT_Vector *control, const FT_Vector *to, void *user)

{

GraphicsPath *pPath=(GraphicsPath *)user;

pPath->AddBezier(Current.X, Current.Y,

Base.X + TOREAL(control->x), Base.Y - TOREAL(control->y),

Base.X + TOREAL(to->x), Base.Y - TOREAL(to->y),

Base.X + TOREAL(to->x), Base.Y - TOREAL(to->y));

Current.X = Base.X + TOREAL(to->x);

Current.Y = Base.Y - TOREAL(to->y);

return 0;

}

static int PathCubicTo(const FT_Vector *control1, const FT_Vector *control2,const FT_Vector *to, void *user)

{

GraphicsPath *pPath=(GraphicsPath *)user;

pPath->AddBezier(Current.X, Current.Y,

Base.X + TOREAL(control1->x), Base.Y - TOREAL(control1->y),

Base.X + TOREAL(control2->x), Base.Y - TOREAL(control2->y),

Base.X + TOREAL(to->x), Base.Y - TOREAL(to->y));

Current.X = Base.X + TOREAL(to->x);

Current.Y = Base.Y - TOREAL(to->y);

return 0;

}

};

PointF PathConverter::Current;

PointF PathConverter::Base;

void OnPaint(HDC hdc)

{

FT_Face face;

unsigned index;

FT_New_Face(library,"c:\\windows\\fonts\\batang.ttc",2,&face);

FT_Set_Char_Size(face, 256 * 64, 0,

GetDeviceCaps(hdc,LOGPIXELSX), GetDeviceCaps(hdc,LOGPIXELSY));

index = FT_Get_Char_Index(face,L'한');

FT_Load_Glyph(face,index,FT_LOAD_DEFAULT | FT_LOAD_NO_BITMAP);

Graphics G(hdc);

G.SetSmoothingMode(Gdiplus::SmoothingModeHighQuality);

GraphicsPath Path;

Path.SetFillMode(Gdiplus::FillModeWinding);

// 외곽선을 패스로 변환

FT_Outline_Funcs outline_funcs = {

PathConverter::PathMoveTo, PathConverter::PathLineTo,

PathConverter::PathConicTo, PathConverter::PathCubicTo, 0, 0

};

PathConverter::Base.X=0;

PathConverter::Base.Y=300;

FT_Outline_Decompose(&face->glyph->outline, &outline_funcs, &Path);

Path.CloseFigure();

// 패스 출력

G.FillPath(&SolidBrush(Color(0,0,0)),&Path);

//G.DrawPath(&Pen(Color(0,0,255),5),&Path);

FT_Done_Face(face);

}

LRESULT CALLBACK WndProc(HWND hWnd,UINT iMessage,WPARAM wParam,LPARAM lParam)

{

HDC hdc;

PAINTSTRUCT ps;

switch (iMessage) {

case WM_CREATE:

hWndMain=hWnd;

return 0;

case WM_PAINT:

hdc=BeginPaint(hWnd, &ps);

OnPaint(hdc);

EndPaint(hWnd, &ps);

return 0;

case WM_DESTROY:

PostQuitMessage(0);

return 0;

}

return(DefWindowProc(hWnd,iMessage,wParam,lParam));

}

앞 예제와 기본적인 구조는 거의 같다. 다만 직접 그리는 것이 아니므로 DC의 핸들 대신 GraphicsPath 객체의 포인터를 받아 패스에 직선과 곡선을 누적시킨다는 점이 다르다. 전달된 좌표를 GraphicsPath의 멤버 함수의 인수로 사용하여 패스에 도형을 하나씩 그린다. 패스에 일단 누적시켜 놓고 나중에 패스만 그리면 된다. 정적 멤버 변수로 현재 위치에 해당하는 Current값을 일일이 저장하는 코드가 추가되어 있는데 이는 GDI와 GDI+의 차이에 기인한다.

GDI는 현재 선택된 오브젝트나 현재 위치, 각종 모드 등이 DC에 저장되는데 비해 GDI+는 상태가 없는 라이브러리라 현재 위치를 별도의 변수에 저장해야 한다. GDI의 현재 위치에 해당하는 값이 바로 Current 정적 멤버 변수이다. 패스가 완성된 후 FillPath로 패스의 내부를 채우기만 하면 획의 안쪽까지 완전히 채워진 글자가 출력된다.

Graphics의 그리기 모드를 잘 적용하면 안티 알리아싱도 훌륭하게 지원된다. 일단 패스가 구축되면 펜이나 그라데이션 브러시 등을 적용하여 다양한 변형을 해 볼 수 있다. 다음은 굵기 5의 파란색 펜으로 외곽선을 그린 것이다. 정말 섹시하지 않은가?

GDI 수준에서 일정한 굵기로 이런 예쁜 곡선을 그리기는 무척 어렵다. 패스 내부에 비트맵을 채워 넣거나 반투명한 색으로 채워 이미지 위에 글자를 살짝 얹을 수도 있고 패스를 변형하여 글자를 찌그러뜨릴 수도 있다. 시간 관계상 예제를 만들어 보지는 않겠지만 GDI+의 패스 기능이 워낙 화려하여 조금만 응용해도 무궁 무진한 변형이 가능하다.

이 예제는 Sleep을 주는 코드가 없어 이전의 예제에 비해 속도가 상당히 빠르다. 내부에서 복잡한 계산을 함에도 불구하고 글자가 바로 출력된다. 그러나 운영체제가 제공하는 고수준 함수에 비해서는 여전히 느린데 지금까지 학습해 봐서 알겠지만 페이스의 글자 하나를 읽어 출력하는 과정이 상당히 복잡하기 때문이다. 즉, 글자 하나를 출력하는 데는 원래 이렇게 시간이 오래 걸린다.

그렇다면 운영체제의 함수들은 과연 어떤 트릭을 쓰길레 거의 실시간으로 텍스트가 출력되는 것일까? 사실 운영체제라고 해서 특별히 용빼는 재주가 있는 것은 아니며 위 예제들의 코드를 순서대로 실행해야만 글꼴을 제대로 출력할 수 있다. 실제로 워드 프로세서로 특이한 폰트의 큰 글꼴을 갑자기 출력해 보면 그리는 과정이 보일 정도로 느리다는 것을 확인할 수 있으며 한번쯤은 그런 경험을 해 본 적이 있을 것이다. 메모리까지 부족한 시스템에서는 아예 획을 긋는게 눈에 보일 정도다.

하지만 일상적으로는 이런 현상을 목격하기가 쉽지 않는데 그 비밀은 바로 캐싱에 있다. 한번 출력한 글꼴은 래스터라이징된 결과를 철저히 캐시하여 다음 출력에는 재계산하지 않고 캐싱된 결과를 출력하는 기법을 사용한다. 또한 폰트에 이미 내장된 비트맵 글꼴도 속도 향상에 큰 기여를 하는데 비트맵 글꼴은 캐싱할 필요도 없이 바로 출력할 수 있다. 특히 시스템 글꼴의 경우는 부팅 직후에 모든 글자들이 다 캐싱되어 있다고 보면 틀림없다. 운영체제는 빠른 출력을 위해 엄청난 메모리를 사용하며 이것 저것 준비할 게 많다 보니 부팅 시간이 오래 걸리는 것이다.

물론 운영체제의 최적화된 코드도 속도 향상에 어느 정도 기여를 하겠지만 주된 속도차는 캐싱에서 발생한다. 그렇다면 응용 프로그램도 캐싱을 하면 훨씬 더 빠르게 문자를 출력할 수 있지 않을까? 메모리를 많이 쓰면 속도가 올라가는 것은 디지털 세계의 진리이므로 이는 당연하다. 다만, FreeType 라이브러리의 글리프 슬롯이 정적 저장소이기 때문에 한번에 하나의 글리프만 읽을 수 있다는 점이 문제다. 그래서 FreeType은 글리프 슬롯을 별도의 객체로 백업하는 함수를 제공한다.

FT_EXPORT( FT_Error ) FT_Get_Glyph( FT_GlyphSlot slot, FT_Glyph *aglyph );

이 함수는 페이스 객체의 현재 슬롯을 별도의 FT_Glyph 타입의 변수에 깊은 복사를 한다. 필요한 슬롯의 개수만큼 FT_Slot 배열을 선언하고 글리프를 읽을 때마다 백업을 한 후 다음 출력할 때는 백업해 둔 슬롯을 읽으면 될 것이다. 사본으로 작성된 글리프는 페이스와는 별도의 객체이므로 다 사용한 후 FT_Done_Glyph 함수로 해제해야 한다. 비트맵이나 패스로 변환까지 해 놓으면 속도는 더 극적으로 향상되어 운영체제와 맞짱을 뜰 수도 있다.

개별 글자들의 글리프를 모두 백업해 두려면 엄청난 메모리가 소모될 것이다. 그래서 정밀하고도 섬세한 메모리 관리 기술이 필요한 것이며 백업이라는 용어 대신 캐싱이라는 멋진 이름을 붙여 주는 것이다. 중복되는 문자는 다시 백업할 필요가 없고 폰트에 이미 비트맵이 제공되는 문자도 백업할 필요가 없다. 사용한지 오래된 문자는 메모리를 비워 적당한 수준의 관리도 해야 하며 비트맵도 날포맷으로 저장하지 말고 압축해서 저장하면 훨씬 더 메모리를 절약할 수 있다.

이 강좌에서는 캐싱의 필요성과 대략의 알고리즘만 설명할 뿐 친절한 예제는 제공하지 않는다. 왜냐하면 캐싱 기법은 응용의 영역이지 FreeType 라이브러리 자체에 대한 기법이 아니기 때문이다. 응용 프로그램의 상황과 용도에 따라 적당한 수준의 캐싱 알고리즘을 적용하기 바란다.