벌써 10년 전의 일이군요. ㅎㄷㄷㄷ
완전 책을 만들어서 출품했었습니다. 아래아한글 97 이용.

사용자 삽입 이미지

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지

Posted by 사무엘

2010/01/13 01:18 2010/01/13 01:18
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/129

아래아한글 2007은 2006년 한글날에 출시되었던 초창기 RTM 판을 어둠의 경로로나 잠깐 구해 쓰다가 다시 2005로 돌아와 버렸고, 저는 그 존재감을 1년이 넘게 잊고 지내 왔습니다.

그런데 얼마 전 한 지인께서 보내 주신 아래아한글 2007은 정말 사뭇 달라진 모습이었습니다.
사실 아래아한글이 그 때 이후로 3년에 가까운 시간 동안 아직까지 메이저 버전업이 없는 상태이긴 하지만 그래도 제품 개선은 정말 꾸준히 돼 오고 있었습니다. MS 식으로 표현하자면, 단순한 버그/보안 업데이트 수준을 넘어 서비스 팩 정도는 된다는 거지요.

각종 패치와 업데이트를 다 받고 나니 버전은 7.5.8.527이 되었습니다. 아래아한글도 날개셋과 마찬가지로 비주얼 C++ 2003 (7.1)로 개발되고 있는 건 여전하고요.
윈도우 비스타에서 “시스템 스타일” 테마를 쓰면드디어 Aero 반투명 프레임이 적용된 대화상자가 나오더군요. (2005는 그렇지 않았음.) 윈도우 XP 시절엔 MS 오피스 2003 테마가 그럭저럭 볼만 했으나 비스타에서는 아주 밍밍하고 보기 안 좋은 모양이 돼 버리기 때문에 차라리 아래아한글 2007 특유의 기본 블루 메탈 테마나 시스템 스타일 테마가 낫습니다.

지금까지 아래아한글은 대화상자에서 숫자만 입력 받는 에디트 컨트롤의 동작이 정말 기괴했습니다. 글씨 크기나 여백량 등. 세벌식 자판을 쓰고 있으면, 2004 이하에서는 Shift+알파벳의 고유 숫자도 동작을 안 하고, 0~9의 쿼티 숫자 배열도 동작을 안 해서 꼼짝없이 글자판을 바꾸거나 numlock 키패드만 써야 했습니다. 그러던 것이 2005에서는 Shift+알파벳 숫자는 인식되도록 개선됐고, 2007에서는 숫자 입력란에서는 아예 한글 글자판이 동작 안 하고 무조건 0~9 숫자만 인식하게 바뀌었던데 저는 차라리 이런 결정을 환영합니다. 정말 속 답답하던 동작 방식이었는데 무척 잘 했습니다.

글꼴을 고르는 콤보 박스가 화살표 키 선택만 가능한 게 아니라 이름을 입력도 해서 빠르게 찾을 수 있게 된 것은 매우 환영할 만한 기능. 비주얼 C++ IDE는 2003에서 2005 이후로 넘어가면서 이런 점에선 오히려 퇴보했죠. (물론 글꼴이 주류인 프로그램은 아니지만.)

그리고 운영체제 한글 IME로 비완성형 문자가 ?로 바뀌고 제대로 입력되지 않던 버그.. 드디어 고쳐진 것을 확인했습니다. 이제 아래아한글로도 <날개셋> 한글 입력기를 띄워서 각종 확장 한자나 옛한글까지 그대로 입력할 수 있습니다.

어떤 프로그램이 유니코드를 얼마나 잘 대비해서 만들어졌는지 측정하는 좋은 척도 중 하나는 파일 이름 인식인데요.
제가 보기엔 아래아한글은 아직도 윈도우 9x를 지원하느라, 혹은 TCHAR 같은 범용 자료형으로 Unicode-prepared된 코드를 작성해 놓지를 못해서... 하이튼 이 둘 중 한 이유로 인해 과감하게 스위치를 유니코드로 바꿔서 빌드 못 하고,
당장 유니코드 문자 지원이 절대적으로 필요한 부분에다가만 유니코드 함수를 임시방편으로 끼워넣은 거라는 인상을 받습니다. 윈도우 XP sp2 이상만 지원하는 MS 오피스 2007과는 달리, 한컴 제품은 똑같은 2007이 무려 윈도우 98 이상을 지원한다고 명시하고 있지요.. 물론 날개셋은 윈도우 95/NT4까지 다 지원.. 그러고도 유니코드도 100% 지원하죠.

