Text System Overview

OSXDEV

목차 1 Text System Architecture 2 The Cocoa Text System, MLTE, and ATSUI 3 Typographical Features of the Cocoa Text System 3.1 Characters and Glyphs 3.2 Typefaces and Fonts 3.3 Text Lyout 4 Text Fields, Text Views, and the Field Editor 4.1 Text Fields 4.2 Text Views 4.3 The Field Editor 5 The Text System and MVC 6 Common Configurations

[편집] Text System Architecture

어플리케이션에 텍스트를 다루는 기능을 넣는 것은 소프트웨어 디자이너들에게 가장 힘든 일 중의 하나이다. 텍스트를 입력하고, 레이아웃하고, 디스플레이하고 편집, 복사와 붙여넣기와 같은 기능을 제공하는 가장 기본적인 텍스트 핸들링 시스템 조차도 꽤나 복잡하다. 요즘은 개발자와 사용자들은 그런 단순한 기능을 넘어서 다양한 서체와, 문단 스타일, 이미지 삽입, 단어 검사등의 기능들을 포함하는 기초적인 에디터를 요구하고 있다.

코코아 텍스트 시스템은 기본과 그 이상의 텍스트 핸들링 기능을 제공하며, 세계의 모든 언어를 지원하도록 한다던지, 서로 다른 문장 방향이나 사각형이 아닌 텍스트 컨테이너의 레이아웃을 다루고, 커닝과 합자같은 복잡한 타입설정을 가능하게 해 준다. 코코아의 텍스트 시스템은 당신의 어플리케이션의 요구에 필수적인 시스템의 일부만을 공부하고 활용하는 것으로 위의 모든 기능들을 제공하도록 디자인 되었다.

대부분의 개발자에게, NSTextView 클래스의 일반적인 목적의 프로그램 인터페이스는 모두가 공부해야 한다. NSTextView는 텍스트 시스템으로의 사용자 인터페이스를 제공한다. 텍스트에 대해 좀 더 유연하고, 프로그램적인 엑세스가 필요하다면, 스토리지 레이어와 NSTextStorage클래스를 공부해야 할 것이다. 그리고 물론 모든 기능들에 접근하려면, 텍스트 핸들링 시스템을 떠받치는 모든 클래스들을 공부하고 활용해야 할 것이다.

그림 1은 텍스트 시스템의 주요 기능 영역을 보여준다. 사용자 인터페이스 레이어가 제일 위에 있고, 스토리지 레이어가 가장 밑에 있으며, 중간영역에는 키보드 입력을 해독하는 컴포넌트와 디스플레이를 위한 텍스트가 있다.

텍스트 클래스들은 그 풍부함과 인터페이스 복잡성에서 다른 Application Kit의 클래스들을 뛰어넘었다. 디자인의 목표중 하나는 서브클래스 할 필요가 거의 없을 정도로 텍스트 핸들링 기능의 편리한 세트를 제공하는 것이다. NSTextView와 같은 텍스트 오브젝트들은 다음과 같은 일을 한다.

• 사용자가 텍스트를 선택하거나 편집할 수 있는지 여부를 제어
• Font 메뉴와 Font 패널과의 연동으로 텍스트의 폰트와 레이아웃 특징을 제어.
• Ruler를 조정하여 문단의 포맷을 조절할 수 있도록 한다.
• 텍스트와 배경의 컬러를 설정한다.
• 자소 혹은 단어 기반으로 텍스트를 래핑하기
• 텍스트 안에서 그래픽 이미지 표시하기
• RTFD 형식으로 텍스트를 저장하고 불러들이기 (RTFD-Rich Text Format파일. TIFF나 EPS파일 혹은 첨부파일을 가질 수 있다)
• 델리게이트와 같은 다른 오브젝트가 그 프라퍼티를 유동적으로 제어하기
• 어플리케이션 간에 텍스트를 copy-paste하도록 하기
• NSText 오브젝트들 간에 폰트와 포맷 정보를 copy-paste하도록 하기
• 텍스트의 단어 검사를 하기

