OPEN HWP의 재진행에 관한 의견을 듣고 싶네요

저도 이 의견에 100% 동감합니다.

리눅스용 한글 반드시 필요하다고 봅니다.

어떤 OS 에서건.. 워드프로세서는 당연히 있어야 하니까요..

하지만 한글의 opensource 프로젝트의 가장 큰 문제점은 하나입니다.

바로 한글 파일을 열수 있느냐? 하는 것이지요

만약 opensource 에디터로 만든다면 반드시 한글과 같은 모양의

프로그램이 될 필요는 없다고 봅니다.

하지만 한글에 있는 파일은 열어야 된다고 봅니다.

그러려면 우선 선행되어야만 하는 과제는 한글의 파일포멧의 open 입니
다.

만약 이것을 널리 공개한다면 오픈 한글의 가능성은 있다고 봅니다.

제가 아직 나이가 어려 잘 알지는 못하지만. 옛날에 openHwp 프로젝트가

있었다는 소리를 듣고 상당히 놀랬습니다.

저도 한때 (멀지않은 과거지만.) 한글과 같은 프로그램을 짜 봤으면 하
는

생각을 해 봤습니다. 하지만. "나만의 포맷을 사용한다?" 이것은 어쩌면

온 국민이 사용하는 "워드프로세서" 라는 점에서는 무의미한 것이 될 수
도

있으니까요..

프로그램에서 각각의 파서를 불러들여 각각의 포맷을 보여줄수 있고.

또 그 자신만의 포맷이 존재해도 상관은 없다고 봅니다.

만약 한글의 저장 포맷에 대해서 아시는 분이 계시다면

이 글의 답글로 달아주시면 좋겠지요... ^_______^

언젠간 누군가가 취미로 한번 만들어 볼 날이 올지도 모르지요..

전에 쓰신 분들의 내용을 보니 자체적인 파일 구조를 가져가자고 하셨는데요.

windows를 사용하는 사람들이 linux를 사용하기 힘든 이유중 하나가

windows의 파일을 linux에서 읽기 힘들기 때문이 아닐까요?

저는 HWP파일이 linux에서도 그대로 읽을 수 있었으면 좋겠네요.

하나 추가해서 html 편집 기능까지 있으면 더 좋을테구요.

아래한글의 강점은 뭐니 뭐니 해도 '표'에 있으니까요.

OPEN HWP를 위한 기획 초안입니다.

0. 문서에 관한 정보

가장 기본적인 정보들로 볼 수 있다. 작성자, 미리보기를 위한 그림규격이
라든지, 문서의 버젼
등과 같이 순수하게 문서에 관한 정보를 저장하기 위한 헤더이다. 파일 시
스템이 기록하지 못하는
사용자 편의를 위한 잡다한 내용들이 기록된다.

1. 문자열에 포함될 수 있는 것들

일반적인 텍스트 에티더에서는 보이는 것이 전부이다. 즉, 화면상에 나타
난 문자가 전부인 것이다.
그러나 워드프로세서에 있어서는 화면에 나타난 문자들 외에, 문자의 크
기, 정렬, 자간, 행간 등의
많은 정보가 함축되어 있다. 또한 문자열 사이에는 문자열만 존재하는것
이 아니라

1.1 문자열

단순한 1자의 문자를 표현하는 순수한 문자들의 열를 의미한다. 이러한 문
자열은 시작지점의 포인터를
표현하는 방법이 많이 쓰이고 있다. 몇십만자가 되는 문서에서 문자 하나
를 삽입하기 위해서
몇십만번의 메모리 이동을 일으킬 수 없으므로 텍스트 에티더에서는 라인
별로 연결리스트를 구축하고
한 라인이 하나의 포인터를 이용하는 방법을 사용하고 있다. 그러나 워드
프로세서에서는
페이지의 폭이나 글상자의 폭에 의해서 한행에 존재하는 글자수가 조절되
므로 글상자의 크기가 라인별로
연결리스트를 연결한다면 글상자의 크기가 바뀔 경우 연결리스트를 완전
히 재구성해야 하므로
문단별로 연결 리스트를 구축해야 한다.

1.2 문단에 관한 정보

