TT 1.0 발표가 연기된 관계로(JH님의 일정을 보았을 때 5월 안으로는 나오겠지만..) 리뉴얼 대신 스킨만 바꿉니다. -_-;

저번엔 새내기 세미나를 기계공학동 금요음악회로 대신했었고, 그때도 감동받았지만, 오늘 보았던 겐조 다케히사의 하프시코드 연주는 내 생애 가히 최고의 연주로 뽑을 수 있을 것이다. 태어나서 모차르트 곡을 눈물이 나올 정도로 인상 깊게 감상했던 건 이번이 처음이고 아마 앞으로도 거의 그럴 수 없을 것이다.

겐조 다케히사는 1980년 동경 예술대학 및 대학원을 나왔고, 84년부터 쳄발로, 오르간, 포르테피아노, 하프시코드 등 바로크 시대 이후의 건반 악기들을 폭넓은 레파토리로 연주하기 시작한 음악가이다. 특히나 인상 깊었던 것은 그가 맹인이라는 사실이다. 건반 악기를 연주하면서 악보를 보지 못한다는 것은 그에게 매우 힘들었을 텐데, 오늘 연주했던 것만 해도 상당한 난이도가 있는 곡들이었다. 매년 50회 이상의 연주회를 하며 훼리스 대학 음악부 강사를 맡고 있다. 음반으로는 [건반 음악의 영역], [J.S.Bach의 오르간 작품집] 등이 있으며 저서로 [새로운 사람은 새로운 음악을 한다]가 있다.

오늘 연주했던 곡들은 작자 미상의 [Upon la-mi-re], D.Scarlatti의 [Sonatas in A major L208 & 209], Couperin의 [La Rosignol en Amour], J.K.Kerll의 [Cou-cou], J.Kuhnau의 [Biblical Sonata No.1 'The Combat betwwen David and Goliath'], 그리고 Bach의 곡을 자신이 직접 편곡한 [Ciaccona from Partita for unaccompanied violin No.2], W.A.Mozart의 [Variation on 'Ah vous di rai je, maman'], 마지막으로 W.A.Mozart의 [4손을 위한 소나타]였다. 마지막 곡은 보조 연주자로 다른 여자 피아니스트와 함께 연주했다.

하프시코드의 음색은 알고 있었지만, 실제 악기와 연주 모습을 보는 건 이번이 처음이었다. 처음의 세 곡은 일본에서 만든, 매우 화려한 장식(그야말로 'baroque' 스타일)의 하프시코드를 썼고, 그 다음부턴 계속 독일에서 만든 매우 단순한 장식(그저 회색빛깔의 초록색 페인트만 칠한 듯 보이는)의 하프시코드를 썼는데 둘의 음색이 약간 달랐다. (사실 난 뚜렷한 차이는 못 느꼈지만 독일제가 좀더 명료한 것 같다) 그리고 두 곡의 Mozart 곡을 칠 때 사용한 포르테피아노는 실제로 모차르트가 사용했던 것을 그대로 본떠 만든 것이라고 한다.

하프시코드는 현이 매우 얇고, 음높이에 상관없이 한 음당 무조건 두 줄로 되어 있다. 현을 때리는 것이 아니라, 건반을 누르면 현 사이에 있던 막대가 올라오면서 작은 깃털 조각으로 현을 퉁겨 소리를 낸다. 하프시코드의 건반은 오르간과 비슷하게 2단으로 구성되어 있다. 한편 포르테피아노는 현대적인 피아노와 하프시코드의 과도기적 성격을 띠는 것으로, 현은 하프시코드와 거의 똑같지만 건반을 눌렀을 때 해머로 친다는 점이 다르다. 소리는 우리가 아는 피아노 소리에 고음부에서 약간 챙챙거리는 느낌이 더 난다고 보면 된다.