(인터페이스 빌더와 같은) 그래픽컬한 사용자 인터페이스 제작 툴은 NSTextField, NSForm그리고 NSScrollView 오브젝트와 같이 텍스트 오브젝트로 엑세스하는 몇가지 다른 설정을 제공한다. 그 클래스들은 텍스트 오브젝트를 그들만의 특정 목적을 위해 설정한다. 추가적으로, 동일한 윈도우 안에 있는 모든 NSTextField, NSForm, NSButton 들은, 달리 말해서, 셀을 통해 텍스트 오브젝트로 엑세스하는 모든 오브젝트들은 어플리케이션의 메모리 요구를 줄이기 위해 필드 에디터라고 하는 하나의 텍스트 오브젝트를 공유한다.그러므로, 당신이 직접 텍스트 오브젝트를 만드는 것보다는, 목적에 맞는 해당 클래스를 사용하는 것이 보통 최상의 길이다. 그것들이 당신의 용도에 맞출 수 있도록 유연하지 못하다면, 프로그래밍적으로 텍스트 오브젝트를 만든다.

텍스트 오브젝트는 보통 다른 오브젝트들과 아주 가깝게 작업한다. 그들 중 일부는 - 델리케이트나 임베디드 그래픽 오브젝트- 당신이 프로그래밍 해 넣어야 하는 부분이 있다. 다른 것들은 - 폰트 패널이나, 철자 검사, 자 - 그 서비스를 사용할지 말지만 결정하면 된다.

스크린이나 종이 위의 텍스트 레이아웃을 제어하기 위해서, NSTextStorage 창고를 NSTextView 의 디스플레이로 연결하는 오브젝트를 다루어야 한다. 그 오브젝트들은 NSLayoutManager와 NATextContainer 클래스이다.

NSTextContainer오브젝트는 텍스트가 레이아웃될 수 있는 영역을 정의한다. 전형적으로, 텍스트 컨테이너는 사각형 영역을 정의하지만 NSTextContainer의 서브클래스를 만듦으로서 원형, 오각형, 비정형 도형등 다른 모양을 만들 수 있다. NSTextContainer는 유저 인터페이스 오브젝트가 아니다. 그러므로 이것은 무엇을 표시할 수도 없고 키보드나 마우스로부터 이벤트를 받을 수도 없다. 이것은 단지 텍스트로 채워질 영역을 설명하는 것이다. NSTextContainer는 텍스트를 저장하지도 않는다 그것은 NSTextStorage 오브젝트의 일이다.

레이아웃을 관리하는 오브젝트인 NSLayoutManager 클래스는 다른 텍스트 핸들링 오브젝트들의 동작을 조율한다. NSTextStorage 오브젝트의 데이타를 NSTextView 오브젝트의 디스플레이로 변환하는 과정을 중재한다. NSTextContainer 오브젝트에 의해 정의된 영역내의 텍스트 레이아웃을 살피기도 한다.

[편집] The Cocoa Text System, MLTE, and ATSUI

코코아 텍스트 시스템은 코코아 어플리케이션에서 필요로 하는 모든 텍스트 서비스를 제공하기 위해 디자인된 오브젝트 지향의 프레임웍이다.그 반면에, 카본 어플리케이션은 편집 기능을 제공하는 Multilingual Text Engine(MLTE)와 타이포그라피와 레이아웃 서비스를 제공하는 Apple Services for Unicode Imaging(ATSUI)와 같은 텍스트 지향의 API들을 사용해야 한다.

개발자의 관점에서, 코코아 텍스트 시스템과 ATSUI는 두개의 병행 API이다. 둘다 라인 레이아웃과 character-to-glyph 변환을 하며 텍스트 렌더링을 위해 Quartz Core Graphics 라이브러리를 호출한다. 하나의 프로젝트에서 코코아 텍스트 시스템을 사용하는 개발자는 ATSUI를 사용하려 하지 않을 것이며, 그 반대도 마찬가지이다.

코코아 텍스트 시스템과 MLTE, ATSUI 그리고 Mac OS X개발 환경의 텍스트 관련 컴포넌트들 간의 관계는 그림 1에 있다.

그림 1. Mac OS X에서의 텍스트 핸들링

자세한 정보는 Quartz 2D 도큐멘트의 Core Graphics 렌더링 엔진을 보라.

[편집] Typographical Features of the Cocoa Text System

코코아 텍스트 시스템은 코코아의 모든 눈에 보이는 텍스트들의 처리와 디스플레이를 책임지고 있다. Application Kit 클래스들을 통해 고품질 타이포 그래픽 서비스의 완벽한 세트를 제공한다. 이 문서에서는 텍스트 시스템과 관련된 타이포그래피의 개념을 정의한다.

