Mac OS X 10.6의 X11을 사용하는 FontForge와 같은 어플리케이션에서 복사와 붙여넣기 기능이 동작하지 않는 것은 Mac OS X의 Pasteboard와 X11의 클립보드가 제대로 동기화되지 않아서이다. 아마도 OS X 10.6의 Pasteboard에 대한 API가 변경되어 버퍼에 입력되지 않아서 그럴 것이다.
해결 방법은 간단하게 X11 Preferences > Pasteboard > Enable syncing의 체크를 해제하면 된다.
Petar Ivanček’s의 Kaptain Brawe는 크로아티아에 위치한 Cateia Games에서 개발하고 Big Fish Games에서 유통하고 있는 어드벤처 프랜차이즈입니다. Petar Ivanček’s이 게임 프로듀싱과 디자인, 아트웍, 애니메이션 등등을 담당했으며, 게임의 스타일은 원숭이 섬의 비밀과 같은 전통적인 포인트 앤 클릭 방식이고 고블린이나 텐타클: 최후의 날 처럼 처럼 특정 챕터에서 여러 캐릭터를 조작하여 퍼즐을 풀 수 있습니다. 게임 자체가 유머러스하고 퍼즐도 재밌기 때문에 한글화 테스트를 해보기로 했습니다. 다음 내용은 그 과정의 설명입니다.
우선, 게임을 진행하면서 한글화가 가능한지 파일을 살펴보니 대부분 Pack되지 않은 순수한 파일들이었고, 한글화에서 가장 중요한 요소중 하나인 한글 글꼴 추가 가능성의 경우 트루-타입이 아닌 DDS와 같은 비트맵 이미지를 사용되기 때문에 다행히 일반적인 XML 형식은 아니지만 10진법 유니코드 값, x, y, 너비, 높이와 같은 데이터가 기입되어 있는 텍스트 파일과 PNG 파일이었기 때문에 리버스 엔지니어링 같은 과정없이 수정이 용이했죠.
우선 추가되어야할 한글 자소의 수는 많지만, 자소를 추가했을 때 메모리 영역에 Overflow될지 모르기 때문에 이미지의 사이즈를 변경해서 확인을 해보니 글꼴 이미지의 크기가 600 KB 정도가 되면 게임이 멈춰버리더군요. 영문 글꼴 크기를 유지해야 했기에 유니코드의 완성형 한글 자소를 모두 입력하는 것은 거의 불가능하다고 판단되었습니다. 일반적으로 많이 사용되는 한글의 자소들만 추가하는 것이 가장 나은 방법이지만, 유니코드의 U+AC00 부터 U+D7A3 까지의 Hangul Syllables 영역에서 필요한 문자만 10진법으로 직접 골라내기란 굉장한 노동과 인내심을 요구하죠.
EUC-KR 인코딩의 한글 코드를 Unicode에 대입하는 스크립트를 작성해야 했지만, 다행히 웹상에 인코딩이나 유니코드 관련된 툴은 넘쳐나지요. 그 중에서 ASCII/Unicode를 2진법/10진법/16진법으로 바꿔주는 디코더를 이용해서 EUC-KR 인코딩의 한글 테이블을 10진법 유니코드 값으로 간단하게 변환이 가능했습니다.
이제 남은 PNG 이미지에 한글 자소를 추가하고, 각 자소의 좌표와 크기를 수정해주면 한글화 테스트가 끝납니다. 각 글꼴의 너비를 하나씩 확인해서 기입하는 것은 비트맵 데이터를 확인하거나 원본 글꼴의 벡터 크기를 비트맵 크기로 변환해서 데이터를 출력해주는 코드를 만들어야 하지만, 귀찮은 관계로 너비를 통일했고, 좌표값 또한 동일한 패턴으로 배열했습니다.
추출한 10진법 유니코드 값과 동일한 패턴으로 추가된 PNG의 한글 문자의 값을 기존 글꼴의 데이터 양식에 맞게 입력되어야 하기 때문에 LibreOffice (구 OpenOffice.org)의 스프레드시트를 이용해서 간편하게 컨버팅했습니다. 이런 간단한 과정을 거쳐서 적은 용량으로 한글 비트맵 이미지 글꼴을 완성했습니다.
이제 남은 것은 일반 텍스트 형식의 loc 파일에 번역한 내용을 넣기만 하면 한글화가 마무리됩니다만, 개인적으로 시간적 여유가 많지 않기 때문에 전체 대사와 오브젝트를 모두 번역은 하지 않았습니다. 현재 Kaptain Brawe 시리즈는 에피소드 2까지 출시된 상태인데 에피소드와 OS에 상관없이 파일구조가 동일하므로 똑같이 적용이 가능합니다.
내 MacBook Pro를 포맷해야 하는데 거의 쓰지 않았음에도 어느날 아무 이유없이 돌연사한 SuperDrive 때문에 회사 동료에게 LG전자의 GP08LU10을 빌렸다.
하지만, LG전자의 신문 기사와 제품 설명서에도 Mac 지원을 강조하고 있는데도 불구하고 마운트 자체가 아예 되지를 않는다. 구글링 해보니 이러한 사례가 많은데, Apple Discussions에 보면 Snow Leopard에서 Firewire를 포함한 외장 드라이브 인식이 안되는 경우의 이야기가 많다.
최후의 수단으로 내 SuperDrive의 펌웨어 업데이트를 해봤지만 물리적으로 고장이 났는지 여전히 디스크를 뱉어내는 현상도 마찬가지라서, 아무래도 GSA-S10N 벌크 제품을 사서 직접 교체할 수 밖에 없을거 같다. 
TextMate 2가 언제 릴리즈될지는 알 수 없기에 (Duke Nukem Forever 처럼은 아니겠지만) 그 동안 사용하기 위한 용도로 이전의 폰트와 다르게 다시 만들었습니다.
영문은 Dejavu Sans Mono 2.30, 한글은 나눔고딕 코딩글꼴, 일본어 및 한자는 Meiryo를 사용하여 글꼴을 조합했습니다. 각각의 글꼴마다 라이센스가 다르기 때문에, 혹시라도 문제가 될 소지가 있다면 코멘트 또는 이메일로 알려주십시오.
Download TextMate Sans Mono
어제 Safari 4 Developer Preview를 설치하고 나서 잠시 자리를 비운 사이에 돌아와 보니 화면이 계속 꺼졌다 켜졌다를 반복하고 있었다. 무슨 일인가 싶어서 System Preference의 스크린세이버 탭을 클릭하자 이미 선택되어 있었던 스크린세이버가 제대로 동작되질 못하니 에러를 내뿜으면서 바로 Crash Report 창이 떴다. 이것 때문에 선택된 특정 스크린세이버가 동작을 못하고 System Preference 프로세스가 죽어버리니 그런 현상이 발생한 것이었다.
~/Library/Preferences의 plist를 지우면서 확인해봐도 plist의 문제는 아니었다. 구글링을 해보니 Safari 4의 문제였던 것으로 보였다. 사파리 4는 버전 3.x에 비해서 더욱 빨라진 성능을 보여주지만 아직 완성된 빌드가 아닌데다, 내심 찜찜한 것도 있고 해서 그냥 Uninstall 하는 걸로 간단히 해결했다.
매킨토시를 사용하는 직장인이나 학생이라면 맥을 켜거나 재시작할 때 나오는 시작음으로 주목 아닌 주목을 받는 경우가 종종 있다. 이런 난감한 경우를 피하려면 시작음을 안나오게 해줄 어플리케이션을 설치하면 된다.
Psst를 설치하거나 일본의 개발자가 만든 StartupSound.prefPane을 설치하면 된다.
TextMate에서 한글이 겹쳐 보이지 않도록 Monaco를 기본으로 Un Dotum과 Malgun Gothic Regular로 글꼴을 만들었고, hetima의 스크립트로 하다가 merge하는 과정에서 계속 internal error가 발생해서 일일히 수작업으로 수정했습니다. 글꼴 다운로드는 아래 링크를 클릭하세요.
Download TextMate Hangul Fonts
견습 마법사의 다이어리 블로그를 보고 정보 통신부가 OpenDocument Format을 행정 업무용 문서 표준으로 채택하는 것을 추진한다는 소식을 접할 수 있었다. 정부가 공개 소프트웨어 활성화 하겠다는 메아리만 울려 퍼지던 때를 생각해보면, 최근 웹 표준과 접근성에 대한 것이나 ODF의 지지 또한 참 반길만한 소식이다. 근데, 인용된 기사 내용의 절반 가량은 한글과컴퓨터사가 ‘한컴 오피스의 모든 기능을 ODF로 가져가기 힘들다’는 인터뷰가 차지 하고 있다.
여기서 잠깐 MS 이야기를 하자면, 흔히들 MS가 Windows를 판매해서 높은 수익을 올릴거라 생각하지만, 실제로는 Windows 패키지는 그다지 팔리지 않으며 대부분 Dell이나 HP와 같은 하드웨어 벤더들의 컴퓨터에 OEM으로 판매되므로 큰 이익은 없으며, 오히려 기술 지원으로 이익을 얻는 편이다. 그럼 MS의 패키지 제품 중에서 가장 효자노릇을 하는 소프트웨어는 무엇일까? 바로 MS Office 시리즈이다. MS의 오피스가 업무적으로 편리한 기능을 제공하고 거의 업계 표준으로 자리매김을 했지만, 맥을 제외한 다른 플랫폼에 대한 포팅이나 지원은 없다.
그리고 맥용 Office를 사용해 보면 차라리 Windows가 깔린 PC를 사고 싶어질 정도이다. 사무환경을 위해서 Windows를 사용해야만 하는 상황이기에 OpenOffice.org나 OpenDocument와 같은 오픈 소스 프로젝트가 주목을 받고 있는 것이다. 정보 통신부가 이러한 기술에 대한 지지를 보낸다는 것은 공개 소프트웨어 활성화 정책과도 일맥 상통하고 특정 기업의 기술과 플랫폼 종속에서 벗어날 수 있는 선택의 기회가 주어진다는 점에서 참으로 반가운 소식이 아닐 수 없다.
견습 마법사님은 현재 행정기관에서 사용되는 HWP 포맷의 기능들이 ODF로 전환시 발생할지 모르는 문제점에 대해서, 아래아 한글과 MS Office에 익숙해져 버린 사람들이 과연 잘 사용하게 될 것인가라는 의문점들을 아래와 같이 예를 들어 보았다.
표(table)는 어차피 데이터를 배열을 하기 위한 표현 양식이다. 표를 그리기 위한 사용자의 편리함은 데이터를 저장하고 표현하기 위한 파일 포맷인 ODF에서 문제점을 찾기란 어렵다. 사용자가 표를 편리하게 그리기 위한 것은 소프트웨어의 User Interface에서 담당할 부분이다.
사족이지만, 한국 사람들 대부분은 데이터를 표로 표현하기를 너무나 좋아하는데 문제점을 짚을 수 있다. 흔히 우리가 어릴때 배웠던 편지 쓰기와 같은 head, body, foot 으로 구분되는 문서 레이아웃으로 서술하는 외국의 형태와는 거리가 멀다. 아마도 내 생각이지만 일제 시대의 문서 양식을 그대로 답습하고 있기에 그렇다고 본다. 예나 지금이나 어린 학생부터 나이든 어른들까지 자기 생각을 글로 잘 표현하 못하거나, 논술을 위해서 학원까지 다니는 것을 보면 이런 조그만 것에서 기인했다고 보는건 좀 과장된 생각일까?
아무튼 표는 데이터를 배열로 표현할 때 유용하지만, 우리나라 처럼 주객이 바뀌어서 여기저기 표를 많이 사용하게 되면, 문서를 읽게 되는 사람은 정확한 정보라고 심리적 안정감을 얻을 수 있을지 모르지만, 표는 서술된 내용을 뒷받침하는 보조적인 역할인데다, 표에 나열된 항목에 대한 제목 이외의 내용을 기입하기란 어려운 점 등등 표를 통해서 모든 정보를 표현하기란 매우 어렵다. 이외에도 여러가지 이유가 있지만, 외국의 문서와 웹 사이트들이 왜 서술형을 지향하는지에 대해선 곰곰히 생각해보면 금방 알 수 있으며, 워드 프로세서나 HTML과 같은 문서 관련된 기술을 보면 편리한 서술 양식을 위한 기능을 제공하기 위해서 왜 업데이트를 하고 노력하는지에 대해서 잘 알 수 있다.
소프트웨어를 개발하는 벤더 입장에서 노력을 쏟는 부분 중 하나일 것이다. 기존의 국제적으로 널리 쓰이는 문서 포맷은 별 문제점 없이 ODF로 컨버팅이 가능할 것이며, HWP는 한글과컴퓨터에서 해결해야할 문제이며, HWP to ODF 컨버트는 그다지 어려운 문제는 아닐 것으로 예상된다. 그리고, 국제 문서 포맷 표준으로 인증받기 위해 IBM과 SUN을 위시한 OpenDocument Format Alliance과 Office Open XML을 내세우고 있는 MS가 서로 으르렁 거리고 있는 상황인데, ECMA는 MS의 손을 들어주었다. 하지만 ODF 진영은 ISO 인증을 받았기에 앞으로 용호쌍박과도 같은 문서 포맷 전쟁이 한동안 이어지리라 생각된다. 하지만 결국 이해 관계를 넘어서 서로의 포맷을 지원하게 되리라 예상된다.
검색엔진 모듈은 개발사에서 알아서 해결해야될 문제다. 별로 어려운 문제라고 보여지진 않는다. 그리고, XML과 ZIP 형식으로 저장되기 때문에 요상한 바이너리 형태의 파일 포맷 보다는 훨씬 더 빠르고 쉽게 접근이 가능하다.
OpenDocument에 DRM에 대한 메카니즘은 없다. 하지만 추후에 추가될지도 모르겠다. 근데 DRM이 간절히 필요한 기능이라면 스펙에 이미 검토되었겠지만, 사실상 DRM 이딴거 필요하나? 곰곰히 생각해보자.
대충 견습 마법사님이 말씀 하신 내용을 토대로 메모를 해보았다. 나도 아직 ODF에 대해서 정확히 아는 바가 없기에 아래의 링크로 대신 맺음을 한다. 그리고 정통부와 행자부가 의기투합만 잘 한다면, 사용자(직원)가 느낄 ODF 사용에 대한 불편함은 잠깐이리라. (군대로 치자면 고참이 까라면 까야지 – 별로 좋은 농담은 아니다.) 다시 한번 최근 정통부의 노력아닌 노력에 박수 3번을 보낸다.
지난 글에서도 적었지만 Emacs와 VIM을 제치고 TextMate는 최고의 텍스트 에디터의 왕좌에 올랐으며 매킨토시의 Killer App으로 자리매김한지 오래다. 물론 투표결과는 단편적일 수도 있다. 하지만 빠르고 능률적이며 재밌게 프로그래밍을 할 수 있는 가장 진보된 에디트 환경을 제공한다는 데에는 다들 이견이 없을 것이다. 아, 물론 2Bytes Character를 사용하는 아시아권을 제외하고 말이다.
Nmind님의 글에서 TextMate를 Windows용으로 카피인 (포팅이 아니다.) E-TextEditor beta버전이 ‘The Power of Textmate on Windows’라는 부제를 달고 릴리즈된 소식을 접할 수 있었다. 웹 사이트를 방문해 보니 Copy라는 단어가 머릿속에 먼저 인식이 되어선지, 웹 사이트의 디자인 또한 Macromates의 그것과 사뭇 비슷하단 느낌이 들었다. 먼저 인덱스 페이지의 스크린 캐스트를 보니 TextMate의 Shortcut key와 Snippets 기능를 거의 그대로 갖고 온듯 보였으며, TextMate의 거의 대부분을 복제했는데, 나름대로 더 나은 기능을 제공하려는 것 같아 보이기도 한다. 포럼의 알림말을 보니 2006년 12월 부터 베타 릴리즈가 시작된 듯 하다. 더욱 재밌는건 스크린캐스트에서 들려오는 E-TextEditor의 개발자 Alexander Stigsen가 TexMate를 개발한 덴마크인 Allan Odgaard의 억양과 어투까지 비슷하게 흉내내고 있다.
블로그에는 E-Texteditor의 릴리즈를 축하하며 환호하는 Windows 사용자들의 코멘트가 주루룩 달려 있으나, TextMate 블로그에서 종종 보이는 p4bl0와 같은 TextMate Fanboy들이 왜 Allan에게 허락을 받지 않고 복제를 했느냐는 성토성의 코멘트도 보이고 Linux를 위해서 오픈소스로 공개해달라는 리눅서들의 코멘트도 보인다. 현재 E-TextEditor는 30일 사용이 가능한 트라이얼 버전을 다운로드 받을 수 있고 라이센스 가격은 $34.95이며, TextMate는 €39이다.
아직 Allan이 E-TextEditor에 대해서 아무 말도 없는 것을 보면, 신경쓸 정도로 생각하지 않는 듯 하다. 이런 상황이 Windows Vista가 Mac OS X이 되고 싶어하는 광경이 그대로 재현되고 있는 상황이 재밌기도 하다. TextMate 2.0 소식은 이미 다들 알겠지만, Mac OS X Leopard 출시 후에 무료로 업데이트가 된다. 아마도 2-Bytes Character 입력 문제 또한 CoreText를 이용해서 해결될 것으로 보인다. E-TextEditor의 릴리즈를 지켜봐야 알겠지만 Windows에서 작업할 때 유용하게 쓰일 듯 싶다.