맹인이어서 그런지 몸의 자세가 다소 경직된 것같이 보였으나 점점 연주에 깊이 빠져들면서 아주 유연해지고, 또 어린아이처럼 발도 구르는 등 그야말로 어린아이가 피아노 앞에 앉아 호기심을 가지고 건반을 누르는 듯한 모습이 되었다. 자기가 마음 속에 담고 있었던, 그러나 겉으로 표현하지 못했던 감정들을 연주를 통해 쏟아내었고, 그것이 매우 순수한 열정으로 이루어지며, 그 표현 또한 세계적 수준의 연주 솜씨를 통한 것이었다는 점에서 눈물이 나지 않을 수 없었다.

살아있음에 감사하는 것. 마지막 곡인 모차르트의 네 손을 위한 소나타에서는 그야말로 내 평생 음악을 들으면서 도달하지 못했던 감동의 수준에 다다랐다. 피아노와 하프시코드를 두 연주자가 동시에 연주하면서 각자 자신의 열정을 쏟아내고, 음악을 통해 사람들을 기쁘게 하고 싶다는 그 순수한 마음이 온 몸으로 느껴졌다.

카이스트와 같은 곳에서, 내용이나 수준으로 보았을 때 실제 정식 공연이었다면 비싸서 갈 엄두도 내지 못했을 법한 그런 멋진 음악회를 들을 수 있다는 건 정말 감사할 일이다. 앞으로도 이런 공연 관람 기회가 더 확대되고, 또 더 많은 학생들이 알 수 있도록 홍보도 잘 되었으면 좋겠다.

업그레이드라고 해서, 겉으로 뭔가 달라져 보이는 건 아니지만, 봇의 내부 구조를 완전히 새로 만들었다. 일단 여러 개의 채널에 동시에 접속하여 각기 따로 메시지를 처리할 수 있도록 하기 위해, 다음과 같은 클래스들을 만들었다.


먼저 IRC Server에서 메시지를 받으면 그걸 clsIRCMessage에게 주어서 parsing한다. 그러면 그 결과가 그 클래스의 속성들로 저장되고, 이것을 1차로 clsIRC(전체 접속 및 channel과 관련없는 모든 메시지 처리)로 넘겨준다. clsIRC는 메시지를 분석해서 자기가 처리해야 하는 메시지일 경우 메시지를 처리한 다음 먹어버린다. (뒤로 전달하지 않는다) 그렇지 않은 경우는 clsIRCChannels(현재 접속된 채널 관리)로 메시지가 넘어가고, 거기서 clsIRCMessage.Channel 속성에 맞는 채널 object로 메시지를 보내면 거기서 처리하게 된다. 이때 이것이 특수한 명령어 인식 문자(backquote)를 가지고 있으면 clsIRCCommand로 넘기고 이 놈이 최종 처리를 하게 된다.

이전에는 모든 걸 소켓의 이벤트 프로시저에서 처리했는데, 일단 이렇게 만들고 나니 기능의 추가, 삭제가 매우 용이해졌고, ActiveX DLL을 이용한 플러그인 방식도 도입할까 생각중이다.

만들면서 가장 고려해야 할 부분은 IRC Server가 도배 방지를 위해 빠르게 많은 양의 메시지를 보내면 Excess Flood로 접속을 끊어버린다는 점이다. (IRC에서는 사람들이 일부러 봇에게 연속적으로 많은 출력을 하는 명령을 주어 이 현상을 일으키는데, 이걸 두고 "봇을 죽인다"라고 한다) 그런 걸 방지하기 위해서 그동안 보낸 메시지의 양을 기록하고 이걸 특정 시간 비율에 따라 감소시켜 일정값 이하일때만 메시지를 전송하도록 pending하는 기능이 필요하다.

아무튼, 옵테러 방지 등 일반적으로 irc 이용자들이 원하고 있는 몇몇 추가 기능들을 넣으면 꽤 쓸만한 프로그램이 될 것 같다.