[편집] Characters and Glyphs

캐릭터는 의미를 전달하는 문자언어의 최소 단위이다. 캐릭터는 알파벳의 자소처럼 언어의 구현시 특정발음에 해당한다; 중국어처럼 하나의 단어를 의미할 수도 있다; 혹은 수학기호처럼 독립적인 개념을 나타낼 수 있다. 어떤 경우라도, 캐릭터는 추상적인 개념이다.

캐릭터가 디스플레이 영역에서 인식가능한 모양으로 나타내어져야 하지만, 그게 동일한 모양은 아니다. 즉, 캐릭터는 다양한 형태로 그려지더라도 여전히 동일한 캐릭터이다. 예를 들어, "대문자 A" 캐릭터는 다른 크기와 다른 굵기로, 기울어지거나 길쭉하게 혹은 획과 같이 다양한 부가적인 형태를 가지며 그려질 수 있다. 이렇게 캐릭터의 다양한 유형의 폼을 glyph라고 한다. 그림 1은 "대문자 A"를 나타내는 서로 다른 glyph를 보여준다.

그림 1. 캐릭터 A에 대한 Glyph들

캐릭터와 glyph는 일대일 대응을 하진 않는다. 어떤 경우 캐릭터는 다중의 glyph에 의해 나타내어진다. "?"의 경우 "e" glyph와 뾰족한 엑센트 glyph인 "'"가 결합된 것이다. 다른 경우, ligatue(합자)처럼 하나의 glyph가 다중의 캐릭터를 나타낼 수도 있다. 그림 2는 각각의 캐릭터와 그들이 결합되었을때의 합자를 보여준다. 합자는 캐릭터가 뒤에 붙는 캐릭터에 따라 다른 glyph를 나타낼 수도 있다는 contextual form을 보여준다.

그림 2. 합자

컴퓨터는 캐릭터를 각각의 캐릭터에 대응하는 인코딩 데이블의 숫자로 저장한다. Mac OS X에서 사용하는 이 인코딩 안은 Unicode d이다. 유니코드 표준은 플렛폼, 프로그램, 사용된 프로그래밍 언어에 상관없이세상의 모든 문자언어를 고유의 번호로 제공한다. 이 보편적인 표준은 서로 다른 컴퓨터 시스템들이 수백가지의 인코딩 방식을 사용하면서 발생하는 충돌을 해결한다. 유니코드는 코코아에서 캐릭터를 저장하는 인코딩을 제공한다. 이는 또한 양방향성 텍스트와 contextual form을 다루기 쉽도록 한다.

Glyph는 glyph코드라 불리는 숫자코드에 의해 표현된다. 문자를 묘사하기 위해 사용되는 glyph는 합성되고 레이아웃 처리될 때 코코아의 레이아웃 매니저 (NSLayoutManager)에 의해 선택된다. 레이아웃 매니저는 어떤 glyph를 사용할지와 디스플레이 혹은 뷰의 어디에 놓을지를 결정한다. 레이아웃 매니저는 사용중인 glyph 코드를 캐쉬하고 캐릭터와 glyph간의 그리고 캐릭터와 뷰 좌표간의 변환을 위한 메소드를 제공한다.(레이아웃 프로세스에 대한 자세한 정보는 "Text Layout"을 보라)

[편집] Typefaces and Fonts

Typeface는 문자언어에서 시각적으로 연관성이 있는 모양을 가진 캐릭터들이다. 예를 들면, Times는 1931년에 런던의 The Times 신문을 위해 스탠리 모리슨이 디자인한 typeface이다. Times안의 모든 자소 형태는 모양에서 연관성이 있으며, 세로 획이나 카운터(자소 몸체의 둥근 부분)등에서 일관된 부분을 가지고 있다. 텍스트의 구역안에 놓았을 때, typeface안의 모양들은 가독성을 높여준다.

TypeStyle 혹은 그냥 style은 시각적으로 구분되는 typeface의 특징이다. 예를 들어, 로만 typestyle은 세리프를 가진 세로획이 가로 줄보다 굵은 것이 특징이다. 이탤릭 typestyle은 자소가 오른쪽으로 기울어졌고 둥글게 생겼으며, 곡선적이며 손으로 쓴 글자모양과 닮았다. typeface는 보통 몇개의 관련 typestyle을 가지고 있다.