임시방편이라고 생각하는 근거를 말씀드리자면..
영문 윈도우에서 HWP 파일은 한글이 섞인 파일도 잘 불러옵니다. 한글이 섞인 디렉터리 이동도 되고 파일 열기도 대화상자와 drag/drop 방식 모두 잘 되더군요. 이것만 해도 크게 개선된 것입니다. 하지만 HWP가 아닌 TXT 파일은 열리지 않았습니다. 더구나 “다른 프로세스가 파일을 사용 중이어서 열 수 없습니다”라고 에러 메시지도 ‘잘못’ 나오고요.따로 처리할 이유가 전혀 없는데도 파일 타입에 따라 유니코드 API 사용 여부를 따로 처리하고 있으니, 일관성 있는 처리가 아니라 HWP에다가만 임시방편 처리를 추가한 거라는 결론을 잠정적으로 내린 것이죠. 또한 ‘열기’ 대화상자라든가 타이틀에 뜨는 문서 파일 이름이 여전히 ???? 로 바뀌어 나온다는 것도 개선돼야 할 것입니다. 진짜로 여기서는 Ansi, 저기서는 유니코드 API를 섞어 쓴 것입니다.

한편, 아래아한글도 드디어 2007 나중판에서는 문서를 PDF로 저장? 인쇄? 하는 기능이 자체 포함되었습니다. 예전에 별개의 제품으로 팔던 PDF converter 엔진이 그대로 포함되어, 자체 글꼴인 HFT까지도 깔끔한 PDF로 바꿔 줍니다! 2.5 확장팩 시절의 추억의 신명 시스템 글꼴과 3.0/96 때의 #로 시작하는 수많은 글꼴들을 이제 깔끔한 PDF로 만날 수 있어 무한 감개무량하며 앞으로 아래아한글 쓸 일이 더욱 늘 것 같습니다.

단, 하나 옥의 티를 찾았는데요.
HFT 영문 이탤릭 글꼴이 PDF로 제대로 인쇄되지 않고 그냥 normal 글꼴을 기울인 형태로 바뀌어 버리더군요.
아래아한글이 내장하고 있는 신명조와 윈도우 운영체제가 내장하고 있는 바탕은 둘 다 ‘한양 시스템’에서 제작했으며 원도가 거의 일치합니다. 물론 후자가 영문의 폭이 좀더 크긴 하지만 비슷하죠.

하지만 둘의 큰 차이를 하나 꼽자면 전자는 영문에 이탤릭 전용 글꼴이 있다는 것입니다.
더구나 아래아한글 2.5 정도에서 추가된 걸로 기억하는 수식 전용 글꼴은 당시 교과서와 문제집 같은 출판물에서나 볼 수 있던 그 자형을 재현한 것이어서 더욱 의미가 컸습니다. 이것도 이탤릭체가 없으면 거의 무용지물이죠. 이것이 PDF로 만들면 여전히 되살아나지 않으니 개선이 필요하다고 봅니다.

끝으로 이건 극소수 매니아 계층 이외에게는 거의 의미가 없을 내용이지만 제품의 완성도 차원에서 하나 언급하겠습니다. 아래아한글의 한자 코드 체계와 관련이 있는 내용입니다.
아래아한글 2.0 이후에서부터 추가된 약 11000여 자의 제 2 수준 한자는 유니코드 BMP 영역에 대부분 이미 존재하지만(A급), 어떤 건 BMP에 없고 무려 surrogate 영역(B급)까지 가야 하는 것도 있으며 어떤 건 아예 유니코드 자체에 아직 정식 등재되지 않은 것(C급)도 있습니다. 물론 유니코드 버전이 계속 올라가면서 C급 한자라는 집합은 완전히 사라질 수도 있지요. 지금도 C급 한자는 거의 10여 자 남짓밖에 안 됩니다.