오늘(2005년 5월 12일)은 내가 만으로 18세가 되는 (18금이 먼저 떠오르는..orz) 날이다. 별다를 것 없는 평범한 하루가 되는 듯 싶었는데, KAIST Orchestra 공연이 끝난 후 있었던 MR 정모에서 특별히 기억에 남을 날이 되었다.

KAIST Orchestra 공연도 간만에 만난 오아시스처럼 매우 좋았다. 내가 어렸을 때 즐겨 듣던 엘가의 위풍당당 행진곡이라든지, 차이코프스키의 꽃의 대왈츠(맞나?) 등을 연주했는데 아주 잘 했다기보담도 내가 좋아하는 곡들을 직접 연주하는 걸 자세히 볼 수 있었다는 점에서 좋았다. Orchestra 공연 끝날 때 앵콜 연주를 했는데, 갑자기 제1바이올린 악장과 지휘자 분이 옷과 자리를 바꾸고 바이올린과 지휘봉도 바꾸더니, 정말로 바꿔서 연주를 하는 게 아닌가. 악장이었던(...) 그 형은 매우 열정적(!)으로 지휘를 했는데 관객들은 다 웃었다. (정말 웃겼다-_-) 그러더니 양쪽 끝에 앉아있던 연주자들이 나와서 무대 앞을 장식한 ㅤㄲㅡㅊ들을 뽑아서 던져주는 것이다. 일순간 환호가 터졌다.;; 퇴장하고 나서 사람들이 꽃다발을 주러 무대 및 준비실에 잔뜩 몰렸는데, 나는 용선이(고등학교 때 같이 오케스트라 동아리를 했었다)를 만나 인사를 나눌 수 있었다.

그렇게 공연을 잘 보고, MR 정모 갈 시간이 딱 됐길래 바로 MR 동방에 갔다. 그런데, 같이 공연을 보러왔던 태경이 형이 먼저 간다 그래놓구선 안 오는 것이다. 분명히 먼저 간다고 했는데... 중간에 어디로 샌 걸까 궁금해 하고 있던 참에, 정모 끝날 때쯤 갑자기 케익을 들고 나타나는 게 아닌가. 자기 말로는 자전거 타고 어은동 쪽에 나가서 사왔단다. 정모와 MRG 팀 세미나가 끝나고, 이불을 뒤집어 쓴 채 약간의 생일빵(?)을 당한 다음 촛불을 켜고 동아리에서 생일 파티를 해 주었다. MR 선배들 얘기에 의하면 원래 MR에서 남자 생일을, 그것도 1학년 남자 생일을 이렇게 챙겨준 적이 없었다고 하는데 어떻게 된 건지 나도 잘 모르겠다. 아무튼 생일을 챙겨준 태경이 형한테 고마웠다.

정말이지, 개인적으로 축하받는 생일은 초등학교 때 이후로 처음인 것 같다. 누군가한테 '고맙다'라고 말할 수 있었던 것도 매우 감사할 일이다. 앞으로 나도 주변에 있는 사람들을 좀더 잘 챙겨주도록 노력해야겠다.

요즘에 토끼군 녀석 덕분에 시작한 IRC에서, #total 채널에 있는 사람들이 언제 토탈을 하자고 할지 알기가 어려워 불편을 느끼고 있었다. 그래서 특정 내용을 가진 메시지가 나타나면 알람을 주는 플러그인 같은 게 없나 고심하고 있었다.

마침 토끼군이 python으로 IRC 봇을 만들어 돌리기 시작하면서 나도 만들어 볼까 했는데, 그냥 만들어 버렸다.-_-

rfc1459를 참조해서 열심히 만들었는데 오타 때문에 서버 접속에 고생한 거 빼면 그 다음부턴 뭐.. 노가다일뿐.

