현재 ODF 파일 표준은  OpenOffice.orgKOffice , Google Docs, IBM Lotus Symphony  등에 구현이 되어 있습니다. 반면에 OOXMLMS Office 2007씽크프리 오피스, 그리고 애플의 iWork 2008, iphone, TextEditor 그리고  XML editor로 유명한 Altobad 의 XMLSpy , 코렐 오피스의 베타 버전 등에 구현되어 있고 노벨에서도 지원하겠다고 합니다.  나름대로 회사의 전략과 입장이 있겠지만 OOXML의 경우 대부분은 시장에서의 사용자 요구 사항에 대한 적극적인 반응이라는 전략에 맥을 갖는 것으로 보입니다. ( 참고로 초기 OpenXML로 불렸는데 ECMA에서  OOXML-Office Open XML로 명칭을 변경했습니다. 포스팅에서는 OOXML로 통일하겠습니다.)

- 씽크프리에서의 OOXML 지원

며칠 전 회사에 방문했던 MS의 Eric White씨의 블러그에 씽크프리와 저에 대한 포스팅이 올라왔네요. 저를 무척  young하게  본 모양입니다. 감사합니다. ^-^ -

http://blogs.msdn.com/ericwhite/archive/2008/02/09/thinkfree-a-cool-implementation-of-open-xml.aspx

2007년 초, 씽크프리에서는 일본 및 미국 시장에서 OOXML의 지원이 필수 요청 사항으로 제출되었고 이와 더불어 문서 표준화에 대한 검토를 진행했었습니다. 당시 , 검토에 있어 가장 높은 기준 순위는 기존 바이너리 파일과의 호환성과 확장성 이었습니다. 또한 초기 오피스 2007이 급속히 확산되지 않겠지만 점차 확산될 것이고 이와 더불어 OOXML 이 광범위하게 보급될 것으로 예상했습니다.  이러한 오랜 내부 검토 과정을 거쳐  OOXML을 ODF에 앞서 지원하기로 결정했었습니다. 이에 따라 2007년 하반기에 3개월에 걸친 작업을 통해   OOXML의 import/export 를 개발했고 이후 다양한 필드의 테스팅을 거쳐 현재 메인 트렁크에 반영된 상태입니다. 실제 현재 씽크프리 온라인을 통해 제공되는 오피스는 OOXML을 지원하고 있습니다. 지원 이후 크게 홍보가 되지 못했는데 이번 OOXML-ODF 의 표준화 전쟁을 통해 다양하게 홍보가 되는 것 같습니다. ^-^ 아래는  씽크프리 Show에서 PPTX를 읽은화면입니다. 지난 번 , MS의 Eric White씨와이 미팅에서 MS 오피스 맥버전과 실제 비교를 해서 보여 줬는데 씽크프리가 훨씬 빠르며 OOXML을 월등히 지원하는 모습에 무척 놀랐었습니다. ^-^. 실제 맥용 MS오피스는 윈도우용과 완전히 다른 코드로 개발되고 있습니다.

사용자 삽입 이미지

씽크프리에서 XML 지원 화면























- 애플에서의 OOXML 지원
현재 애플에서는 iWork 08버전에서  OOXML 을 지원하고 있고 아이폰의 메일에서 첨부파일 뷰어가  OOXML을 지원하고 있습니다.  다음은 아이폰에서의 OOXML지원 동영상 입니다.
 

- Altva에서 OOXML 지원
Altova의 XMLSpy는 XML Editor 중에서는 가장 널리 사용되는 제품입니다 XSLT와 XQuery 등 실수하기 쉬운 복잡한  XML 을 다루는 데는 가장 유용하지 않나 싶습니다. 이 제품에서 현재 OOXML을 지원하고 있습니다. 다음은 XMLSpy 에서 OOXML을 지원하는 화면입니다.

사용자 삽입 이미지



Posted by 박재현
,

사용자 삽입 이미지
구정 연휴 동안 ODF,OOXML 등 문서 표준화를 둘러싼 여러 정황들과 기술들에 대해 심도깊게 살펴보았습니다. 당분간 문서 표준화를 둘러싼 여러 기술들과 정치적인 배경, 경제적인 문제 등에 대해 정리를 해 볼까 합니다.  개인적으로오피스 문서 표준화가 미치는 영향이 일반적으로 생각하는 것보다 큰 파괴력을 갖기 때문입니다.  가령, HWP 바이너리 문서 대신  ODF 나 OpenXML이 표준화가 되다면 기존의 한글 워드프로세스의 주력 시장인 정부 공공기관이나 학교 등에서 더 이상 한글 워드프로세스를 사용하지 않아도 무방하기 때문입니다. 이미 가격적인 면에서  MS는 이미 Student/Teacher 버전의 경우 $60에 공급하고 있고 , 중국 정부에 10$에 공급을 하고 있는 상황입니다.