아래아한글은 이미 제 2수준 한자와 유니코드 사이의 변환 테이블도 다 갖추고 있고 이를 문자표에다 제공하고 있습니다. 하지만 정작 한컴 2바이트 코드로 저장된 파일을 가져와 보면 아래아한글이 지금처럼 유니코드 surrogate를 정식 지원하기 전에 워디안/2002 시절에 임시로 사용하던 변환 테이블을 여전히 수정하지 않은 것 같습니다.
가령 B급 한자에 속하는 0x531C는 한중일 통합 한자 확장 B인 U+20850 (surrogate 영역)이지만 이 글자를 한컴 2바이트 코드로 저장하여 불러와 보면, 옛날의 임시 주소인 U+A700이라는 엉뚱한 문자가 되지요.

아래아한글은 97에서 워디안으로 넘어갈 때 정말 큰 진통을 겪긴 했지만 그래도 그때 고비를 잘 넘긴 것 같습니다. 그때 HWP 파일 포맷이 딱 바뀐 이후, 지금은 아랍 어, 세로쓰기, 문서 워터마크 등 문서의 뼈대 구조를 결정하는 굵직한 기능이 엄청 많이 추가되었음에도 불구하고 워디안부터 2007까지 파일 포맷이 근본적으로 바뀌는 일 없이 하위/상위 호환성이 잘 유지되고 있으니까요.

다음 버전(아마 2010)은 지금 MS 오피스 다음 버전이 추구하고 있는 것과 마찬가지로 ODF 스펙 구현이 몰두 중이라고 합니다. 개인적인 생각은 아래아한글도 어서 워드처럼 개체가 사각형이 아닌 모양으로 본문을 감싸는 기능이 지원돼야 한다고 생각합니다. 앞서 지적했지만 유니코드 지원도 강화돼야 할 것이고, 좀더 욕심을 부리면 워드처럼 TSF A급 프로그램으로 발전하고 한양 PUA가 아닌 유니코드 낱자 결합 방식으로 옛한글을 지원해야 할 텐데, 참 가야 할 길이 멀군요!

Posted by 사무엘

2010/01/11 09:43 2010/01/11 09:43
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/65

※ 1기: 1.x 커널

아래아한글 1.x 시절의 에디팅 엔진입니다. 잘 알다시피 단순한 plain text에다가 약간의 서식만 붙은 것 같은 초보적인 형태였죠.
글씨의 크기 조절은 가로 확대/세로 확대만 되고 가변폭 글꼴은 사실상 지원되지 않았으며, 문단 여백도 그냥 칸 수로 지정하던 시절이었습니다. 표는 선그리기 기능으로 그려야 했습니다.
문서의 파일 포맷은 최소한 1.0, 1.1, 1.2 이렇게 세 방식 이상이 존재했던 것 같습니다. 아래아한글 1.5x는 1.2 방식과 문서 파일 포맷이 동일하며, Alt+V (새 이름으로 저장)를 누르면 과거 1.1 방식으로 저장도 할 수 있습니다.

※ 2기: 2.0 커널

1992년에 출시된 2.0부터 97까지 굉장히 장수하여 안정화한 한컴 2바이트 코드 기반의 에디팅 엔진입니다. 글씨 크기를 포인트로, 여백은 mm 같은 단위로 지정할 수 있게 되고 색깔도 8종류 중 하나로 지정할 수 있게 됐습니다. 가변폭 글꼴의 표현이 가능해지고 그림, 표 같은 각종 개체를 넣을 수 있게 됐습니다. 개요, 스타일 같은 개념도 생겼죠.

