기타2007.09.29 02:17

아시는 분은 아시겠지만, 올 9월부터 KTX에 영화객실(KTX 씨네마)이 생겼다. 그런데 친구중에 한녀석이 그 KTX 씨네마 개봉작 조달과 시설 유지보수를 맡고 있는 씨네우드 엔터테인먼트라는 회사의 주식을 샀다면서, 나보고 이번 귀향길에 꼭 타고 내려오라고 신신당부를 하는게 아닌가. 이자식, 아쉬우면 돈이라도 보태주던가... 야튼 눈물겨운 호소에 결국 관람료 7000원을 더 내고 감상을 해봤는데, 음... 이건 좀 그렇다.

KTX 씨네마

일단 스크린 사이즈가 가장 눈물겹다. 사실 극장에 가는 큰 이유 중에 하나는 시각적인 감동을 얻기 위함인데, KTX 객실에서 스크린이 커봐야 얼마나 클 수 있겠는가. 대충 좀 와이드한 화이트보드 같았다. 어림짐작으로는 가로 2미터, 세로 1미터 정도로 보였다. 게다가 객실 가운데 동반석은 최악이다. 스크린 바로 아래쪽이라 목은 꺾일대로 꺾이고, 화면 저쪽은 잘 보이지도 않는다.

사운드도 역시 극장에 비할 바가 아니다. 나름 신경쓴 것 같긴 한데, 아무래도 장소가 협소하다보니 웅장함이나 깊이가 없는 느낌이다.

좌석의 불편함도 역시 큰 약점 중에 하나다. 뭐 KTX 한 번이라도 타 본 사람은 다 안다. 좌석이 얼마나 불편한지. KTX는 대량운송을 목적으로 하는 열차라 좌석이 무지하게 촘촘하다. 앞뒤간격은 물론이고 폭도 좁아서 조금 풍채 있으신 분들은 앉기도 힘들다. 사실 KTX는 빨라서 타는 거지, 편해서 타는 건 절대 아니다. 편한 걸로 따지면 오히려 새마을이 훨 낫지. 어휴... 쓰다보니 또 열받네.

야튼... 만약에 스크린, 사운드, 좌석 모든게 극장과 동일한 느낌을 주더라도 한 가지 어쩔 수 없는 문제가 또 있다. 바로 달리는 열차의 객실이라 좌석에 진동이 느껴진다는 것이다. 극장에서 좌석이 덜덜 떨린다고 생각해보라. 이거 원... 다른 문제보다는 좀 덜 심각하지만, 예민한 사람들은 영화에 집중하기 힘들 것 같다는 생각이 들었다.

여기까지 내가 느낀 바를 요약해보면, KTX 씨네마는 스크린 사이즈가 작고 사운드가 다소 빈약해서 극장에 비해 시청각적인 감동을 얻기가 힘들고, KTX의 고질적 문제인 좌석의 불편함 때문에 관람 이후에 사지가 뻐근하며, 열차의 진동으로 인해 집중력이 다소 흐트러지는 문제가 있다.

주식을 산 친구에게는, 조금 미안하긴 하지만, 냉정하고 솔직하게 얘기해줬다. "KTX 씨네마... 이렇게 하고 극장이랑 똑같이 돈 받으면 도둑놈이다!"

덧붙임) 명절 기차표를 구하지 못했을땐 KTX 영화객실을 예매하시라. 표가 남아돈다;;

신고
Posted by roguebean
기타2007.09.10 22:21

바다 하리 vs 루슬란 카라에프 (K-1, WGP 07 요코하마)

근래 봤던 K-1경기 중에 가장 인상깊었던 경기. 누워서 보다가 내 눈이 의심스러워 벌떡 일어났다는...ㄷㄷㄷ...

신고
Posted by roguebean
개발2007.09.03 00:22
OOXML의 ISO 표준 통과 여부에 대한 논쟁이 한참이다. 지금까지 내가 접한 내용들은 대부분 반대여론이었는데, 주로 기존 표준(ODF)과의 양립에 따른 혼란, 구현 가능여부에 대한 불확실함, 특허권이나 라이센스 문제 등 여러가지 이유가 있었다. 사실 나도 반대서명운동에 참여하기는 했으나, 복잡한 정황을 다 이해한 것은 아니고, 단지 그들의 표준안이 기술적으로 불만스럽기 때문이었다.