이처럼 오피스 문서의 표준화의 경우 정치,경제,문화,기술적으로 많은 복합적인 이슈들을 포함하고 있습니다. 민족주의적 관점에서 보면 ODF도 결국 Sun이 배후조정하고 있는 Openoffice.org 를 통해서  MS와 경쟁(?, 실제 경쟁이라기 보다 MS의 오피스 사업을 어떻게된 수익을 줄이고 정부기관이나 교육 기관등에 시장을 만들어 보자라는 전략)하겠다는 것이고 , OOXML의 경우도 MS가 정체되어 있는 오피스 시장을 확대하여 서버기반으로 확대하고 표준화를 통해 각국의 정부 기관과 교육 기관등 취약한 부분을 열겠다는 전략이 숨이 었습니다.  따라서 결국 , 어떤 표준안도 우리나라 입장에서 보면 비슷한 것이죠. 그러나 결국 어떤 표준안이 되도 또 끌려가야 한다는 것이 문제가 아닐 수 없습니다. 전에도 이 부분에 대해 간략히 언급한 적이 있습니다만 자료를 정리하다 보니 중국의 사례가 눈에 띠어 정리해 봅니다.

- 2008/02/02 - [Office2.0] - Open XML VS ODF 표준화의 최종 라운드

혹시 UOF(Uniform Office Format) 라는 오피스 문서 표준을 아시나요?

UOF는 XML 에 기반한 중국 오피스 파일 포맷 명세으로 중국 정부와 SW업체,학교 및 관련 연구소에서 2005년 만든 국가 표준입니다.  한 3년간의 작업을 했다고 합니다.  초기 이 표준은  RedOffice의  요구에 의해서 시작되었다고 합니다. RedOffice는 오픈 오피스에 기반하여 개발된 중국 오피스입니다. 결국 ODF에 기반한 것이죠. 현재 베이징 대학에서 이미 ODF-UOF 변환 필터를 오픈 소스로 개발하여 제공하여 그 기반도 탄탄히 만들어 놓은 셈입니다. 그리고 더욱 중요한 것은 Sun Microsystem의 묵인하에 몇몇 중국 관련 특허가 UOF 에 포함되어 있고 RedOffice에 구현되어 있습니다. 결국 중국 오피스 시장은 UOF를 통해 보호되고 있는 셈이죠. 상황이 이렇다 보니 과거에 빌 게이츠가 중국을 방문하여 윈도우 소스를 제공하고 윈도우를 거의 공짜 수준으로 제공하여 시장을 열려고 하는 노력을 이해할 수 있을 것 같습니다. 그런데 Sun이 ODF 기반으로 UOF를 그냥 놔두는 것은 정말 이해하기 힘든 결정인 것 같습니다. 자바와 오픈 오피스의 지배권을 끝까지 가져가면서 결국 시장을 더 망치치 않나 싶습니다. 아^-^ 피곤한 태양!

이러한 중국 오피스 문서 표준화를 보면서 국내 오피스 시장을 보면 많은 걱정이 됩니다. 특히, 아무런 국내 시장에 대한 보호장치 없이 ODF-OOXML이 국내 표준이 된다면 ( 실제 개인적으로는 이미 ODF는 ISO의 표준이고 OOXML의 ECMA와 산업계 표준이기 때문에 오는 3월 OOXML의 ISO의 표준 투표 결과는 실제적으로는 큰 의미가 없다고 생각합니다.) 실제 그 간 많은 우여곡절끝에 명맥을 유지하고 있는 기존 국내 오피스 회사들은 또다른 생존을 위한 변신을 해야할 것으로 보입니다.  어쩌면 지금이라도 국내 문서 표준화라는 것이 필요할 지 모르겠습니다.

물론,XML 기반 문서 관리,컨텐트 관리를 주력으로 하는 회사들은  이와 반대로 새로운 사업 기회를 얻겠죠. 그런데 재미난 것은 이미 MS의 경우 이러한 서버 기반의 솔루션의 개발을 이미 수년간 해 오고 있다 것 입니다. OOXML을 이미 지원하고 있는 씽크프리도 또 다른 기회를 얻게 될까요!^-^


Posted by 박재현
,

연휴 기간에 밀렸던 자료들을 보다 보니 MS 오피스 사용자가 5억 , 오픈 오피스의 다운로드수가 1억 정도라 합니다. 대충 사용자수를 알 수 있을 것 같습니다. 더구나  MS 오피스의 경우 정식 라이센스수로 추정했을 터이니 불법 사용자까지 포함하면...

문제 하나 내겠습니다.

Q>전 세계 오피스 관련 파일들의 크기가 얼마나 될까요?
A>정확한 수치는 exabyte(100경) 단위로 측정된다고 합니다. 나름대로 비싼 자료니 허무맹랑한 소리는 아닐 것 입니다.

도무지  exabyte 단위의 감이 잡히지 않아 좀 정리해 보았습니다.

* Kilobyte 103, 210
* Megabyte 106,220
* Gigabyte 109,230
* Terabyte 1012,240
* Petabyte
    1,000,000,000,000,000 bytes — 1015,
    1,125,899,906,842,624 bytes — 250
