Monthly Archives: June 2007

아리따체로 삽질하기

아모레퍼시픽에서 배포하는 아리따체라는 글꼴이 있다. 지금까지 리눅스에서 맑은 고딕을 써 오다가 뭔가 라이센스 위반을 적게 하는 데스크탑을 만들겠다는 거창한 의도 하에 시스템 글꼴을 아리따로 갈아엎었다. 저 사이트에 있는 아리따 글꼴 압축 파일에는 아리따M, 아리따 SB라는 두 글꼴이 있다. 아리따M은 일반형, 아리따 SB는 볼드 글꼴이다. 볼드 글꼴과 일반 글꼴의 Family를 다르게 하는 것은 그 동안의 한국어 글꼴에서 관행이었지만, 지금 이 상황에서는 통하지 않는다.

리눅스의 freetype의 경우, fake bold를 사용해서 한 Family 안에서 bold가 없는 글꼴의 가짜 bold 효과를 구현하게 해 줄수는 있다. 그런데 아리따M 글꼴에는 fake bold가 통하지 않았고, 따라서 아리따 SB를 어떻게 잘 연결시키면 되지 않을까 생각했다. 불행히도 내 머리에 떠올랐던 방법은 TTF 파일을 직접 건드리는 것이었고, 이를 위해서 이리저리 찾아다녔다.

일단 내가 생각한 것은 FontForge였다. 불행히도 FontForge는 현대적인 GUI 툴킷을 사용하지 않아서 한글 입력에 문제가 있을 것 같았는데, 내 예상이 적중했다. Family 이름을 편집하기 위해서 FontForge로 글꼴을 연 순간 한글은 보였지만, 한글을 고치기 위해서 그 어떤 방법도 통하지 않았다. 별 수 없어서 FontForge는 포기했다. 누가 FontForge에서 family 이름을 한글로 입력할 수 있는 방법을 안다면 알려주기 바란다.

결국 윈도로 부팅해서 FontCreator라는 상용 프로그램의 셰어웨어를 사용하기로 했다. 다행히도 GUI 관련 문제는 없었지만, 한글 글꼴 이름이 \ 다음 CP949로 되어 있는 16진수 시퀀스로 나타났다. 거기에 한글 이름을 강제적으로 적어 넣으니까 family 이름을 정상적으로 인식하지 못했다. 16진수 시퀀스를 건드릴 필요가 없었기 때문에, family 이름을 모두 아리따로 수정하고 weight 정보를 bold로 주었다.

이제 fake bold 없이도 정상적으로 bold 글꼴이 의도한 대로 나타난다. 휴우. 불행히도 아리따체 사용 조건에는 이 행위를 금지한다는 말이 있지만, 나는 이 과정에서 glyph 정보를 건드리지 않았고 weight 정보를 건드린 것 뿐이다. 이것은 bold 글꼴의 family를 다르게 해서 생긴 잘못으로, 애시당초 글꼴 설계시에 이를 고려했어야만 한다.뭐 어쨌든 이런 조건 때문에 수정한 ttf 파일은 배포하지 않으며, 직접 수정해서 쓰기 바란다.

FAT32에 당하다

양동찬 서버 백업을 내 외장하드에 테스트해서 풀던 중 특정한 파일에서 오류가 났다. LANG=ko_KR.EUCKR 이라는 환경 변수를 줘 보아도 파일 이름이 깨지는 것은 계속 일어났다. 그 파일들은 UTF-8 시스템에 비정상적으로 업로드된 인코딩이 EUC-KR인 파일들이었고, 그게 외장하드에서 문제가 되었다. FAT32 파일 시스템의 문자 범위 제한 때문인지 모르겠지만 계속 파일을 열 수 없다는 오류 덕분에 복구가 힘든 줄 알았다.

그런데 scp를 통해서 백업 파일들을 서버에 복사한 다음 서버에서 tar xvf를 시도해 보았다. 멀쩡하게 잘 풀린다? 그 다음 convmv 시켜서 인코딩을 원위치시킨 다음 처리를 끝냈다. 태터툴즈 DB는 가상 서버 안에서 sql을 복사해 오는 것으로 끝났다. 좀 일이 어이없이 돌아가는 것 같았다. 그게 무슨 일인지 궁금해서 좀 뒤져 보았다.

예상대로 위키백과가 답을 주었다. 일부 ASCII 문자열들이 FAT에서는 제어 문자로 사용되고 있었고 파일 이름 문자로 사용될 수 없었다. 아마 비정상적인 UTF-8 시퀀스를 처리하면서 이런 문자를 쓰려고 시도를 했고, 그 결과 읽을 수 없는 파일 이름이 나온 것 같다. 정상적인 UTF-8 시퀀스라면 이런 일이 없을 것 같은데 말이다. 서버의 파일 시스템은 XFS였고, XFS에는 특별히 이런 제어 문자 제한이 없었던 것 같다. 그 덕분에 정상적으로 파일 압축을 풀 수 있었다.