문단에 관한 정보는 오른쪽, 왼쪽, 가운데, 배분정렬이 대표적인 것이다.
문단에 적용되는 기본 문자속성이나
특정한 문단에 일괄적으로 스타일을 적용할 시에도 문단에 관한 정보를 구
축해 두는것이 좋다.
앞 절에서 문자열에 관한 정보에서 문단별로 연결리스트를 구성하게 문단
객체를 구성하여 문자열(나중에
설명될 것이지만 정확하게는 객체열이 되어야 할 것이다.) 포인터와 함께
문단 정보를 구성하는것이 좋겠다.
그리고 문단에 적용되는 문단사이 간격이나 문단별로 첫자 크게 키우기,
문단앞에 한칸 띄우기 기능, 텝
등과 같은 내용되 모두 문단에 관한 정보에 저장될 수 있다. 흔히 문서위
쪽에 눈금자와 함께 붙어 있는
조그만 슬라이더에 관한 정보들이다. 문단사이간격에 관한 정보는 우리나
라에서는 잘 쓰이지 않지만
HTML문서에서 문단을 뜻하는

테그가 2칸이 떨어지는 것을 보면 사용처
를 쉽게 알 수 있을 것이다.

1.3 문자 속성에 관한 정보

문자 속성에 관한 정보를 부여하는 방법은 여러가지가 있을 수 있다. HTML
처럼 테그와 같은
특별한 기호로 문자 속성을 표현하는 방법과 각각의 문자에 대응하는 문자
의 상태를 표현하는
바이트는 두는 방법이 있다. 문자의 상태를 표현하는 바이트를 두는 방법
의 경우는 문자의
속성의 종류가 바이트가 감당할 수 있는 이상의 정보가 있을 경우 자료구
조가 수정되어야 한다는 점과
대부분 같은 문단에서는 같은 문자속성을 유지하고 있기 때문에 계속적으
로 각각의 문자에
속성에 관한 정보를 요지하는 것은 비 효율적이다. 따라서 HTML과 같은 방
법이 나은 선택이 된다.

UNICODE로 이루어진 문자열을 진행하다가 약속된 코드(문론 실재 문서상에
는 들어갈 수 없는 혹의 거의
사용될 수 없는 코드중 하나를 뽑아서 사용한다.)를 4개로 시작하여 문자
열내 삽입된 객체의 시작임을
표현하고 객체의 포인터를 기록한 다음 같은 코드 4개로 닫아준다. 문론
파일에 기록될 때는
직렬화 기법을 써서 이 사이에 실제로 객체에 관한 내용이 기록될 것이
다. 4개의 약속된 코드로 객체의
시작임을 알리고 다음에 객체의 종류를 표현하는 ID를 써서 객체의 정보
에 따른 원하는 코드가
수행될 수 있도록 한다. 문자 속성객체가 존재한다면 문서를 파싱해서 표
현하는 부분에서
문자의 속성을 변경하는 동작을 수행하면 될 것이다.

문자 속성에 관한 정보가 일단 지정되면 시작점부터 문단 끝까지 같은 형
태의 문자를 볼 것이다.
만약에 특정한 부분까지 원하는 글자의 종류를 지정하고 싶으면, 다시 원
래의 글꼴로 돌리거나
디폴트라는 뜻을 간결하게 표현하는 객체를 이용한다.

1.4 문자열내의 삽입 객체

문서 사이에 삽입될 수 있는 객체의 종류는 많다. 그림일 수도 있고 글자
일 수도 있다.
어떤 종류이든 간에 각각의 객체에 따른 정보를 유지하고 있고 객체의 상
태를 표현하기 위한
뷰 모듈과 객체의 상태를 변경하기 위한 인테페이스 모듈을 가질 수 있다.

뷰 모듈은 객체의 정보를 표현하는 것으로 객체가 글자 사이에 위치하게
될때 가질 수 있는
사각 영역이 있다. 이 사각형 공간 안에 객체가 가지고 있는 정보는 표현
하는 역활을
하는것이 뷰 모듈이 된다. 그림 객체라면 그림을 화면에 뿌려주는 코드가
있을 것이고
수식 객체라면 수식을 해석해서 주어진 사각 영역에 뿌려주면 된다. 윈도
우의 OLE도 비슷하다.
워드가 가지고 있는 고유의 내장객체에 대해서 OLE(혹은 다른 표준을 준수
하는)형태로
처리할 수도 있고 고유의 방법으로도 처리할 수 있을 것이다.