지금 IRC로 irc.hanirc.org에 접속해서 #tokigun 채널에 가면 daybreakin이란 놈이 있는데 그놈이 내 봇탱이이다. (물론 내 컴퓨터가 꺼지면 없을 수도 있다. 또 추후 #daybreaker 채널을 만들어 거기서 돌릴 수도 있다)

자세한 건 "`help"를 쳐 보면 알 것이다. ㄱ-

요즘 들어 본격적으로 스터디를 시작하고 있다. 너무 한가하게(방만하게) 지내는 것 같는 느낌도 많이 들었고, 딱 시기 적절하게 스터디 기회가 주어졌기 때문이다.

컴퓨터 동아리 SPARCS에서는 MFC 스터디를 시작했고, 친구들과는 수리물리학 스터디를 시작했다.

MFC 스터디는 말 그대로 MFC 기반으로 윈도우 Application들을 만드는 걸 공부한다. 일주일에 한 번씩 동방에 모여 돌아가면서 세미나 형식으로 발표를 하고 필요에 따라 숙제를 내주기도 한다. 이번 주에 내가 맡은 것은 Windows GDI 시스템에 관한 것이다. 어제 몇 시간 동안 삽질한 끝에 드디어 MFC의 동작 기반을 다룰 수 있게 되었고 새로운 컨트롤을 추가하거나 메시지 핸들링을 하거나 하는 걸 익혔다. (그래도 내가 VB로 API 삽질을 워낙 많이 해서인지 기본 개념은 쉽게 익힐 수 있었던 것 같다)

수리물리학 스터디는 Boas가 쓴 Mathematical Methods in Physical Science라는 책을 가지고(원서 or 번역서는 개인이 선택) 역시 일주일에 한 번 세미나실을 빌려 각자 맡은 chapter를 설명하고 문제 풀이를 하게 된다. (사실 물리를 잘 하는 사람들은 보아스보다 아프간 책이 더 어렵고 좋다고 하지만 나도 그렇고 몇몇은 전혀 접해보지 않았기 때문에 조금 쉬운 것으로 택했다 - 다루는 내용은 급수, 복소수, 행렬, 미분방정식, 편미분, 텐서해석, 중적분 등이다)

이렇게 되니 슬슬 바쁜데 역시 나는 바빠야 뭔가 '사는' 듯한 느낌이 드는 것 같다. 물론 지나치게 바빠서 아무리 해도 내 힘으로 마무리지을 수 없는 상황이 되면 스트레스가 쌓이겠지만(작년 12월의 휴먼테크 준비 + 대통령과학장학금 신청 및 면접 + 기숙사 관리 프로그램 + 학교 홈페이지 프로젝트 + 졸업논문의 조합은 가히 최고였다-_-;;), 이런 정도로 적당히 바쁜 건 활력소도 되고 적당한 긴장을 유지시켜 준다.

정말로, 저번 중간고사처럼 공부를 안 하는 일은 다시는 없으리라 다짐한다.

ps. 위에서 말한 스터디 외에도 MR 동아리 로고 디자인, LT(Line Tracer) 로봇 제작, SPARCS의 수강지식인 디자인 벤치마킹 등의 다른 일들도 많다-_-;

3. 프로그래머와 디자이너

프로그래머와 디자이너는 서로 상극의 관계일수밖에 없는 것일까?

우연한 기회에 가입한 싸이월드의 UI 디자인 클럽에 내가 Visual Basic을 통해 GUI 개발을 하던 경험에 관한 글을 올렸더니 사람들 반응이 프로그래머와 디자이너는 가까워지기 어려운 것 같다는 것이었다. 여기서는 웹에 초점을 맞추어 디자이너와 프로그래머에 대해 말해 보고자 한다.

