지금 여러분의 PC에는 비트맵 그래픽 에디터로 무엇이 설치되어 있는가?
포토샵, 페인트샵, 페인트 닷넷, 심지어 그림판, 비주얼 스튜디오가 자체 제공하는 그래픽 에디터 등등...
이런 것들을 떠올리면서 각 프로그램들이 텍스트를 삽입하는 텍스트 도구가 어떤 형태로 구현되어 있는지 생각해 보시기 바란다.
보통은 텍스트 도구를 실행하면 텍스트를 삽입할 지점 내지 영역을 지정할 수 있고, 그 뒤에는 어지간해서는 텍스트 입력란이 별도의 대화상자나 창을 통해서 뜨게 된다.
그런데 Windows가 기본 제공하는 그림판은 다소 참신하게 설계되어 있다.
텍스트를 입력받는 영역이 그림 내부에 일체형으로 생긴다. 그림 내부에 cursor가 생겨서 텍스트를 곧바로 입력할 수 있으며 심지어 블록까지 잡을 수도 있는데,
일괄적인 단색이 아니라 기존 그림이 그대로 배경에 깔린다. 즉, 텍스트를 입력했다가 지우면 원래 그림이 도로 보존된다는 뜻이다. 별로 깜빡거리는 현상도 없다. 게다가 윈도 95 시절부터 그림판은 이렇게 동작해 오고 있었다. 참고로 페인트 닷넷이나 과거 윈도 3.1 시절의 페인트는 텍스트가 그림에 바로 삽입은 되지만, 블록까지 잡을 수는 없다.
이건 보통일이 아님을 알 수 있다. 아무래도 운영체제의 일반 에디트 컨트롤로는 불가능한 일인 것 같다.
WS_EX_TRANSPARENT라는 스타일이 있고 자체적으로 배경을 지우지 않게 WM_ERASEBKGND 메시지를 서브클래싱한다 해도, 일단 글자에 가려졌던 배경을 깜빡거림 없이 지능적으로 복구하는 일은 해당 컨트롤이 알아서 해 줘야 하기 때문이다.
Spy++로 살펴보면, 텍스트를 입력받는 동안엔 그림 클라이언트 영역 내부에 리치 에디트 컨트롤이 하나 생기긴 한다.
잘은 모르겠지만 얘는 일반 에디트 컨트롤보다 기능이 더 많고 전문적인 만큼, 옵션을 줌으로써 투명하게 동작하는 것에 대비되어 있는 게 아닌가 싶다.
과거의 그림판은 글꼴이나 크기, 색깔을 바꾸면 그게 모든 텍스트에 일괄 적용되었다. 하지만 7의 그림판은 리치 에디트답게 속성을 글자별로 다 따로 줄 수 있다. 뭐, 일괄 적용되던 시절에도 어차피 리치 에디트 기반인 건 동일했으니 그건 단순히 개발 난이도를 낮추기 위해 사용되었던 정책인 것 같다. 그래픽 에디터는 전문적인 텍스트 에디터가 아니니까 말이다.
상황을 좀 더 일반화해서 생각해 보자.
사실, GUI 위젯의 구성요소로는 각종 버튼들, 리스트 박스, 콤보 박스 등 여러 물건들이 있는데,
그 중 기술적으로 가장 만들기 힘든 것은 단연 에디트 컨트롤이다.
키보드 입력을 가장 정교하게 처리해야 하고, 텍스트의 변경으로 인해 텍스트의 전체 레이아웃이 바뀌는 것을 그때 그때 처리해야 하며 그러면서 화면상으로 바뀐 부분만 다시 그리거나 스크롤해 줘야 한다.
에디트 컨트롤을 만들어야 하는데 이런 어렵고 복잡한 내부 처리는 다른 컴포넌트에다 맡기고, 주어진 레이아웃대로 화면에 글자를 출력하는 것만 사용자가 customize할 수는 없을까?
예를 들어서 게임을 만들 때 말이다. 채팅창이 있는데 글자는 그림자 같은 일반적인 리치 에디트 포맷에 없는 특수한 효과가 적용되고, 배경으로는 게임 배경 화면이 알파 채널로 겹쳐진다. 이런 그래픽 출력을 일반 윈도우 DC를 이용해서 할 수는 없는 노릇이다.
이런 경우, 별 수 없이 게임 내부의 GUI 라이브러리를 개발하는 사람이 야메로 에디트 컨트롤을 직접 구현한다.
직접 만들면 세세한 제어가 가능하니 속 편한 경우도 있지만, 외국 시장까지 생각했을 때 아무래도 높은 완성도를 기대하기 어렵다. 중국어· 일본어 IME의 시각 피드백을 출력한다거나 아랍어가 뒤섞인 텍스트를 제대로 처리하는 에디트 컨트롤을 혼자 다 만든다는 건 불가능하며 그럴 필요도 없다.
본인이 개발한 <날개셋> 타자연습에도 기술적으로 완전 구닥다리이긴 하지만 그래도 DirectDraw surface를 만들어서 동작하는 게임이 있다.
내 원래 계획은 입력 중인 글자는 게임 배경에 같이 오버랩되어 표시되는 것이었다.
하지만 그것까지 구현하는 게 어려워서 그냥 화면 하단에 날개셋 에디트 컨트롤을 때려박아 넣는 형태로 프로그램이 만들어졌다. 에디트 컨트롤의 내부 알고리즘이 내린 지시를 custom 출력 매체에다 효과적으로 임베딩하는 방법이 필요하다.
이런 생각을 마소의 개발자가 안 했을 리가 없다.
그래서 Windowless Rich Edit Control이라는 게 있다. 리치 에디트 컨트롤의 내부 알고리즘을 COM 객체 형태로 만든 것이다. 얘를 이용하면 굳이 독립된 윈도우를 만들지 않고도 리치 에디트 컨트롤처럼 동작하는 객체를 손쉽게 구현할 수 있다.
물론, 스펙을 보면 알겠지만 우리 쪽에서 처리해야 할 요청이 한두 개가 아닌 관계로, 마냥 쉽게만 사용할 수 있는 물건은 아닐 수도 있다.
우리는 ITextHost라는 인터페이스를 구현하여 “어디에다 cursor를 만들어라, 무슨 크기를 얻어 와라” 같은 요청를 처리하면 되고, 운영체제의 기본 서비스가 필요하면 ITextServices 인터페이스를 호출하면 된다. 이들 객체는 CreateTextServices 함수를 통해 주고받으면 된다.
본인은 그렇잖아도 문자 입력과 관련된 프로그래밍 경험이 많은 관계로, 운영체제에 이런 API가 있는 것은 진작부터 알고 있었고, 이걸 실전에서 활용도 몇 차례 해 봤다. 단, 정작 그림판은 이런 windowless 오브젝트를 사용한 게 아니라 내부에 특수 처리된 리치 에디트 컨트롤 윈도우를 직접 생성했다는 게 의외로 놀랍다.
text services라는 단어 자체는 이 때부터 있었던 셈이다. 그러니 IME를 대체하는 Windows의 차세대 문자 입력 프로토콜이 text services framework, 즉 TSF라고 명명된 것은 우연이 아니라 하겠다.
Posted by 사무엘