문서 파일 포맷은 2.0, 2.1, 3.0으로 나뉩니다. 사실 아래아한글 2.1은 기능면에서는 2.0과 그렇게 큰 차이가 없으나, 글꼴 쪽으로 굉장히 많은 변화가 생겼고 또 2.1에서 문서 압축 저장이 추가됐기 때문에 포맷이 바뀐 것으로 기억합니다. 아래아한글 2.5는 파일 포맷의 변동이 없었기 때문에 2.1과 포맷이 동일합니다.
3.0은 하이퍼텍스트라든가 자체 벡터 드로잉 기능, 그리고 윈도우 OLE 데이터 같은 것을 저장해야 하는 데다, 때마침 2.1 방식 문서 파일의 암호가 크랙되어서 큰 논란을 겪기도 했기 때문에 바뀌었지 싶습니다.

※ 3기: 21세기 커널

정말 많은 우여곡절을 겪은 워디안 때부터 지금까지 큰 변화 없이 이어지고 있는 에디팅 엔진 겸 파일 포맷입니다. 아마 아래아한글은 앞으로 이 방식에서 더 바뀔 일이 없을 것 같습니다.
문자 인코딩이 시대의 조류를 따라 드디어 유니코드로 바뀌고 글씨라든가 용지의 크기 제한이 완전히 사라졌습니다. 색깔도 RGB 어느 색으로나 줄 수 있게 되었으며, 여러 쪽에 걸치는 표처럼 MS 워드의 앞선 기능을 대폭 수용하여 2.0 시절 커널과는 비교가 되지 않는 많은 기능들이 추가됐습니다.

더구나 워디안 이후로 아래아한글은 과거에 없던 여러 기능이 추가되고 있음에도 불구하고 예전과는 달리 파일 포맷의 하위 호환성은 비교적 잘 유지되고 있는 것 역시, 처음에 파일 포맷 설계를 확장성 있게 잘 한 덕택이라고 볼 수 있습니다.
아래아한글도 이제 open xml 기반 문서 파일 포맷도 적극 도입해야 하지 않나 싶습니다만 과연 실현될지?

- MS 워드의 경우 97~2003 커널이 가장 보편적으로 널리 쓰이다가 2007에 와서는 에디팅 엔진과 파일 포맷이 또 크게 바뀌었지요. 95 그 이전 기수는 잘 모르겠네요.
개인적으로 워드보다도 엑셀에서, 편집 가능한 셀 수가 크게 증가하고 색깔 제한이 없어진 것을 매우 환영합니다.

Posted by 사무엘

2010/01/11 00:37 2010/01/11 00:37
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/56

아무리 MS 워드가 다른 기술이 월등하고 훨씬 더 프로페셔널하고 무엇보다도 파일 포맷이 국제적으로 널리 통용되고 다 좋다고 하나, 아래아한글의 비장의 무기들.

글자 모양/문단 모양을 구분할 수 있는 속성 복사 Alt+C

그리고 Alt+B 키매크로. MS 제품에도 심지어 비주얼 스튜디오에는 키매크로가 있습니다. Visual Basic 기반의 더 복잡하고 전문적인 매크로 이전에 이런 게 없나 궁금합니다. 키매크로는 차라리 과거의 도스용 아래아한글만한 시절이 없었죠.
사실 매크로, 핫키 정도는 과거 윈도우 3.1의 “레코더”처럼 운영체제 차원에서 유틸이 하나쯤 있어야 합니다. 너무 초보자 위주의 마우스 GUI에만 치중하다 보니 GUI 운영체제들은 컴퓨터를 정말로 효율적으로 활용하게 해 주는 자동화, 프로그래밍, 일괄 처리 기능이 너무 미약하죠.

하나 더, 특정 스타일을 바로 지정하는 Ctrl+숫자 단축키. 이거 정말 워드에는 없나 궁금합니다.
사실 이따금씩은 도스 시절의 잔재인 “글꼴 단축키”가 아쉽기도 합니다. 블록 잡고 Alt+L, K, T, C, D 끗. (한글 폰트를 ‘견명조’로 바꾸기 ^^)