웹에서는 HTML이 내용을 구조화함과 동시에 그것을 어떻게 표현하는지에 관한 정보를 담고 있기 때문에 프로그래머 또한 HTML을 만들어야 하고, 디자이너 또한 HTML을 만들어야 한다. 이 과정에서 자연스레 충돌이 일어난다. 또한, UI 디자인을 아무리 잘 했더라도 디자이너가 생각한 모든 것을 세세하게 프로그래머가 구현할 거라고 기대하기도 어렵다.

웹 표준에는 flash가 있기 전에도 CSS라는 서식 지정 양식이 따로 있어 html을 건드리지 않고도 디자인을 바꿀 수 있게 되었는데, 아직도 CSS에 대한 근본적인 개념 이해 부족 및 관련 자료의 부재, 그리고 아직 미흡한 html과의 분리 등이 디자이너와 프로그래머의 완전 독립을 방해하고 있다.

그런 문제점을 해결하기 위해 html까지 디자이너에게 맡기는 방식으로 개발된 것은 php 개발 그룹에서 만든 smarty 엔진이 대표적이다. 또한 flash의 등장으로 DB 연동, xml 사용 등이 가능해지면서 디자이너들이 약간의 action script에 관한 지식만 있으면 손쉽게 디자이너와 프로그래머의 역할이 나눠질 수 있게 되었다.

그러나 현재 flash 전문가들이 지적하듯 flash를 이용한 DB 연동 등의 서적은 불필요한 asp, php 프로그래밍 기법까지 소개되고 있어 디자이너들의 혼란을 가중시키고 있다. 또한 smarty 등의 template 엔진을 이용하는 것에 대한 근본적인 필요성과 효과를 이해하는 사람들은 많지 않은 것 같다.

웹 프로그래머와 디자이너들 모두 그런 혼란에 휩쓸리지 않고 제대로 그 근본을 이해한다면 그것을 통해 간접적으로 표준의 필요성을 더 잘 이해할 수 있을 것이다.

어제 어영부영 하다가 초치기로 물리실험보고서를 쓰느라 점심도 안 먹고 이 더운 날에 저어기 멀리 떨어진 자과동까지 가서, 그것도 계단으로 5층까지, 게다가 복도 맨 끝에 있는 조교 방에 갔더니 글쎄 워크래프트 3를 신나게 하고 있는 것 아닌가. -_-;;;

누군 힘들게 보고서 내러 거기까지 갔구만, 게임을 하고 있는 조교..-_-
(보고서 기한이 오늘 오전까지였는데 12시를 넘겨서 혹시나 하는 마음에 빨리 갔는데...ㅠ)

뭐, 조교도 사람이기에(...) 게임을 하는 거야 좋지만, 또 그렇게 보고서를 촉박하게 쓴 나도 잘못이지만, 어쨌거나 그 순간 황당했음은 말할 것도 없겠다..-_-;; (그렇다고 그 조교가 잘못해다거나 뭐 그런 건 아니다. 다만 순간 어이없기도 하고 웃음이 나오길래 적어 보았다.)

조교가 게임하고 있을 때 뛰어가서 레포트 내고 싶지 않으면(??) 다음부턴 숙제 좀 덜 촉박하게 하자-_-;;

블로그에 글 쓰는 게 갑자기 귀찮아져 버렸다.

블로깅에서의 슬럼프라고나 할까. -_-

숙제며 공부할 것들이 이리저리 겹치고, 동아리에서도 할 일이 생기고, 거기다 토탈 게임도 하고 싶어지고...

웹 표준에 관한 세 번째 글과 경곽 신환회를 소재로 한 원칙과 타협 주제의 글도 써야 하는데 도저히 귀찮아서...OTL

그나저나 하나 둘씩 시험 채점 결과가 나오고 있는데 그거야말로 대략 OTL이다.. ㅠㅠ (그나마 다른 과목에 비해서 물리를 잘 보긴 했는데, 평균이 어떻게 되는지 모르겠다. 그나저나 미적분학 망한 건 잘못하다간 재수강으로 연결될지도 몰라서 낭패. - 이젠 고등학교 때 배운 걸로 버티기도 끝나간단 말이다!! - 오늘 드디어 역삼각함수를...)