Font는 일관된 사이즈와 typeface, typestyle을 가지고 캐릭터를 묘사하는 일련의 glyph들이다. 폰트는 특정 디스플레이 환경에서 사용되도록 의도되었다. 폰트는 일반적인 캐릭터 처럼 합자와 같은 모든 contextual form에 대해 glyph를 가지고 있다.

Font family는 typeface는 같지만 typestyle이 다른 폰트의 그룹이다. 즉, 예를 들면, Times는 폰트 패밀리의 이름이다(타입 페이스의 이름이기도 하다). Times Roman과 Times Italic은 패밀리에 속해있는 각각의 폰트의 이름이다. 그림 3은 Times 폰트 패밀리에 속해있는 몇개의 폰트를 보여준다.

그림3. Times 폰트 패밀리의 폰트.

어떤 경우 타입페이스의 특정 스타일은 다른 폰트이지만 그 폰트가 사용불가인 경우에는, 시스템이 프로그램적으로 패밀리내의 다른 폰트를 변형시킴으로서 그 타입 스타일을 만들어 낸다. 예를 들어, 알고리즘은 같은 패밀리내의 보통 폰트의 라인 두께를 늘임으로서 볼드 타입스타일을 만들어 낼 수 있다. 코코아 텍스트 시스템은 필요하다면 이러한 변형을 대신해 준다. 코코아에서 변경 가능한 스타일 (traits라고도 불린다)은 볼드, 이탤릭, condensed, expanded, narrow, small caps, poster font 그리고 fixed pitch이다.

[편집] Text Lyout

텍스트 레이아웃은 전통적인 활자조판에서 페이지에 해당하는 영역인 디스플레이 장치의 텍스트 뷰 영역내에 glyph들을 배열하는 처리과정을 말한다. glyph들이 서로 연관적으로 놓여지는 방식은 텍스트 디렉션이라고 한다. 라틴어에서 나온 영어나 다른 언어들의 glyph는 공간으로 분리된 단어들이 연이어 위치하는 형식이다. 단어들은 텍스트 뷰의 왼쪽 상단에서 시작하여 텍스트가 뷰의 오른쪽 측면에 닿을때까지 일렬로 놓인다. 그러면 텍스트는 이전 줄의 왼쪽 측면 밑에 새 줄을 시작하고 레이아웃은 이와 같은 방식으로 텍스트 뷰의 바닥까지 진행한다.

다른 언어의 경우, glyph 레이아웃은 상당히 다를 수 있다. 예를들어, 어떤 언어는 glyph를 오른쪽에서 왼쪽으로 레이아웃하고, 수평이 아닌 수직방향으로 진행하는 경우도 있다. 기술적인 저작물에서 영어와 히브리 어처럼 서로 다른 텍스트 방향이 한 줄안에서 섞이는 경우는 일반적이다. 어떤 writing 시스템은 매줄마다 텍스트 방향을 바꿀 수도 있다(boustrophedonic writing이라고 불리는 배열). 어떤 언어는 공백으로 glyph를 단어로 그룹짓지 않는다. 게다가, 어떤 어플리케이션들은 임의의 glyph 배열을 사용한다; 그래픽 레이아웃은 glyph들이 직선이 아닌 경로를 따라 배열되어야 한다.

코코아의 레이아웃 매니져(NSLayoutManager 클래스의 인스턴스)는 베이스라인이라고 불리는 보이지 않는 선을 따라 glyph들을 레이아웃 한다. 로만 텍스트에 있어서, 베이스라인은 수평선으로, 대부분 glyph들의 바닥쪽 면이 이 위에 안착한다. 몇몇 descender를 가지는 "g"같은 문자이나 꼬리를 가진 glyph들은 베이스라인 아래로 뻗어나가고, 커다란 원형을 그리는 "O"같은 문자들은 시각적인 보정을 위해 약간 베이스라인 아래로 내려간다. 다른 writing 시스템들은 glyph들을 베이스라인 아래에 혹은 중간에 위치시키기도 한다. 모든 glyph들은 레이아웃 매니져들이 베이스라인을 따라 바르게 정렬할 때 사용하는 원점을 가지고 있다.