뭐 결론은 convmv를 통해서 끝냈다. 하여간 꽤나 재미있는 삽질이었다.

태터툴즈 백업 결합 완료

시험이 끝나고 결국 해 보고 싶었던 삽질인 두 태터 백업 합치기에 도전해서 성공했다. cat을 통해서 두 개의 XML 파일을 합쳐 준 다음 XML을 가지고 놀면서 복구에 성공했다. 내 경우 두 파일의 합이 116.4MB라서 Kate에서 워드 랩을 끄고 작업했다. TT 백업의 경우 첨부 파일을 base64로 해서 한 줄에 박아버리기 때문에 워드랩을 끄는 것이 좋다. 그리고 나서 본격적인 삽길 시작.

두 번째 XML 쪽에 가면 post 태그로 둘러싸인 블로그 글들이 있는데, 이것을 첫 번째 백업의 해당하는 위치로 올리면 된다. 그 위치는 post 태그와 notice 태그의 사이이다. 여기 뒤에다가 글들을 붙여 주면 역시 해당하는 곳으로 들어간다. 그 다음 통계 부분은 일일 방문자 부분을 끌어올리고 두 블로그의 방문자의 합을 수동으로 계산해 주었다. 방명록은 두 번째 블로그 쪽에서 복사해 올 필요가 없었고 나머지 잔잔한 부분은 무시하고 서버에 올렸다.

그 결과가 지금 보고 있는 옛날 글들이다. 나중에 과거 블로그도 결합하기 위해서 soojung – ttxml 변환기나 만들어 볼까. 아 soojung 개발자도 지금 때려쳤다지.

서버 복구됨

오늘 시게이트 10k 73GB 하드가 도착하는 것과 함께 서버가 복구되었습니다. 짝짝짝. 우분투 7.04 서버를 no-CD 네트워크 설치해 주시고 또 다른 삽질도 이것저것 해서 그럭저럭 망가지기 전 환경은 구축했다. 아직 귀찮아서 백업 파일은 풀지 않았지만 곧 풀 예정이다.

그런데 Tattertools 백업 파일 merger는 없나? 백업 두 개를 한번에 풀어야 하는데 import를 시키니깐 각각 백업의 데이터만 불러와졌다. 웬만하면 기존 블로그 글도 합치고 싶은데, 아아 수동 merge 밖에는 없나.

WebKit 나이틀리 우분투에서 빌드하기

시험이 끝나서 삽질을 하다가 WebKit을 리눅스에서 빌드해 보기로 했다. 의외로 빌드 과정은 간단하다. 애플 SVN에서 땡겨 와 준 다음 리눅스용 스크립 돌리면 된다. 그런데 svn checkout http://svn.webkit.org/repository/webkit/trunk WebKit 이 명령어를 실행시키는 순간 오늘 기준 778MB를 긁어오고 있었다. 테스트 파일이 대부분이었지만 뭔가 좀 심각하게 흠좀무서웠다. checkout이 다 끝나고 빌드 명령어를 내렸다. gperf, bison, flex, libsqliet3-dev 등 필요한 개발 패키지는 다 깔려 있었다. 빌드 자체는 간단하다. QTDIR=/usr/share/qt4/ WebKit/WebKitTools/Scripts/build-webkit 명령이 전부. 그러나 그 단순함 뒤에는 뭔가 숨겨져 있다.

우분투 페이스티의 Qt 버전은 4.2.3이다. 그런데 빌드를 하다가 웬 뚱딴지 같은 에러가 나더라.

../../../WebKitQt/Api/qwebnetworkinterface.cpp: In constructor ‘WebCore::WebCoreHttp::WebCoreHttp(QObject*, const WebCore::HostInfo&)’:
../../../WebKitQt/Api/qwebnetworkinterface.cpp:785: error: ‘ConnectionModeHttps’ is not a member of ‘QHttp’
../../../WebKitQt/Api/qwebnetworkinterface.cpp:785: error: ‘ConnectionModeHttp’ is not a member of ‘QHttp’

어라? 왜 이러지 하면서 WebKit의 버그인가 알아보려고 했는데, 이건 Qt 4.2.3의 한계였음이 드러나고 말았다. 친절한 트롤텍씨의 QHttp 클래스 문서에는 Qt 4.3에서 새로 추가된 상수라고 쓰여 있었다. 순간 좌절. 이거 하나 때문에 Qt 4.3을 컴파일하거나 Gutsy로 지금 dist-upgrade 하기에는 너무 아깝다. 결국 우분투 페이스티에서 WebKit 빌드 포기.

Gutsy를 기다리거나 Qt 4.3을 컴파일한 사람이 있으면 그 성공담이나 듣자.