이번 주에 형이 군대에서 휴가 나온다고 했으니 집이나 가야지..-_-

아는 형한테 쇼팽의 악보 파일들을 잔뜩 받고 압축을 풀었다.
탐색기로 파일 목록을 보던 도중 블루스크린이 뜨면서 리붓되어 버리는 게 아닌가? (그것도 XP Service Pack 2에서, 항상 최신 백신을 유지하는 시스템에서..)

귀찮아서 오류보고 안하려다가 해 봤는데 해결 방법을 제시한 게 있다길래(MS 하청업체 내지는 협력업체인 것 같음) 링크를 클릭했더니...-_-;;


젠장.. 뭐 이런 게 다 있어!!
파일 이름이 192자이면 에러가 난다고? -_- 게다가 더 황당한 건 이런 에러가 날 확률이 적다고 주장한다는 것이다. 이러니 MS Windows가 욕을 먹지..

어쨌든 폴더 이름의 글자 개수를 바꾸니 해결은 된 것 같은데 정말 어떻게 프로그래밍했길래 저런 버그가 생긴 건지 알 수가 없다.

ps. 오류가 난 파일은 System32Drivers 폴더 내의 AFPAnsi.sys 또는 BXShield.sys라고 한다. 이걸 복구 프로그램으로 삭제해서 컴퓨터 제조업체에서 제공하는 최신 드라이버로 깔라는데, LG 전자 홈페이지어 들어가니 고객 서비스가 그동안 리뉴얼하고 있다가 잠시 후 10시부터 새로 개장한다는 것이다. -_-;;;

아, 이게 얼마나 감격스러운 일인가!
게임회사가 망했는데 그 유저들이 그 게임을 바탕으로 다시 게임을 만들었다. (Total Annihilation은 97년도 쯤에 나온 게임인데, 당시로서는 너무나 고사양을 요구했었기 때문에 곧이어 나온 Starcraft에 밀려 결국 역사의 뒤안길로 사라지며 완성도 높은 미션과 유닛들이 포함된 확장팩 출시에도 불구하고 게임 제작 회사가 망해 버린 비운의(...) 게임이다)

Total Annihilation을 Full 3D RTS 게임으로 만드는 TA Spring 프로젝트의 결과물인 TA Spring 0.4b2 버전이 공개되었다.

다운로드 페이지 | 프로젝트 홈페이지

AI는 지원되지 않아 테스트 모드로 싱글을 하든지 아니면 서버에 접속해서 멀티를 해야 한다. (서버는 그냥 id, 암호만 만들면 쉽게 접속된다. 사람은 많지 않지만 게임을 해 볼 만하다)

인공지능이나 게임 편의성도 향상시켜, 나무가 있는 곳에 건물을 지으면 나무를 자원으로 회수한 뒤에 짓고, 자기 자신의 위치에 지으면 알아서 비켜서 짓는다.

게다가, 오픈소스로 진행되는 프로젝트여서 GNU General Public License로 배포된다!!

이건 말이 필요없다. 아래를 보시라~! (내 컴퓨터에서 실행한 것임)

뭐, KAIST 내부 portal 사이트가 firefox에서 호환이 제대로 안 된다는 건 이미 익히 알려진 사실이지만, 요즘 새로 고친 메일 시스템은 쓸 만 하기 때문에 가끔 firefox로 이용해 주고 있었다.

그. 런. 데. (클릭)

지금까지는 보통 1cell 짜리 table을 이용하였는데 원래 그 기능을 하는 hr 태그를 이용해 보겠다.

CSS에 다음과 같이 정의하고 <hr/>라고 써주면 끝이다. ^^;