Glyph 디자이너들은 metrics라고 하는 폰트를 측정하기 위한 세트를 제공한다. 폰트의 각 glyph들 주변의 여백을 설명한 것이다. 레이아웃 매니저는 메트릭스를 glyph의 위치를 잡는 데 사용한다. 수평진행 텍스트에서, glyph는 베이스 라인을 따라 다음 glyph의 원점까지의 거리를 측정하는 advance width라는 메트릭을 가지고 있다. 보통 원점과 glyph의 왼쪽 면 사이에는 공간이 있는데, 그것을 left-side bearing이라 한다. 또한 glyph의 오른쪽 면과 진행 너비에 의해 지정된 포인트사이의 공간을 right-side bearing이라 한다. glyph의 수직 크기는 ascent와 descent라는 두개의 메트릭스로 정해진다. 어센트는 베이스라인 위의 원점에서 폰트의 가장 높은 glyph의 위쪽 면까지의 거리이다. 디센트는 베이스라인을 기준으로 폰트의 아래쪽 가장 깊은 디센더까지의 거리이다. glyph의 보이는 부분을 감싸고 있는 사각형을 bounding rectangle혹은 bounding box라 한다. 그림 4는 메트릭스들과 수직 glyph 위치를 잡기위한 유사한 개념을 설명한다.

그림 4. Glyph 메트릭스

디폴트로, 타입세터는 진행방향의 너비만큼 표준 glyph간 간격을 만들어 내면서 나란히 glyph들을 배치한다. 그러나, 결합되는 텍스트에 따라 두 glyph사이의 간격을 좁히거나 넓혀주는 kerning이 있어야 더 읽기가 쉽다. kerning의 일반적인 예는 그림 5와 같이 대문자W와 대문자 A사이에서 일어난다. 타입 디자이너들은 폰트의 메트릭스를 디자인 할때 kerning정보를 포함시킨다. 코코아 텍스트 시스템은 선택된 텍스트의 kerning을 끄거나, 폰트의 디폴트 설정값을 사용하거나, kerning을 조이고 늘이는 방법을 제공한다.

그림 5 Kerning

타입 시스템은 보통 폰트 매트릭스를 points라는 단위로 측정한다. 포인트는 Mac OS X가 인치당 72개를 가지는 단위이다. 폰트의 어센트와 디센트 거리를 더하는 것은 폰트의 포인트 사이즈이다.

타입세팅중 라인간의 공간을 더하는 것을 leading이라 한다. 전통적인 금속 활자 페이지 레이아웃에서 한 행의 리드가 사용되었다. (리딩은 라인 갭이라고도 불린다) 어센트와 디센트를 더한 것에 리딩을 더한 것을 폰트의 line height라고 한다.

타입 디자인의 타이포그래픽적인 개념은 좀 난해하지만, 컴퓨터나 타이프라이터에서 문서를 만드는 대부분의 사람들은 페이지의 텍스트 레이아웃은 친숙한 것이다. 예를 들어, 마진은 페이지의 모서리와 레이아웃 엔진이 glyph를 위치시키는 텍스트 영역사이의 흰 공간이다. Alignment는 마진과 관련해서 텍스트라인이 자리잡는 것을 설명한다 예를 들어, 수평 방향의 텍스트는 그림 6에서처럼 좌,우, 중간 정렬을 할 수 있다.

그림 6. 마진과 연관된 정렬

텍스트의 라인들은 justified 될 수도 있다; 그림 7처럼 수평적인 텍스트가 좌우 마진 모두에 정렬되는 것이다.

그림 7. Justified text

glyph의 스트링으로부터 라인을 만들어내려면, 레이아웃 엔진은 한 줄이 끝나고 다른 줄이 시작되는 지점을 찾아 line breaking을 수행해야 한다. 코코아 텍스트 시스템에서, 단어 혹은 glyph 경계 기반의 라인 브레이킹을 설정할 수 있다. 로만 텍스트에서, glyph 사이로 분리된 단어는 브레이크포인트에 하이픈이 필요하다. 텍스트 스트림이 라인으로 분리된 후, 필요하다면 시스템이 alignment와 justification을 수행한다.

[편집] Text Fields, Text Views, and the Field Editor