인터페이스에는 기본적으로 삽입 객체의 사각영역을 처리하는 기능이 기본
적으로 필요하고
(크기조절, 박스넣기같은 기능들) 기타 부분은 표준에 부합하거나 그렇지
않으면
마우스 오른쪽 버튼에 포함되는 메뉴의 일부분으로 들어갈 수 있을 것이
다. 여기서
발생한 메시지는 당연히 객체의 상태를 변경하는 코드와 연결되어 있다.

1.5 문서 정보에 관한 객체

특정한 지점에서 문서가 작성된 날짜나 편집자, 쪽번호 등이 포함되기를
바랄 수 있다.
이러한 기능은 주로 머릿글이나 꼬리글같은 마스터 페이지적인 요소에 삽
입이 되지만
페이지 표현과 같은 기능을 수행하기 위해서 특별히 예외적인 상황을 만들
지 않기 위해 필요하다.
꼬릿글에 대하여 워드의 고유기능으로 삽입할 수 있는 특별한 글상자가 아
닌 많은
글상자들의 일부로 여겨질 수 있으면 거기에 글자뿐 아니나 표, 그림, 외
부객체같은 것들이
자유롭게 삽입될 수 있으며 함께 쪽번호를 표현할 수 있으면 훌륭하게 꼬
릿글의 기능을
수행할 수 있다. 또한 쪽번호의 위치나 장식같은것도 세세하게 표현할 수
있다.

2. 페이지

페이지라는 객체는 B5나 A4같은 용지의 크기에 관한 정보 외에고 페이지
에 위지하고 있는 글상자의
개수와 크기 그리고 떠있는 객체들을 가지고 있다. 떠있는 객체에 관해서
는 나중에 설명할 것이다.
각각의 페이지는 순서적인 관계를 유지하고 있으며 쪽번호라든가 적용을
받는 마스터 페이지
등을 가지고 있다.

2.1 조판

조판이란 무었인가? 그것은 문서가 가지고 있는 정보를 적절한 형태로 배
열하는 작업이다.
많이 알려져 있는 조판작업 중에는 단 나누기가 있다. 1단 짜리 문서는 한
페이지에 하나의
글상자 만이 존재하며(문론 떠있는 객체가 여기 포함되지는 않는다.) 여기
에 연속적으로
정보가 배열된다. 파서는 문자열에 관한 정보를 해석하여 프린터나 화면으
로 문서가
가지고 있는 정보를 출력하면 된다. 그리고 한페이지가 끝나면, 나머지 정
보를 다음
페이지의 글상자로 넘긴다. 그래서 결국 모든 정보가 다 표현될 수 있다.

다단의 경우를 들어보자. 다단은 같은 글상자가 한 페이지에 좌우로 배치
되어 있는 형태이다.
페이지는 하나이지만 한쪽 글상자를 완전히 채우면 다른쪽의 글상자로 이
동한 후에 나머지
정보를 계속해서 표현한다. 조판이 복잡해지면 각각의 글상자가 마구 배치
될 수 있다.

각각의 페이지에는 각 글상자들의 배치와 문자열들이 글상자에 표시되는
순서서가 기록될
것이다. 3~4 단의 문서나 그 이상의 복잡적인 경우에되 같은 개념으로 처
리될 수 있다.
문론 일일이 알맞은 크기의 글상자나 조판의 흐름을 지정하는것은 매우 성
가신 일이므로
다양한 프리셋과 괜찮은 구역 편집기능을 제공할 필요가 있다.

2.2 떠있는 개체들

떠있는 객체들이란 문자열에 영향을 주지 않는 문자열과는 별개로 존제하
고 있는 문서 상의 그림이나
수식 혹은 다른 문자열을 내포할 수 있는 글상자 따위가 있다. 이러한 객
체에 관한 정보는 문자열
안에 포함되지 않아야 한다. 문자열의 내용이 삽입 및 삭제되는 것에 대하
여 이런 떠있는 객체의
정보가 삭제되거나 변경되는 일이 없어야 하기 때문이다. 떠있는 객체들
의 정보는 문자열에 삽입된
객체와 동일한 것이지만 그 포인터들은 페이지 객체가 가지고 있게 된다.

이러한 떠있는 개체들은 글상자 위에 바로 표현될 수도 있고 글상자의 글
자를 밀어내고 위치할 수도
있다. 각각의 글상자들은 위쪽의 떠있는 객체들을 감지하여 글자들의 흐름
이 재지정 되어야 한다.
따라서 글자들의 흐름에 관련한 속성이나 그외 문자열내의 삽입 객체들과
는 다른 몇가지 속성이
포함될 수 있다.