단축키가 더욱 빛을 발하는 또다른 분야는 표입니다. 저는 비슷한 난이도의 표 문서를 아래아한글과 워드로 모두 작성해 봤습니다. 셀 블록 잡기, 병합, 분할, 서식 지정 등등.
지켜보는 사람도 말하더군요. “님은 아래아한글 쓸 때는 대부분 양손이 키보드에 가 있고 단축키로 하는데, 워드는 꼭 스타 하는 것처럼 마우스 움직임이 복잡하고 많네. ㄳ”

워드 2007에서 표 작업 정도 하려면 ‘아래에다 셀 삽입, 셀 제거’ 같은 자주 쓰는 기능을 간추려서 Quick Access Toolbar에다가 옮겨놓기부터 먼저 해야 합니다. Home, Table 이런 리본들 왔다갔다하다 보면 정신 없습니다.

물론 워드가 훨씬 더 합리적으로 기능 잘 제공하는 것도 많습니다. 가령, 여러 아이템을 클립보드에다 복사해서 골라가며 붙이는 게 실무에서 이렇게 유용한 줄은 몰랐습니다. 오피스 2000부터 추가된 기능이죠.

아래아한글은 기본적으로 2.0 시절부터 표를 그림이나 문자 같은 동일한 개체라는 개념으로 봐 왔습니다. 그래서 여러 페이지에 걸치는 표는 2002에서 에디팅 엔진을 새로 디자인할 때에야 드디어 가능해졌습니다. 하지만 워드는 애초부터 표는 레이아웃의 일종으로 구현되었으며, 아래아한글처럼 표 전체를 한 글자처럼 취급하는 기능이 없습니다. 이건 HTML의 구조와도 비슷하죠.

아래아한글이 2.0 이래로 별다른 변화 없이 제공해 온 개체 배치 방식은 저는 완전히 이해하여 프로그램과 제가 일심동체가 되어 있는 반면, MS 워드가 개체를 배치하는 방식은 저는 나름 97 이래로 워드를 쓰고도 아직도 알쏭달쏭입니다. 내가 이렇게 바꾸면 프로그램이 이렇게 딱 동작할 거라는 확신이 없습니다. ㅜㅜ

서식 지정하는 방식, 특히 불릿/개요 같은 문단 속성도 마찬가지. 아래아한글은 딱 프로그래머스럽게 동작하는 반면 워드는 정말 제멋대로.. 그 미묘한 감각 차이는 아래아한글처럼 독학 자습만으로는 도저히 습득을 못 하겠습니다.

워드와 아래아한글은 서로 정말 극과 극에 가까운 다른 철학으로 디자인된 프로그램이라는 건 두 프로그램을 모두 중급 이상 활용하는 분이라면 누구나 공감할 것입니다. 저는 이미 초등학교 고학년 때 그림, 표, 메일 머지, 목차, 각주, 스타일, 개요 등등 아래아한글 2.X 전기능을 마스터한 반면 워드는 성인이 된 지금도 아직까지 그 동작 알고리즘이 뿌옇게 흐리게만 보입니다. 한 프로그램의 철학에 익숙한 사람이 다른 프로그램에도 능숙해지기는 어려운 장벽이 있습니다. 그래서 두 프로그램 중 하나가 쉽게 없어지지는 않을 것입니다.

워드에는 아래아한글처럼 매 언어별로 글꼴의 상대 크기와 장평, 자간을 세밀하게 맞추는 기능이 아쉽고, 아래아한글에는 워드처럼 사각형이 아닌 개체의 실제 모양대로 글자가 흐르는 어려운 기능, 아주 정교한 서식들(덧말, 첫 글자 자동 키우기 등, 아래아한글에도 없지는 않으나 글자 배치가 워드에 비해 완성도가 떨어짐) 같은 게 아쉽습니다.

아래아한글이 2004에서야 surrogate를 지원하기 시작하고 2005부터 아랍/히브리 문자를 제대로 지원하기 시작한 건 굉장히 늦은 감이 있지만 바람직한 향상이라 생각됩니다. 그나저나 2005는 2007에서 잘 쓰던 과거 신명 시스템 글꼴들을 왜 인식을 못 하나 모르겠습니다. 태 시스템 것만 인식되네요. (태 가는 헤드라인) ㅜㅜ