텍스트 필드, 텍스트 뷰, 그리고 필드 에디터는 시스템과 사용자간의 인터액션에서 충추적인 역할을 하므로 코코아 텍스트 시스템에서 중요한 오브젝트들이다. 텍스트의 입력과 수정, 그리고 디스플레이를 제공한다. 당신의 어플리케이션이 어떤 형식으로든 사용자가 입력한 텍스트를 다뤄야 한다면, 이 오브젝트들을 이해해야 할 것이다.

[편집] Text Fields

텍스트 필드는 NSTextField 클래스로부터 인스턴스화 된 유저 인터페이스 컨트롤 오브젝트이다. 그림 1은 텍스트 필드를 보여준다. 텍스트 필드는 적은 양의 텍스트, 일반적으로 한줄짜리 텍스트를 디스플레이 한다. 텍스트 필드는 또한 검색 매개변수 같은 사용자가 텍스트 응답을 넣을 수 있는 공간을 제공 해 준다. 다른 모든 컨트롤들 처럼, 텍스트 필드는 타겟과 액션을 가지고 있다. 디폴트로, 텍스트 필드는 수정이 끝났을 때 - 사용자가 Return을 누르거나 다른 컨트롤로 포커스를 넘겼을 때 - 액션 메세지를 날린다. 폰트와 텍스트 색상, 배경 컬러 등 텍스트 필드의 모양과 레이아웃을 컨트롤 할 수 있으며, 텍스트가 수정 가능한지 읽기전용인지, 선택가능한지 아닌지, 텍스트가 텍스트 필드의 가시영역을 넘어설 때 랩 할지 스크롤 할지를 결정한다.

패스워드 입력에서 안전한 텍스트를 만들려면, NSTextField의 서브클래스인 NSSecureTextFiled를 사용한다. 씨큐어 텍스트 필드는 사용자가 입력하는 문자를 불렛으로 디스플레이 하고 복사나 붙이기를 허용하지 않는다. 필드의 값을 stringValue메소드를 통해 당신은 얻을 수 있지만, 사용자는 그 값을 엑세스 할 수 없다.

텍스트 필드를 인스턴스화 하는 일반적인 방법은 인터페이스빌더에 있는 Cocoa-Views에서 NSTextField 오브젝트를 드래그하여 당신의 어플리케이션 유저 인터페이스의 윈도우로 위치시키는 것이다. 그 후, 씨큐어 텍스트 필드가 필요하다면 Info 윈도우를 열고 Custom Class 팬을 선택해서, NSSecureTextField를 선택하면 된다.

[편집] Text Views

텍스트 뷰는 NSTextView 클래스로부터 인스턴스화 된 사용자 인터페이스 오브젝트이다. 그림 2는 텍스트 뷰를 보여준다. 텍스트 뷰는 전형적으로 여러줄의 텍스트가 문장안에 모든 복잡한 타입세팅을 가지고 레이아웃되는 것을 디스플레이 한다. 텍스트 뷰는 코코아 텍스트 편집 시스템의 주요 유저인터페이스이다. 텍스트 입력과 수정을 다루는 사용자 이벤트를 제공하며, 영어가 아닌 모든 서체들을 임의의 컬러와 스타일 등의 어트리뷰트를 다룰 수 있도록 한다.

그림 2. 텍스트 뷰

코코아 텍스트 시스템은 텍스트 스토리지, 레이아웃, 폰트와 어트리뷰터 수정, 철자검사, 언두와 리두, 카피 앤 페이스트, 드래그 앤 드랍, 파일로의 저장외의 다양한 기반 기능들로 텍스트 뷰를 지원한다. NSTextView는 역사적인 이유로 분리된 NSText의 서브클래스이다. NSTextView의 많은 메소드들을 NSText에서 구현하고 있다고 해도, NSText를 인스턴스화 하면 안된다. NSTextView 오브젝트를 NSWindow오브젝트 안에 넣을 때에만, 코코아 텍스트 시스템에 의해 "공짜로" 제공되는 막강한 텍스트 에디터의 능력을 발휘할 수 있다.

[편집] The Field Editor