내가 개발에 참여하고 있는 ThinkFree Office는 MS Office와의 호환성이 핵심 과제이기 때문에 OOXML 지원은 필수요소라고 할 수 있다. 언젠가 ODF도 지원을 하겠지만, 그보다는 OOXML이 우선이었다. 그런 정책 덕분에 현재 ThinkFree Office는 WordprocessingML 읽고 쓰기가 지원이 되고 있고, SpreadsheetML과 PresentationML도 조만간 지원이 될 예정이다. 사실 OOXML 지원 업무에 많은 관여를 한 것은 아니지만, 일부 파트를 담당하면서 OOXML 스펙 문서(download)를 끼고 살다시피 했는데, 이 스펙 문서는 뭐랄까, 반쪽짜리 문서라는 느낌이 들었다. 얼핏 봐서는 모두 공개하는 것처럼 보이지만, 그렇지 않은 경우가 많다. 실제 이 스펙만 보고 문서를 정확하게 표현하는 것은 불가능하다. 몇가지 예를 들어보면 다음과 같다.

- 5.1.11.18 prstGeom(Preset Geometry), DrawingML-Main (p.3672)
Preset shape의 경우 '<a:prstGeom prst="heart"></a:prstGeom>"처럼 해당 shape의 preset name만 문서에 기록되며, path 정보가 없기 때문에, 해당 path를 알고 있는 MS Office만이 preset shape을 정확하게 표현할 수 있다.

- 5.1.11.11 gd(Shape Guide), DrawingML-Main (p.3660)
Shape path를 결정짓는 변수인 adjust value의 경우, shape guide로 그 값이 기록되는데, coordinate space가 정의되어 있지 않아 그 값의 의미를 파악할 수가 없다. 역시 MS Office만이 정확한 coordinate space를 알고 있다.

- 4.6.7 attrName(Attribute Name), PresentationML-Animation (p.3080)
애니메이션의 경우 특정 개체의 속성을 시간에 따라 변화시켜줘야 하는데, 그 속성이름을 attrName element에 기록한다. 그런데 실제로 PowerPoint 2007로 pptx 문서를 만들어보면 'style.color', 'style.rotation' 등 스펙에 정의된 이름 말고도 'fillcolor', 'r' 등 그네들만이 사용하는 이름이 문서에 기록된다. 심지어는 특정 vendor를 지칭하는 속성 이름들('ppt_x' 등)도 버젓이 기록된다. 만약 스펙에 근거한 개발을 한다면, 저런 속성 이름들은 처리가 불가능해진다.

- 4.6.92 val(Value), PresentationML-Animation (p.3158)
attrName과 마찬가지로 '0-#ppt_y/2'와 같은 말도 안되는 변수를 수식에 넣고 있다.

위의 예처럼 OOXML 스펙은, XSD를 통해 data type의 제한 정도만 정의하고 실제 data가 가지는 의미가 불확실한 부분들이 다수 존재한다. 이런 식으로 일부 문서 정보의 의미를 공유하지 않으면서 마치 모두 공개하는 양, 이름까지 Office Open XML이라고 지은 그네들은 정말... 가증스럽다. 만약 이런 상태의 스펙으로 OOXML이 전자 문서의 표준이 된다면, 그 스펙에 공개되지 않은 세세한 내용들까지 100% 지원해주는 Office 툴은 MS Office가 유일할테고, 결국 사용자 입장에서는 조금 비싸더라도 문서를 정확하게 표현해줄 수 있는 MS Office를 선호하게 될 것이다.

개인적인 생각으로는 OOXML은 표준으로 승격되기에 아직 무리가 있다. 다른 문제 다 제쳐두고 일단 스펙 자체가 불만스럽다. 이미 표준으로 확정된 ODF는 직접 다뤄본 적이 없어서 모르겠는데, 역시 부족한 접이 많다고 들었다. 바램이 있다면, 아직 문서표준을 확정짓지 말고, 어떤게 더 나은가 충분한 시간동안 검증을 한 다음에 표준을 정했으면 좋겠다. OOXML이건 ODF건 아직 나온지 몇년 되지도 않았는데, 벌써부터 표준으로 받아들이면 어쩌자는 건지...

신고
Posted by roguebean

티스토리 툴바