Posted by 사무엘

2010/01/10 23:52 2010/01/10 23:52
,
Response
No Trackback , 5 Comments
RSS :
http://moogi.new21.org/tc/rss/response/42

※ 1.x 시절

윤곽선 폰트라는 개념이 없던 시절엔 도트용과 레이저용이라는 기묘한 구분이 있었습니다.
레이저용이라고 해 봤자 겨우 300dpi짜리 프린터였는데, 그때는 그 고해상도 비트맵 글꼴만 해도 제작 비용이라든가 컴퓨터 상의 처리 부담이 만만찮았습니다.
레이저 프린터용 자형의 존재 여부가 한 프로그램의 에디션을 구분하고 복사 방지장치 장착 여부를 결정한 것이나 다름없습니다.

※ 2.0, 2.1

일반용과 전문용으로 구분했습니다. 가격 차이는 거의 2.5배 정도.
글씨를 자유롭게 확대할 수 있게 되었기 때문에, 일단 레이저 프린터용 비트맵 자형도 일반용에 기본 내장은 되는 '거저 먹는' 양상이 되었습니다.
아래아한글 2.0은 우리나라 소프트웨어 역사에 그야말로 획기적인 한 획을 그었습니다.
하지만 컬러 인쇄와 윤곽선 글꼴, 맞춤법 검사기 같은 기능은 전문용에만 있었지요. 윤곽선 글꼴이 없었으니 일반용은 글씨 크기 조절이 사실 별 의미가 없었습니다.
전문용은 락이 걸렸습니다. 그리고 2.1 전문용은 386 전용 코드로 개발되었습니다.

※ 2.5

드디어 2.5에서 일반용과 전문용이란 구분도 없어지고, 대신 86, 386 코드 에디션 구분이 생겼습니다. 86 에디션은 제 기억으로 덧실행, 맞춤법 같은 기능이 없는 거 빼고 문서를 만드는 기능상으로는 거의 차이가 없습니다. 286 AT 기종에서도 드디어 컬러 인쇄와 윤곽선 글꼴을 구현해 냈습니다. 눈물나게 감동스럽습니다.
다만, 2.5부터는 영한사전, 추가 확장 글꼴 같은 '확장팩'이란 개념이 생겼고, 확장팩에만 락이 걸렸습니다. 락이 없으면 영한사전 메뉴는 비활성화됐고, 신명시스템 글꼴은 아무 말 없이 그냥 동작하지 않고 명조로 대체되어 나왔죠. "한글과컴퓨터 2"라는 폰트 드라이버 자체가 락이 걸렸던 것 같습니다.

※ 몇 가지 중요한 사실

- 아마 2350자에 없는 비완성형 한글에 대해 최초로 동작한 윤곽선 글꼴은 2.1에서 추가된 휴먼 안상수체 계열의 조합형 글꼴입니다.
- 신명조가 비완성형 한글과 옛한글까지 윤곽선화한 건 2.5나 3.0때부터입니다. 제 2수준 한자가 윤곽선화한 것과 시기가 비슷합니다.
- 1.X 시절부터 있던 샘물과 필기체는 정확하게 2.5에서 윤곽선화했습니다.

- 윈도우용 아래아한글 3.x에서부터 2.5 확장팩 글꼴이 락이 풀린 형태로 제공되기 시작했습니다. 윈도우용 버전은 기존 도스용 2.5의 락이 걸린 확장팩 글꼴도 바로 읽어들였을 뿐만 아니라, 3.0용 확장팩 자체도 락이 풀려서 도스용 2.5에다가 복사하면 바로 읽을 수 있는 형태로 글꼴이 들어있었다는 뜻입니다. 사용하는 폰트 드라이버가 "한글과컴퓨터 2" 대신 일반 "한글과컴퓨터"로 바뀌었습니다.

Posted by 사무엘

2010/01/10 22:43 2010/01/10 22:43
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/18


블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/11   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Site Stats

Total hits:
2991372
Today:
383
Yesterday:
2549