필드에디터는 텍스트 필드를 포함한, 윈도우의 모든 컨트롤들이 공유하는 하나의 NStextView 오브젝트이다. 이 텍스트 뷰 오브젝트는 현재 액티브인 텍스트 필드에 입력과 편집 서비스를 제공하기 위해 그 자신을 뷰 계층안에 넣는다. 사용자가 포커스를 텍스트 필드로 이동하면, 필드 에디터가 키스트록 이벤트를 처리하고 그 필드를 위한 디스플레이를 해 준다. 필드 에디터는 현재 텍스트 필드를 그 자신의델리게이트로 설정하고, 그 텍스트 필드가 자신의 컨텐츠 수정을 가능하게 한다. 포커스가 다른 텍스트 필드로 옮겨지면, 필드 에디터는 그 필드로 다시 갖다 붙는다. 그림 3은 텍스트 필드가 편집중일때 필드 에디터의 양도를 나타낸다.

그림 3. 필드에디터

윈도우안에서 한번에 하나의 텍스트 필드만이 활성화 되기 때문에, 시스템은 윈도우당 하나의 NSTextView를 필드 에디터로 준비한다. 다른 역할도 있지만, 필드 에디터는 선택을 유지하는 일도 한다. 그러므로ㅡ 수정되지 않은 텍스트 필드는 선택영역도 가지지 않는다.(그러나 개발자가 하나 이상의 필드 에디터를 가지도록 커스텀 필드 에디터를 만들수는 있다.)

[편집] The Text System and MVC

코코아의 텍스트 시스템의 아키텍쳐는 사용 편의성과 유연성을 개선시키기 위해모듈화,계층화 되어있다, 모듈화 디자인은 모델-뷰-컨트롤러 파라다임(스몰토크-80으로부터 비롯된)을 반영한다. 데이타, 데이타의 시각적인 표현, 그리고 그 둘을 연결시켜주는 로직 은 서로 분리된 오브젝트로 되어있는 디자인 파라다임이다. 텍스트 시스템의 경우, NSTextStorage가 모델의 텍스트 데이타를 가지고, NSTextContainer가 레이아웃 영역의 지형을 모델하며, NSTextView가 뷰를 제공한다. 그리고 NSLayoutManager가 컨트롤러로서 데이타와 그 구현에 알맞게 스크린에 나타나도록 중재를 담당한다.

책임을 팩토링 하면 각각의 컴포넌트들은 서로간에 덜 의존적으로 되어 전체 시스템의 재 디자인 없이 개별 컴포넌트를 보다 나은 버전으로 대치하는 게 쉬워진다. 텍스트 처리 컴포넌트의 독립성을 보여주기 위해, 텍스트 시스템의 다른 서브셋을 사용할 경우를 생각해 보자.

? NSTextStorage 오브젝트만 사용한다면, 텍스트를 특정 캐릭터, 스트링, 문단 스타일등으로 검색할 수 있다. ? NSTextStorage 오브젝트만 사용한다면, 프로그래밍적으로 디스플레이를 위한 레이아웃을 고려하지 않는다면 텍스트 작업을 수행할 수 있다. ? NSTextView 오브젝트를 제외한 모든 컴포넌트를 사용한다면 레이아웃 정보, 라인 브레이크가 어디서 일어나는지 결정하고, 페이지 수 등을 계산할 수 있다.

텍스트 시스템의 계층화는 일반적인 텍스트 처리 업무를 수행하기 위해 당신이 배워야 할 양을 줄여준다. 사실, 많은 어플리케이션들은 NSTextView 클래스 API를 통해서만 텍스트 시스템과 인터랙트 한다.

[편집] Common Configurations

다음 도형들은 서로다른 텍스트 처리 목표를 위해 네가지 주요 텍스트 시스템 클래스 (NSTextStorage, NSLayoutManager, NSTextContainer 그리고 NSTextView)의 오브젝트를 어떻게 설정해야 하는가에 대한 정리를 해 준다.

하나의 텍스트 플로우를 표시하려면 오브젝트들을 그림 1과 같이 정리한다.

그림 1. 하나의 텍스트 플로우를 위한 오브젝트 정리.

NSTextView는 glyph를 디스플레이하는 뷰를 제공하고, NSTextContainer 오브젝트는 glyph가 레이아웃될 뷰 안의 영역을 지정한다. 일반적으로 이 설정에서, NStextContainer의 수직면적은 컨테이너가 어떤 양의 텍스트라도 처리할 수 있도록 엄청나게 큰 값으로 선언된다. 그 반면에, NSTextView는 NSText에 의해 제공되는 setVerticallyResizable:메소드를 이용해 텍스트 주변을 감쌀정도의 크기로 그 자신을 설정하며, 최대 높이를 NStextContainer의 높이와 같게 한다. 그러면, NSScrollView에 임베드 된 NSTextView를 이용해 사용자는 텍스트의 어느 부분이라도 볼 수 있도록 스크롤 할 수 있다.

