TLF 를 향한 여정의 끝
TLF 최초의 프리뷰 버전부터 사용을 했었으니 TLF 만 거의 1년을 팠던 것 같습니다.
이놈의 TLF 때문에 adobe open source 사이트에서 TLF 소스를 까보면서 문제를 해결하기 위해 노력했었고, 소스가 공개되어 있지 않은 녀석은 디컴파일 까지 해가면서 문제를 해결하기 위해 노력했었죠.
http://cafe.naver.com/flashactionscript/43762
http://cafe.naver.com/flashactionscript/44397
http://cafe.naver.com/flashactionscript/44544
http://cafe.naver.com/flashactionscript/50213
http://cafe.naver.com/flashactionscript/50226
http://cafe.naver.com/flashactionscript/52161
http://cafe.naver.com/flashactionscript/52623
http://cafe.naver.com/flashactionscript/52836
http://cafe.naver.com/flashactionscript/52856
http://cafe.naver.com/flashactionscript/53256
http://cafe.naver.com/flashactionscript/53478
대충 FTE, TLF 에 대해 썼던 글만 해도 이정도군요...
일단 간단히 결론만 이야기 하자면, 저와 TLF 는 "우리 이제 그만 헤어져~" 상태가 되어버렸습니다. TLFTextField 의 에러도 에러지만, 거의 호러에 가까운 스크롤 시의 속도 저하와 입력텍스트 상황에서 고속 입력의 경우 입력시키는 글자가 누락되어 버리는 등의 현상들은 도저히 감당히 되지 않는거죠...
일단 몇가지 안내를 하자면
1 . 스크롤 되어야 하는 텍스트에 절대로 TLF 를 사용하지 마십시오.
지옥에 가까운 스크롤 속도의 저하를 보게 될 것입니다. TLF 텍스트 스크롤의 리소스를 찍어보면 그 원인을 알 수 있는데 스크롤이 조금이라도 움직일때마다 모든 글자들이 addChild 와 removeChild 를 미친듯이 반복하게 됩니다.
TextField 가 스크롤바를 따라 자연스럽게 움직이는 모습을 보여준다면, TLF 를 통한 Text 의 스크롤에서는 의도치 않은 트위닝 효과를 보게 될 것입니다...
2 . 입력텍스트에 TLF 를 사용하지 마십시오. (특히나 embed 된 font 를 통해서는 더더욱...)
어지간히 가벼운 입력일 경우 대충 돌아가지만 부하가 일어나기 시작하는 순간 입력중이던 글자들이 드롭되는 채로 입력되는 모습을 볼 수 있을 것입니다.
3 . 쉽게 이야기해서 위의 두가지 상황 덕분에 여러분은 TLF Markup 을 사용하는 것을 포기하는 것이 좋습니다.
TLF 로의 변화에서 가장 우리를 기쁘게 했던것이, Flash Text 도 드디어 멀쩡한 형태의 Markup 기준이 생겼다는 것이었을텐데... 스크롤과 입력텍스트 에서 일어나는 과부하 문제 덕분에 여러분은 이 Markup 에 대한 기대를 버리는 것이 좋습니다.
4 . 스크롤 되어야 하는 장문의 글과 입력텍스트는 embed font 를 사용하지 않는 TextField 를 통해 처리하십시오.
윈도우와 비 윈도우 간의 포맷표현이 문제가 되는데 이 문제는 아래와 같이 해결하십시오.
var format : TextFormat = new TextFormat();
format.font = /Windows/g.test(Capabilities.os) ? "돋움" : "Verdana";
위의 코드는 windows 기반의 OS 에서는 돋움을 표현하고, 그 외의 경우에는 sans serif 폰트를 지정하는 Verdana 를 지정하게 됩니다. (Arial 은 맥에서 한글입력시 serif font 로 대체되게 됩니다. Verdana 를 사용하십시오.)
좀 더 세분화 시키면 Windows 의 버전을 체크해서 xp 이전까지는 "돋움" 으로 하고, Vista, 7 이후에서는 "맑은 고딕" 을 사용할 수 도 있습니다. 그리고, 좀 더 세분화해서 들어가면 Font.enumerateFonts(true) 를 통해서 현재 디바이스 상에 설치된 폰트들을 읽어내고, 그 중, 여러분이 의도하는 폰트들을 지정할 수도 있습니다.
TLF 의 FontFamily 기능은 편리하지만, 위와 같이 대체할 수도 있습니다.
그리고, TextField 에서 embed font 를 통한 입력텍스트 표현은 최근 저 자신이 입력지연 및 입력이 날아가는 문제를 겪었습니다. (가장 최신의 플레이어에서...) 입력텍스트에 embed font 를 사용하는 것은 지양하십시오.
5 . 하지만, StringTextLineFactory 와 같은 경우는 사용을 권장합니다.
TLF 의 여러가지 성능문제는 대체적인 경우 반복적인 TextLine 의 재생성과 반복적인 addChild, removeChild 의 반복에서
일어나는 것으로 보여집니다. 하지만, StringTextLineFactory 와 같은 경우는 위에서 이야기한 반복이 없습니다.
그리고, 아주 가벼운 텍스트의 표현에 있어서는 TextField 보다 빠른 퍼포먼스를 보여줍니다.
다만, StringTextLineFactory 와 같은 Factory 류의 생성방식은 상호작용 (selection, input, link) 등의 기능을 모두 사용할 수 없는 단순한 디스플레이 용도로 제한이 됩니다.
하지만, 단순한 디스플레이 용도로 사용하더라도 TruncationOption 이나 Vertical Align, 보다 적은 용량의 embed font 와 같은 TLF 의 장점들을 활용하기엔 StringTextLineFactory 도 충분한 역할을 할 수 있을 것입니다.
6 . 결과적으로 이야기하는 것은...
스타일링 된 텍스트의 표현엔 "StringTextLineFactory" 를 사용하고 (이것은 fla 를 사용하는 이들에겐 상관없는 이야기임... 애초에 StaticTextField 는 Text 가 아니라 그림이니깐...), 입력과 스크롤, 셀렉션 등의 상호작용을 요구하는 기능들에는 embed font 를 사용하지 않는 TextField 를 사용하십시오.
물론... 느린것을 보았던 몇달 전의 저와같이 "뭔가 방법이 있겠지~" 라고 생각하면서 해결방법을 찾느라고 고생할 몇몇 사람들이 있긴 하겠지만... 그리고, 제가 이야기한 TLF 의 부정적인 부분들을 해결할 방법을 찾아낼 수 있는 분들도 있을지 모르겠지만...
(어쩌면 지금까지 이야기했던 면면들은 제 실력이 부족해서 제대로 활용을 못했던 것일지도 모르죠...)
일단, TLF 에 상당한 시간을 투자한 저로서는 StringTextLineFactory 와 같은 디스플레이용의 텍스트 표현을 제외한 영역에서의 TLF 의 사용을 지양하라는 말을 하고 싶습니다.
상당히 오랜시간을 투자했는데도 불구하고 애초에 잘못 만들어진 녀석이라는 것 이외엔 어떤 해결방법도 찾지 못했습니다.
어쨌든... TLF 와는 가끔 카페에서 만나 StringTextLineFactory 에 대한 이야기나 나누는 좋은 친구로 돌아가려 합니다. "우리 이제 그만 헤어지자..."
올드 미디어에 대한 디지털화
아이패드를 기점으로 해서 미친듯이 디지털 페이퍼 역할을 할 디바이스들이 쏟아져 나올 태세인데, 과연 그 디지털 페이퍼화의 중요한 대상이 될 올드미디어 시장에 어떻게 접근을 할 것인가? 라는 의문은 여전하다.
당분간의 시장은 단순히 기존 올드미디어에 대해 "종이를 대신하는 정도" 로만 쓰일 것이다.
나 자신이 만화를 그렸기 때문에 알 수 있는 일이지만, 기존의 올드미디어의 핵심을 담당하는 40대 작가들은 디지털 세대가 아니기 때문에, 현재 10대에서 30대 까지의 디지털 네이티브 세대들이 생각하는 것과는 틀리게 그 이전 작업이 상당히 느릴 것이다. 어쩌면... 아예 이전을 하지 못할 수도 있고...
수익을 발생시키는 중요한 기점이 될 "디바이스의 능력을 충분히 활용해서 재미를 만들어내는 작업방식의 변화" 와 "기존의 올드미디어가 가진 수익성의 빈약함" 은 돈이 되지 않음으로서 디지털을 구성하는 젊은 개발자들이 쉽사리 접근하는데 어려움을 만들어낼 수 있을듯 싶다.
말 그대로 돈이 되는 핵심 작가진들은 개발자의 접근이 많이 필요할 작업을 하지 않을테고, 젊은 작가진들은 개발자가 수익을 나누어 먹기엔 상당히 빈약한 수익성을 가지기에 어려움이 있다...
이 시장이 과연 어떻게 돌아갈 것인가? 라는데 약간의 의문이 생기고 있다. 이 시장의 승리자들에 개발자 등을 비롯한 디지털을 만들어내는 사람들이 나눠먹을 시장이 있을것인가? 라는데 약간의 회의가 들기도 하고... 아마, 이 시장이 의미하는 것은 거대한 유통 플랫폼을 가진 기업들의 포지셔닝 전쟁이 될 가능성이 높지 않을까 싶다. 추가적인 수익이 발생한다면 유통업자와 작가진의 수익분배가 될 가능성이 높다.
생각하는 것처럼 아이패드와 같은 디지털 페이퍼 디바이스들이 포화되어 수익성이 악화되고 있는 웹, 어플리케이션 시장의 대안이 되지는 않을 것 같다는 생각이 든다.
Text Layout Framework 간단한 안내
HTML 과 Flash 로 동시에 파싱되는 위키 언어 만든답시고 삽질 하고, 컴포넌트 만든다고 삽질하고 하다보니 어느새 TLF 도 적당히 손에 익어가는 중입니다.
자세한 내용들을 쓰기엔 내용이 너무 방대하기 때문에 나중에 시간이 남으면 써보기로 하고... 작업 동안 경험했던 간단한 팁들을 안내해볼까 합니다.
1 . Font, Embed Font 의 표현
매우 필요했지만, 한글 폰트 자체의 용량 덕분에 쓰는 것이 주저되었던 Embed Font 의 사용환경이 TLF 에 들어서는 매우 좋아진 편입니다.
일단, Embed Font 의 용량자체가 상당히 줄었기 때문에 (이전에 약 7MB 짜리 폰트가 TLF 에서는 2MB 정도로 압축가능 하기 때문에) 독립적인 swf 로 분리해서 사이트 전체적으로 런타임 공유를 통해 사용한다면 크게 부담되지 않는 수준입니다.
다만, 여러개의 폰트들을 그룹으로 지정해서 1순위 폰트에 필드가 없을 경우, 다음 순위의 폰트에서 글자를 찾는 fontFamily 의 존재에도 불구하고 fontLookup 의 일방성 덕분인지 embedFont 에 없는 한자나 특수문자의 표현에는 무리가 있는 편이네요... embed font 에 없는 필드를 device font 로 대체할 수도 있지 않을까 싶긴 한데... 아직 방법은 찾지 못했습니다. (아니면, 테스트에 사용한 나눔고딕에 한자 필드가 아예 없는게 아니라, 공백으로 넣어뒀을 가능성도 있겠군요...)
2 . ITextLayoutFormat, TextLayoutFormat
TLF 에서 사용하는 TextLyaoutFormat 은 크게 paragraph (문단) 의 모양을 조절하는 기능과 font 의 모양을 조절하는 기능 (FTE 에서 FontDescription) 과 글의 모양을 조절하는 기능 (FTE 에서 ElementFormat) 과 그 외, 몇가지 추가적인 기능들이 짬뽕되어 있는 포맷 형식 입니다.
이전에 사용하던 TextFormat 보다는 상당히 디테일한 지원을 해줍니다. 딱히 정리해서 설명하긴 어렵고, TLF 를 사용할때 모든 모양에 대한 조절을 원한다면 이 flashx.textLayout.formats.ITextLayoutFormat 을 살펴보면 됩니다.
다만, 링크에 대한 서식설정은 FlowElement 에 존재하는 linkNormalFormat, linkHoverFormat, linkActiveFormat 을 사용해야 합니다.
3 . 마법의 InlineGraphicsElement
TextFlow 상에 여러 그래픽스 오브젝트를 넣는데는 InlineGraphicsElement 가 사용되어질 수 있습니다. 이게 단순히 그림만을 지원하는 것이 아니기 때문에 원한다면 DisplayObject 를 상속받은 모든 그래픽스 오브젝트들을 TextFlow 상에 집어넣을 수 있다는 이야기가 됩니다.
제 경우에는 TLF 에 없는 html 의 <hr> 기능이나 <ol>, <ul> 등의 기능을 이 InlineGraphicsElement 를 통해 구현시켰죠. 원한다면 <table> 과 같은 고급 서식 기능을 만드는 것도 불가능하지 않다는 이야기가 됩니다. 그리고, <video> 기능을 문서 흐름속에 포함시킬 수도 있다는 이야기가 되겠죠...
InlineGraphicsElement.source 는 크게 세가지 정도를 줄 수 있는데, "image.png" 와 같은 String 형태의 uri 와 DisplayObject 로 인스턴스가 생성되는 class, 마지막으로 아싸리 DisplayObject 자체를 집어넣을 수 있습니다.
이 기능은 아직 저차원적인 수준의 지원만을 해주는 TLF 를 보다 강력한 문서표현이 가능하도록 확장시킬 수 있는 기반이 되어줍니다. 사용하기에 따라서 여러가지 것을 만들 수 있을 것 같네요.
이미지 uri 의 경우, ContainerController 에 문서 구현을 시켜주면 자동으로 로드처리를 해주는데 이때, StatusChangeEvent.INLINE_GRAPHIC_STATUS_CHANGE 이벤트를 감지해서 container update 를 시켜줘야 합니다.
그리고, InlineGraphicElement 에는 좀 특이한 버그(인지 아닌건지 잘 모를 에러)가 있는데, InlineGraphicElement 중에서 source 가 uri 로 지정된 녀석이 하나라도 있으면 Selection 시에 문제가 없는데, 아예 자체적으로 생성된 DisplayObject 나 Class 로만 source 가 구성된 녀석들만 있으면 Selelction focus 가 들어가는 순간 모든 그래픽스들이 removeChild 되어서 사라져버립니다... (ㅡ ㄴ ㅡ;;;) 이건 버그인건지 뭔지 잘 모르겠는데... 그런 문제들이 지속적으로 발생한다면 더미로 uri 로드를 하는 녀석을 하나 박아넣으면 해결이 됩니다.
4 . TLFTextField, ContainerController, TextLineFactory 의 선택
TLF 의 텍스트 표현에는 크게 세가지 정도의 선택이 있습니다.
일단, Interaction 이 전혀 되지 않는 순수하게 그림을 그리는 용도로 사용할 수 있는 TextLineFactory 기반의 기능들이 있습니다. 글자마다 서식이 다른 복잡한 녀석이라면 TextFlowTextLineFactory 를 사용할 수 있고, 서식이 하나로 통일된 단순한 녀석이라면 StringTextLineFactory 를 사용할 수 있습니다. 이 Factory 방식은 인터렉션이 필요하지 않은 아주 디스플레이용 글을 표현할 경우에 매우 유용합니다. 그리고, 무엇보다 이 Factory 방식에서는 truncation 기능 (긴 글의 마지막을 ... 으로 줄여주는 기능) 을 사용할 수 있기 때문에 굉장히 유용합니다. 주의할 점으론 TextLine 을 사용하고 난 뒤에는 수동으로 TextLineRecycler 를 통해 풀에 다시 집어넣어줘야 한다는 점 정도가 있겠네요.
그리고, ContainerController 나 좀 더 단순화된 TextContainerManager 는 좀 더 디테일한 기능의 조절이 가능합니다. 말 그대로 TextFlow 를 컨트롤하는 원천이기 때문에 Interaction 이 가능한 글을 만들려 할때는 가장 베이스가 되는 녀석입니다. 다만... 원천인 녀석답게 단순하게 쓰는데는 매우 편리하고 가볍지만, 복잡한 "쓰기", "스크롤" 기능들을 만들때는 매우 해야할게 많습니다. 특히나 쓰기에서 displayAsPassword 나 restrict 기능들이 하나도 구현되지 않은 정말 저수준의 녀석이기 때문에 시간이 넘쳐 흐르지 않는 이상 이 것으로 "쓰기" 기능을 구현하지 않는 것이 정신건강에 좋습니다.
마지막으로 Flash 에 포함되어 있는 TLFTextField 나 Flex SDK 에 포함된 input component 들이 있는데 쓰기 기능들을 구현하는데는 그냥 만들어져 있는 이 기능들을 사용하는게 좋습니다. TLFTextField 의 경우엔 좀 Class 가 정체를 알 수 없는 느낌으로 TextField 적인 api 와 TLF 의 api 가 짬뽕된 녀석이라 좀 거시기하지만... 정신의 평온을 위해선 이걸 쓰는 것을 추천합니다.
결론을 이야기 하자면
걍 디스플레이 용도의 간단한 텍스트 = TextLineFactory 계열
자유롭게 커스텀 할 수 있는 간단한 용도 = Controller 계열
쓰기 등 복잡한 처리가 필요한 폼 형식 = TLFTextField 등의 컴포넌트 계열
을 사용하면 될 것 같습니다.
사용법이 각각 계열마다 상당히 큰 차이가 나므로 익혀야 하는 api 수가 TextField 보다 많지만, 이래저래 성능 고려하거나 합리적으로 만들려고 할때는 도움이 많이 됩니다.
5 . TextFlow 의 후가공 처리
TextFlow 에는 getElementByID 와 getElementsByStyleName 이라는 두가지 메서드를 통해서 각 Element 를 불러오는 것이 가능합니다. 이 기능은 CSS 라는 일괄 서식지정 기능이 없는 TLF 에 도움이 많이 되고, 특히나 위에서 이야기한 InlineGraphicsElement 등을 사용하는데 도움이 많이 되는 편입니다.
getElementByStyleName 을 통해서 같은 스타일의 Element 들을 일괄적으로 모은 뒤에 서식지정을 한다거나 하는데 도움이 많이 됩니다.
6 . TextConverter, ITextExporter, ITextImporter
TLF 가 기존 TextField 보다 좋아진 점 대표적으로 꼽을 만한 것은 XML 형태의 전용 마크업 언어가 있다는 것인데요... 이를 통해서 서식이 지정된 텍스트를 저장하거나 읽어들이는 작업이 가능합니다.
다만, 마크업 언어 자체가 아직까지는 단순 서식 문서 정도만 지원하기 때문에 복잡한 처리를 위해서는 필연적으로 위에서 언급한 InlineGraphicElement 를 통해 확장시킬 필요가 있습니다.
제 경우에는 복잡한 쓰기 기능은 그냥 TLFTextField 를 사용하기로 했기 때문에 주로 flashx.textLayout.container 와 flashx.textLayout.conversion, flashx.textLayout.elements, flashx.textLayout.factory, flashx.textLayout.formats 만 보고 있습니다. flashx.textLayout.operations 나 flashx.textLayout.edit, flashx.textLayout.undo 의 경우엔 만지기 시작하니깐 사람 상당히 피곤하게 만드는 경향이 있어서 작업하다가 아예 포기해버렸습니다. 뭐... 혹시나 플래시로 위지윅 에디터 만들려는 사람들 아니라면 딱히 만질일이 별로 없는 부분이기도 합니다. 쓰기 부분을 피해서 알아보면 의외로 분량이 그다지 많지 않은 편입니다. 텍스트 엔진을 TLF 베이스로 바꾸고 싶으신 분들에겐 조금 참고가 되지 않을까 하네요...
그럼 이만~ 앙뇽~
컴퓨팅 대권의 향방?
애플이라는 보통은 성공하지 못할 괴짜가 1인자가 되면서 부터 시작된 IT 대전은 이제 무르익어서 절정에 다다르고 있는 느낌이다.
한참 애플과 구글이 치고박고 하는 중에 조용히 뒷구녕으로 움직이는 MS 의 움직임이 심상치 않아 보였다. 슬쩍슬쩍 보이긴 했는데 애플과 구글에 너무 집중된 조명 탓에 그냥 저냥 스쳐지나갔었는데...
이번 새로운 라이브 에센셜즈를 계기로 얘네들이 뭔가 엄청난 대공사를 하고 있다는게 눈에 보이는 것 같다.
역사상 최강의 윈도우라고 부를만한 windows7 부터 시작해서, 아직 드러나진 않았지만 상당한 정리가 이루어진 windows phone7, 공상과학 영화에서나 봤던 xbox 키넥트, 아직은 좀 병신같지만 상당한 성능을 자랑하는 검색엔진 bing, 그리고, 이번 라이브 에센셜즈에 포함된 여러 서비스들 까지 포함해서...
격전끝에 모든 패를 다 꺼내보이고 있는 구글이나 애플과는 틀리게 MS 는 잠수동안 지금까지의 MS 기반을 뛰어넘는 더 엄청난 크기의 성을 쌓고 있다는 느낌이 든다. 너무 대공사라서 이게 건물인지 잘 모르겠을 정도로 거대한 공사같다...
MS 답지 않음이 서서히 MS 다움으로 변해가는 느낌이 든다. 과거의 "더럽게 불편하지만 모든게 다 윈도우이기 때문에 MS 를 썼던" MS 스러움을 부시기 위해 애플과 구글이 공성전을 하는 와중에 그 성 뒤에서는 새로운 MS 스러움이라는 새 성을 쌓고 있는듯 보인다. 시간이 지나 이 MS 스러움이 완성되면 과연 대권은 누구에게로 향하게 될까...