2.3 마스터 페이지

마스터 페이지는 좀 특별한 페이지들도 다른 페이지들처럼 순서적인 관계
를 유지하고 있지 않으며
연속적으로 표현되어 있는 페이지들 처럼 문서의 글이 들어가는 글상자를
가지고 있지도 않다.
그러나 그외의 내용은 일반적인 페이지와 동일하다. 이러한 마스터 페이지
는 다른 페이지의
배경으로 지정될 수 있다.

2.4 쪽과 문자열(객체열)과의 불일치 문제

글상자와 문서 사이의 불일치, 이것은 아주 심각한 것이다. 객체가 없는
순수하게 문자만으로
이루어진 문서의 경우를 고려해 보도록 하자. 편집중인 문서는 약 2000자
정도의 문자를
가지고 있고 문서의 편집자는 이것을 10페이지 정도에 나타내고 있다. 만
약에 1200자에
해당하는 지점에서 현재 페이지가 몇페이지인지 알고 싶다면 결과적으로
복잡한 연산을 통해서
모든 문자열들이 다시 표현되어야 한다. 만약에 12페이지에서 59페이지등
으로 아동하고자
할 경우에는 문제가 될 수 있다.

여기서는 앵커 객체같은것을 이용해서 페이지나 글상자사이에 문자열이 잘
리는 부분에 대하여
기록하는 방법이 사용될 수 있다.

3. 기타

3.1 메모리 부족에 관한 대책

작은 규모의 응용프로그램에서는 전혀 문제될 것이 없는 내용이지만 프로
그램의 규모가
커지면서 이러한 문제들이 나타난다. 스타크래프트에서 메모리가 부족해
서 더 이상의
유닛을 위한 정보를 가질수 없는 상황에 왔을때 일방적으로 프로그램이 다
운되어 버리면
이보다 난감한 일이 없다. 스타트래프트 같은 게임들에서는 메모리가 부족
하여
유닛을 더 만들수 없는 상황이면 유닛 생산이 더 안되는 장면을 볼 수 있
다.

워드와 같은 프로그램에서 메모리 부족을 이유로 문서를 한참 편집하다가
프로그램이
죽어버리면 그것보다 난감한 일이 없다.

작업 진행 과정에서 메모리 부족이 일어난 경우, 프로그램을 종료시켜서
는 안되며
객체를 생성하는 작업을 중단하고 사용자에게 대화상자나 혹은 그보다 시
스템 자원이
적게드는 방법으로 상황을 사용자에게 알려야 한다.

이러한 메모리에 관한 문제는 기반 객체를 디자인할때 메모리 부족시 객체
의
상태및 프로그램의 상태를 이전으로 돌리는 기능이 필요하게 된다.

3.2 파일 밎 메모리 오류에 관한 대책

비상업적인 프로그램들은 잘못된 파일을 입력받았을때 죽어버리는 경향이
있다.
파일등을 읽거나 객체의 정보를 읽어올 때 원하는 지점에 예상한 정보가
없어서
나머지의 내용을 엉뚱한 내용으로 착각하여 되지도 않는 메모리를 할당받
는 다든가

문서상에는 표현된수 없는 위체에 객체를 위치시킨다든가 하는 내용이 포
함된다.
이런 상황이 발생하면 즉시 문제가 발생하지 않더라도 문제가 될만한
코드가 수행됨과 동시에 프로그램이 죽어버린다. 프로그램을 수행하다가
OLE개체가 삽입된 부분을 보려고 문서를 스크롤 시키면 프로그램이 다운되
는
경우가 비슷한 경우이다.

따라서 파일형식에서 오류를 정정할 수 있는 규격을 마련하던가, 코드의
모든 부분에서
잘못된 값을 유효한 값으로 변화시키거나 하는 방법이 필요하다. 후자의
방법의 경우는
코드 전체에 걸쳐서 광범위하게 이루어지는 작업이기 때문에 작업에 있어
서의 명확한
지침이 필요하다.

기능 수행의 예

위와 같은 모델에서 몇가지 기능이 동작하는 과정을 한번 생각해 보기로
한다.

1) 떠있는 객체를 문자열 사이로 집어넣는 경우

떠있는 객체를 클립보드로 복사한다. 오리기를 하는 경우는 페이지로부터
떠있는
객체에 관한 정보를 삭제한다.