NSTextContainer의 영역이 NSTextView의 바운즈로 삽입되었다면, 텍스트 주위로 여백이 보일 것이다. NSLayoutManager 오브젝트와 여기에 그려져 있지 않은 오브젝트들은, NSTextStroage의 데이타로부터 glyph를 만들어 내고 NStextContainer에 의해 정의된 영역안으로 레이아웃 시키기 위해 함께 할 것이다.

이 설정은 딱 한 쌍의 NSTextContainer-NSTextView에만 적용가능한 것이다. 이런 어레인지에서, 텍스트 플로우는 NSTextContaier에 의해 정의된 영역 내에서 흐름을 방해받지 않는다. 이 어레인지에서는 페이지 구분, 단 레이아웃 그리고 그 이상의 복잡한 레이아웃은 불가능하다.

다중의 NSTextContainer-NSTextView 쌍을 사용하면 좀 더 복잡한 어레인지가 가능하다. 예를 들면, 페이지 구분을 위해서는, 그림 2와 같은 설정을 해야 한다.

그림 2. 페이지 구분된 텍스트를 위한 텍스트 오브젝트 설정.

각각의 NSTextContainer-NSTextView 쌍은 도큐멘트의 페이지에 해당한다. 위 도형에서 회색 사각형은 당신의 어플리케이션이 NSTextView의 배경으로 제공하는 커스텀 뷰 오브젝트를 나타낸다. 이 커스텀 뷰는 NSScrollView안에 임베드 되어 사용자가 도큐멘트의 페이지들을 스크롤 할 수 있게 한다.

단 편집 도큐멘트는 그림 3과 같은 설정을 사용한다.

하나의 페이지마다 대응되는 NSTextView-NSTextContainer쌍을 가지는 게 아니라, 이제 한 페이지 마다 두개의 쌍을 가진다. 각각의 NSTextContainer-NSTextView는 도큐멘트의 한 부분을 제어한다. 텍스트가 디스플레이 될때, glyph들이 먼저 뷰의 왼쪽 위에 레이아웃된다. 뷰에 더이상의 공간이 없으면, NSLayoutManager가 델리게이트에게 그 컨테이너가 다 채워졌음을 알린다. 델리게이트는 레이아웃되어야 할 텍스트가 더 남아있는 지를 체크할 수 있으며 다른 하나의 NSTextContainer와 NSTextView를 더할 수 있다. NSLayoutManager는 다음 컨테이너에 텍스트를 레이아웃 할 수 있도록 진행하고, 다 채워졌으면 델리게이트에게 통지하는 작업을 반복한다. 여기에도 커스텀 뷰(회색으로 묘사된 곳)가 텍스트 컬럼들을 위한 캔버스를 제공한다.

다중의 NSTextContainer-NSTextView쌍만을 가질 수 있는 것이 아니라, 하나의 NSTextStorage에 대해 다중의 NSLayoutManager를 가질 수도 있다. 그림 4는 다중의 레이아웃 매니저를 가지는 가장 단순한 어레인지를 보여준다.

그림 4. 동일 텍스트에 대한 다중 뷰의 텍스트 오브젝트 설정.

이 어레인지의 효과는 동일 텍스트에 대해 다중의 뷰를 제공하는 데 있다. 사용자가 위쪽 뷰의 텍스트를 변경한다면, 변동사항은 아래쪽 뷰에 즉각 반영된다.(변경사항이 아래쪽 뷰의 바운드 안에 있다고 가정)

마지막으로, 텍스트가 임베드된 그래픽 주위를 싸고 도는 것 철머 복잡한 페이지 레이아웃이 요구되는 경우에는 NSTextContainer의 고유 서브클래스를 사용하는 설정을 이용하여 해결 가능하다. 이 서브클래스는 그래픽 이미지를 수용하기 위한 영역을 정의하며 그림 5와 같은 오브젝트 설정을 사용한다.

번역자	사용자:LingoStar
원본문서링크	http://developer.apple.com/documentation/Cocoa/Conceptual/TextArchitecture/TextArchitecture.html (Last Updated - ')

본 문서는 Cocoa Study Group의 발표자료입니다.