* exabyte , 100경
    1,000,000,000,000,000,000 bytes — 1018
    1,152,921,504,606,846,976 bytes —  260
* zettabyte
    1,000,000,000,000,000,000,000 bytes — 1021.
    1,180,591,620,717,411,303,424 bytes — 270
* Yottabyte
    1 septillion, or 1,000,000,000,000,000,000,000,000 bytes — 1024
    1,208,925,819,614,629,174,706,176 bytes — 280

아래는 상식입니다. 저는 무량대수가 가장 큰 수인줄 알았는데 구골플렉스가 있다고 합니다.  재미없는 모임의 퀴즈에서 간혹 나오는 문제입니다. ^-^

* 萬 - 10의 4제곱
*  億 - 10의 8제곱.
*  兆 - 10의 12제곱.
*  京 - 10의 16제곱.
*  垓 - 10의 20제곱.
* 秭 - 10의 24제곱.

* 穰 - 10의 28제곱.

*  溝 - 10의 32제곱.
*  澗 - 10의 36제곱.
*  正 - 10의 40제곱.
*  載 - 10의 44제곱.
*  極 - 10의 48제곱.
* 항하사 恒河沙 - 10의 52제곱. 갠지스강의 모래알처럼 많은 수량이라는 의미.
* 아승기 阿僧祇 - 10의 56제곱.
* 나유타 那由他 - 10의 60제곱.
* 불가사의 不可思義 - 10의 64제곱. 헤아릴 수 없이 많다는 의미.
* 무량대수  無量大數 - 불가사의의 억배.
* 구골 googol - 10의 100제곱.
* 구골플렉스 googolplex - 10의 10억제곱.



Posted by 박재현
,

씽크프리는 업무 특성상 메일로 의견 교환이 많습니다. 특히, 저의 경우 외국 파트너나 엔지니어와의 의견 교환이 많을 뿐만 아니라 내부에서도 무척 많은 편입니다. 간혹, 메일을 주고 받는 과정에서 오해가 많이 발생해서 난처한 일이 발생한 적이 있었습니다. 특히, CC를 말그대로 참고로 넣었는데 CC로 받는 분중에서 오해가 많이 생기더군요..^-^ 이럴 때마다 항상  나름대로 주의해서 메일을 써야 겠다라는 생각을 했었습니다. 우연히 블루문님의 블러그에서 이와 관련된 좋은 글이 있어 소개합니다.

1. 제목은 상대방 입장에서 쓸 것
- 이메일의 제목은 상대방이 쉽게 알아 볼 수 있는 제목으로 작성할 것
- 보낸 이메일은 자신의 것이 아니라 "상대방의 것"임을 명심할 것
- 연속으로 메일을 보낼 경우 비교 관리하기 쉽도록 제목을 정할 것
- 내부 소통을 위한 이메일과 외부 전달을 위한 이메일의 제목을 혼용하지 말 것

>> 추가 하고 싶은 내용
CC를 추가할 경우에도 해당 받는 사람의 입장을 고려해서 작성하는 것이 좋다. 특히, 조직에서는 다른 부서의 상관이나 특정 이해관계에 있는 분들이 오해를 할 수 있는 단서가 될 수 있다.
 
2. 적절한 호칭을 사용할 것
- 상대방 조직에서 사용하는 정식 호칭을 거명할 것
- 호칭에 맞는 상대 존칭을 사용할 것
- '압존법'을 극단적으로 사용하지 말 것
- 그러나 '압존법'을 분명히, 경우에 맞게 사용할 것
 
3. 이메일 본문 작성의 핵심
- 제목에서 언급한 내용으로 먼저 시작할 것
- 문장은 항상 두괄식으로 작성할 것
- 불필요한 문장으로 이메일의 핵심을 흩뜨리지 말 것
- 달리 해석할 수 있는 함축적인 문장과 단어를 사용하지 말 것
- 상대방을 앞에 두고 이야기한다고 상상하며 이메일을 쓸 것
- 민감한 사안이라면 반드시 '구두로 먼저 이야기'하고 이메일을 쓸 것
 
>> 최대한 핵심을 간단하에 정리해서 보내는 것이 좋다.

4. 다른 기억해야 할 것들
- 보낸 이메일은 반드시 다른 사람에게 공개 된다
- 사적인 내용조차 반드시 공개 된다
- 이메일의 법률적 효력은 약하나 법정에서 참조 자료가 된다
- 한 번 보낸 이메일은 회수할 수 없으니 교정하고 또 교정해도 부족함이 없다
- 첨부 파일이 포함되었는 지 반드시 확인하라
- 이메일은 보조 커뮤니케이션 수단임을 명심하라, 진정한 커뮤니케이션은 면대면 대화다.

                                                                        출처 : http://i-guacu.com/1623

2008년에는 메일도 잘쓰고 오타도 없애는 한해를 만들어 보겠습니다.

모두 즐거운 구정 연휴 잘 보내세요!!

Posted by 박재현
,