hr {
clear:both; /* (option) */
margin:5px auto; /* (option) */
padding:0px;
width:360px; /* 알아서 적절하게. %로 해도 됨 */
height:1px;
color:#2D520D; /* 여기와 아래에 같은 색을 넣음 */
background-color:#2D520D;
border:0px;
}
/* for IE */
* html p {
margin:0px;
}
* html hr {
margin:0px auto;
}

약간 tricky한 방법이긴 하지만 이렇게 하면 훨씬 간단하게, 단 네 글자 만으로 수평선을 만들 수 있다.

from 토끼군.

덧. 일반적인 디자인 용도로는, <div style="border-bottom: 1px solid red; height:1px; margin:0px; padding:0px"></div>가 더 쓰기 좋을 겁니다.

이렇게 말이죠. 다만 hr은 p 태그 사이, 글 중간에 넣을 때 줄 중간에 표시되는 성질이 있다는 게 좀 다릅니다.

드디어 단계적으로 진행될 홈페이지 리뉴얼에 착수했다.

이번 리뉴얼의 최종 목표는 홈페이지의 인터페이스를 하나로 묶게 될 태터 스킨 제작 및 개인용 wiki 설치, 그리고 중학교 때까지 만들었던 각종 프로그램들 중 괜찮은 것들을 sparce 분점에 전시하는 것이 될 것이다. (현재 moni wiki 1.1.0 정식 릴리즈가 얼마 안 남았다고 하여 기다리는 중인데, MathML Drawing 등이 추가된다고 한다. - 지금 나온 4월 9일자 버전도 되는진 잘 모르겠다)

오늘 한 작업은 간단히(?) 메인 화면 수정하기.

http://daybreaker.info (클릭!)

ps. 메인의 사진에 나온 장소가 어디인지는 아마 우리 생물 교수님과 야외 수업(.....)을 했던 사람이면 알 것이다. -_-;;

2. 웹 표준이 반드시 '좋은' 것인가

웹 표준은 다양한 플랫폼(OS)과 브라우저 사이에 호환성을 유지하는 것이 주목적이다. 또한 다음에 자세히 설명하겠지만 내용과 형식의 분리라는 목적도 있다.

그러나 표준이 반드시 좋은 것, 또는 쓰기 편한 것은 아니다. (다음의 두 예를 보라)

ActiveX의 경우는 프로그래머 입장에서는 거부하기 힘든 매력을 가지고 있다. window 프로그램 만들듯이 만들면 웹페이지에서도 그대로 동작하기 때문이다. 하지만 결정적으로 Windows 전용인데다 표준이 아니다.
(개인적인 바람으로는 ActiveX가 다른 OS에서도 되고 보안 문제만 해결한다면 표준이 되었으면 하지만, ActiveX의 강력함은 근본적으로 system API에 직접 접근할 수 있다는 데서 나오기 때문에 어려울 것이다. 칼의 양날과도 같은 존재다. 그 대안으로는 차라리 java applet이 나을 것 같다)

또 하나 XHTML 표준에서 맘에 안 드는 건 b, i, u 태그로만 되던 것이
<span style="font-weight:bold"> (b 태그도 가능)
<span style="font-style:italic">
※ 정정합니다. italic을 나타내는 i 태그는 XHTML 1.1에서도 쓸 수 있는 것으로 확인되었습니다. 오해를 불러일으켜 죄송합니다.
<span style="text-decoration:underline"> (u 태그는 사용 불가)
와 같이 해야 한다는 것이다. 좀더 엄밀하게 구분되긴 했지만 막상 저 코드를 쓰는 입장에선 불편하다고 밖에 할 수 없다. (css 파일에 class를 만들거나 하면 되지만, 태터에서 글 쓰는 것과 같이 class를 선언할 수 없는 경우는 어쩔 수 없다)

표준을 지키는 건 필수적이지만, 표준을 지키는 것이 반드시 쉬운, 편리한 일은 아니다.

ps. b, i, u 태그 테스트 페이지