문자열의 중간에 커서를 두고 붙이기 명령을 내리면 클립보드에 있던 객체
가
약속된 기호를 붙이면서 문자열 사이에 삽입된다.

2) 2단 편집을 지정하는 경우

현재 페이지의 글상자에 관한 정보를 모두 삭제한다.

2단을 위한 글상자 2개를 페이지 정보에 삽입한다.

글상자에 따른 문자열 및 앵커정보를 갱신한다.

3) 그림이 포함된 꼬리글

마스터 페이지 객체를 생성한다.

사용자는 꼬리글의 위치로 적당한 지점에 떠있는 글상자를 배치한다.

글상자 안에 글과 객체를 배치한다.(문자열과 같은 규격이다.) 그리고
페이지 정보를 표시하는 객체를 문자열 내에 포함시킨다.

마스터 페이지는 매 페이지 인쇄될 때 마다 각 페이지의 매경으로 적용되
면서
지정해 둔 글상자안에 포함된 내용과 해당 쪽의 쪽번호를 표시할 것이다.

흠..

총대 매는 사람 1명이면 됩니다.

일 떠벌리고 주체를 맡을 그 사람이 없으면
어떤 일도 제대로 안되더군요

openhwp 도 왜 망했는지를...

과연 성공할 수 있을까? 아니 실패
한다. 왜? 개발자는 없고 사용자만
있으니까..

여기 기능이 어쩌면 좋게다고 안
내시는 분들 너무 큰 것 바라지 마
십시오. 이런 프로젝트 첨부터 넘
큰것 바라면 뻑 갑니다.

글고 나는 프로그램 잘못해서. 실
력이 없어서 못한다는 분덜 제발
생각좀 고치십셔.. 어차피
OpenSource 운동은 아마추어 프로
그래머가 중심입니다. 하다못해
Bug Reporting이라도 할수 있다고
왜 생각 못할까여??

--; 음 넘 흥분해꾸나..

지송~~

언제나 말은 쉽고, 행동은 어렵죠....
제발 이야길 끄냈으면 뭔가 결실이 있길 바랍니다.

실력 있는 사람 몇(3~ 4)명만 의기투합 해서 뭉치면
금방 될겁니다.

여기서 백명이 의견 다는 것 보다. 3~4명의 실력자가 뭉치는게
좀더 확실한 결과를 낼 수 있을 것같습니다.

실력 있으신 분들 제발 좀 뭉쳐주세요...
한국에서는 hwp가 거의 표준인데(관공서나 학계나..)
만약 OpenHWP가 성공한다면 다른 나라에서 우리나라를
부러워 할 겁니다.

TeX포매팅도 꼭 들어갔으면 좋겠네요.

제가 아시는분이 있었으면 좋겠더라고 하더라구요.
(그분이 말씀하시길 아래한글에 그게 들어있었으면 국내뿐만 아니라
세계적으로 사용되었을지도 모를거라고 하셨습니다.)

수학/물리/화학 같은 논문의 표준 포맷이기도 하고.
문서모델도 아주 잘되어 있는걸로 알고 있습니다.

(근데 이 주제랑 상관있는 얘긴가 몰겠네요. 무턱대고 생각난김에 적었는데..)

안녕하세요..
제가 생각하기에 필요한 것은 HWP 파일 형식의 공개입니다.
기존 HWP 파일과 호환되지 않는다면 다수의 HWP 사용자들에게
외면받을 것입니다. 일단 포맷만 주어지면, 거기에 따라
자료 구조나 문서 입력기, 문서 뷰어등의 소스가 작성될 수
있습니다.. 얼핏 듣기로는 한컴에서 HWP를 공개한다는
소식이 있었는데, 아마 소스를 공개하지는 않을 것이고
기껏해야 라이브러리, API 수준일 것으로 생각됩니다..
저는 이 때 HWP 파일 형식이 공개되기를 바랍니다..
그러면 OpenHWP 프로젝트가 생겨도 잘 되지 않을까 하네요..
그럼..

안녕하세요. 이병일이라고 함다.
오래간만에 kldp에 글을 올리는 군요...^^

성규님 글 잘 읽었습니다.
저는 예전에 OpenHwp 프로젝트에 관여를 한적이 있지요.
물론 개발에 참여할 실력이 안되서 폰트개발에 참여를 했었습니다만 어찌
어찌 하다보니 openHwp 프로젝트가 흐지부지 되더군요.

만약 다시 시작하게 된다면 이번만큼은 예전의 전철을 다시 밟지 않았으
면 하는것이 제 간절한 바램입니다.

도움이 될런지는 모르겠습니다만 당시에 openHwp의 개발이 중단된 이후로
Abi word를 한글화 하자는 의견이 있었고 잠시 진행이 되다가 프로젝트가
중단되었습니다.
그리고 당시에 논의 되던것중에 한가지가 한글코드에 관련된 내용입니다.
그 내용인 즉, 유니코드를 지원하되 첫가끝 조합문자를 사용하여 한글고어
까지 고려하자는 것이었읍니다.

만약에 다시 openHwp 개발이 시작된다면, 제가 개발에 참여할 실력은 되
지 않지만 제가 할 수 있는일은 하겠습니다. 몇몇 워드프로세서가 리눅스
용으로 나오고는 있지만 우리도 우리힘으로 워드프로세서를 만든다는거 좋
은일이라 생각합니다.
그럼...

안성규 wrote..
: 흘흘. 한글 워디안이 심하게 깨지는 걸 보구
: 이제 워드시장이 MS 워드로 주도권이 넘어가나 하는 생각이 듭니다.
: 개인적으로는.. 삼성에서 내놓은 훈민정음을 쓰고 있지만
: 인지도가 낮아서 파일공유같은 문제들에 대해서 불이익을 받고 있죠.
:
: 당연히 현재 인지도가높은 (개인적으로 MS워드.. 아주싫어합니다.
: 아래한글만큼이나 너저분한 기능들 - - ;) MS워드가 많이 사용될텐데..
: 그게 싫기 때문이죠...
:
: 특히나... 리눅서들같이 MS에 기대기 싫어하는 분들이시라면..
: 그렇다고, 저처럼 사용자층이 없는 훈민정음을(거의 삼성 자회사들만
: 쓰는걸루 알고 있습니다.) 권할수도 없는 것이고..
: 이참에... 한글 워드를 한번 만들어보는건 어떨가 생각중입니다..
:
: 흠.. 필요한건.. 한글입력기(현재 있지만 깨끗하게 돌아가지는 않는듯)
: TTF폰트 매니저(이것두 있죠..) 문서 객체 모델링... (좋은게
: 나오리라고 생가합니다..) 과 같은... 기반기술이 깨끗하게..
: 다듬어 지는것..
:
: 문서자료구조에 대한 모델링을 완전히 하는것..
: (가장 힘든 작업이 되겠죠... - - ;)
: 문서내에.. 여러가지 객체들이... 글자네 삽이되거나..
: 글자와는 관계없이.. 떠있을수 있어야 되겠고..
: 글상자 같은 곳은.. 문서를 제귀적으로 내포할수 있게
: 설계해야 하고...다시 말하면... 글이 아닌 수식이나
: 그림 그리고.. 다른 문서를 가질수 있는 글상자도 포함할 수
: 있는(표안의 표기능을 연상하시면 됩니다...)과 같은 '객체'
: 가 존재할 수 있는 형태의 포맷이 필요하죠..
:
: 가장 기본적인 기능은.. 수식이나... 그림과 같은 객체는
: 필요 없고... 글상자.. 표와같이 다른 객체를 내포할 수 있는
: 형태를 모델링하는게 중요하겠네요..
:
: 그리고 인쇄의 대상이 되는 규격에 관한부분 ..
: 마스터 글상자가 되나요?... 마진주는 부분이랑..
: 페이지 설정.. 마스터 페이지처럼 일괄적용되는 기능들..
:
: 흠... CORBA를 바탕으로 한... OLE같은 문서객체모델이 있으면
: 좋겠는데... 표준이 나왔는지는 잘 모르겠군요..
: 암튼 이런 표준이 제정되거나 준수되어서...
: 제체 기능이 확장되지 않고도 쉽게 '익스텐션'을 가질수 있어야 겠죠.
:
: 윈도우에서도 동작가능해야 하므로... 이 형태는 윈도우 버젼에서는..
: OLE로 쉽게 대체될 수 있어야 겠습니다. 국민 워드가 되기 위해서는
: 윈도우에 대한 지원은 안할 수 없죠..
:
: 일단 이정도네요.. - - ;
: 가능하겠죠?

저도 참가를 하겠습니다.

그런데, 기본 소스가 있어야 하지 않나요???

어떻게 구하지요..

아직 hwp 사업을 포기한 것도 아닐텐데....

멜 주세요...