서식을 지원하지 않는 단순한 텍스트 에디터를 워드 프로세서로 발전시키려면 무슨 작업이 필요할까?
뭐니뭐니해도 글자마다 서식을 달리 지정할 수 있어야 한다. (서체, 속성, 크기, 색깔 등등)
그런데 그걸 구현하는 과정에서 개념적으로 굉장히 중요한 결정을 내려야 하는 게 있다. 바로, 장치 독립적인(device-independent) 레이아웃을 구현하는 것이다.

장치 독립이란, 표시 화면의 해상도(=확대 배율)와 관계없이 글자들의 비율과 위치가 일정하게 유지되는 걸 말한다. 쉽게 말해 위지윅(WYSIWYG)이다. 요즘 워드 프로세서에서는 필수인 이 기능을 지원하기란 장치 종속 레이아웃보다 훨씬 더 어렵다.
우리에게 잘 알려져 있는 장치 종속 레이아웃과 장치 독립 레이아웃의 예는 다음과 같다.

장치 종속적 레이아웃: 웹브라우저 화면. MS 엑셀. MS 워드의 웹/개요 모드, Draft/normal view. 워드패드
장치 독립적 레이아웃: MS 워드의 인쇄 모드(print layout) view. 아래아한글, Acrobat PDF, 그리고 모든 프로그램들의 '인쇄 미리보기 (print preview)'

차이를 아시겠는가?

WWW
iiiiiiiiiiiii

가변폭 글꼴로 두 줄에 W와 i를 비슷한 폭이 되는 개수로 찍은 뒤(당연히 i의 개수가 훨씬 더 많아짐),
화면 배율을 아주 작게 줄였다가 아주 크게 확대해 보라.
W와 i의 폭의 편차가 크면 장치 종속적인 레이아웃이고,
대체로 전반적인 배율은 잘 유지되지만 그 대신 작은 크기에서 i들끼리의 픽셀 간격이 들쭉날쭉하다면(저해상도에서 보정을 위해 어쩔 수 없이) 그건 장치 독립적인 레이아웃이다.

엑셀을 실무에서 오래 써 본 분들은 이미 아시겠지만, 엑셀은 심지어 Page layout view에서도 위지윅이 전혀 보장되지 않기 때문에 화면에서 보는 글자의 폭과 인쇄해서 보는 글자의 폭의 차이를 유의해야 한다.
화면으로 보기 좋게 글자수나 폭을 맞춰 놓은 것은 인쇄를 하거나 심지어 확대 배율만 바꿔 봐도 모조리 어긋나 버리기 때문이다.
편집 화면이 아니라 오로지 '화면 인쇄'만이 장치 독립성이 보장되는 결과를 보여준다.
엑셀은 대용량의 데이터를 수월하게 다루기 위해서, 성능상의 이유로 위지윅 편의는 희생한 셈이다.

요즘 워드 2007은 처음 시작했을 때 인쇄 모드 view로 시작하지만, 옛날, 한 97~2000 버전까지만 해도 print layout이 아니라 normal view가 기본 모드였다. 아래아한글은 비슷한 개념으로 '쪽윤곽' 옵션이란 게 있어서 둘의 차이는 화면에 용지의 여백이 나타나 보이는지의 여부가 고작이지만, 워드의 normal view는 print layout view보다 훨씬 더 이질감이 컸다. 그림이나 표 같은 틀이 제 위치에 표시되지 않고 다단(column)이나 세로쓰기 같은 건 아예 무시되었으니까...;; 그리고 근본적으로 normal view는 앞서 말했듯이 위지윅이 보장되지 않는다.

이런 view가 기본 mode였던 이유는 두말 할 나위도 없이.. normal view가 문서를 훨씬 덜 정교하게 대충 렌더링하기 때문에, 처리 속도가 훨씬 더 빠르기 때문이었다.
normal에서 신나게 긴 글을 편집하고 있다가 print layout으로 처음으로 모드를 바꾸면, 워드는 “페이지를 정돈하고 있습니다. 잠시 기다려 주십시오”라고 뜸을 들이곤 했다.

장치 독립적인 레이아웃에서는 여백이나 글자 크기 따위를 나타낼 때 픽셀이 아니라 어느 매체에서도 동일한 절대적인 단위가 쓰인다. 그래서 아래아한글이라든가 PDF 같은 문서 파일 포맷 스펙을 보면 그런 개념을 찾을 수 있으며, 아래아한글의 경우는 1/n 인치가 최소 단위였지 싶다.

운영체제 API는, 해상도가 서로 넘사벽급으로 다룬 모니터와 프린터를 모두 동일 코드만으로 수월하게 다루기 위해서 다양한 추상적인 좌표계와 확대 배율을 지원하며, WM_PAINT뿐만이 아니라 WM_PRINT 같은 (잘 알려지지 않은) 메시지도 제공하고 있다.
MFC가 OnPaint말고 OnDraw라는 화면· 프린터 통합 메소드를 제공하는 것 역시 다 이유가 있어서인 것이다
.
흠, 그러고 보니 나도 포스트스크립트나 '텍' 같은 전자 조판 언어를 공부하고 싶긴 한데, 접할 기회가 없구나.;;

Posted by 사무엘

2011/08/19 09:03 2011/08/19 09:03
, , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/557

회사 동료가, 수백 개의 작은 그림 파일들을 엑셀을 써서 카탈로그처럼 일목요연한 표 모양으로 한데 정리해야 할 일이 있었습니다. 그 많은 그림들을 일일이 Alt+I, P, F로 삽입하는 건 사람이 할 짓이 못 되었기에 프로그래밍을 할 줄 아는 제가 좀 도와 줬습니다. 셀마다 각 파일들을 이미지로 담고 있는 HTML 표 코드를 생성하는 프로그램을 짠 후, 그 표를 엑셀에서 import하는 방법을 썼지요.

쉘 스크립트라든가 하다못해 엑셀의 매크로를 능숙하게 다루는 분이라면 더 쉬운 방법으로 이 문제를 해결했을지 모르나, 저는 그런 지식은 없었기 때문에 이런 일까지 비주얼 C++을 동원해서 해결했습니다.
그런데 문제는 다음부터였습니다. 이렇게 만든 엑셀 문서는 다른 컴퓨터에서는 그림이 보이지 않았습니다. 그림이 문서에 완전히 내장(embed; by value)되지 않고 링크만 저장되었던 것입니다(by reference).

저는 굉장히 당황하지 않을 수 없었습니다. 원래 MS 오피스의 제품에서 그림을 자체 기능으로 삽입하면, 그림은 기본적으로 문서에 완전히 내장됩니다. 링크라는 개념 자체가 사실상 없는 걸로 저는 알고 있었습니다.

그림을 주로 링크로 취급하던 대표적인 프로그램이 과거 아래아한글이었지요. 그래도 얘는 링크가 깨지면 그림이 있는 경로를 다시 묻기라도 했으며, 3.0부터는 그림을 문서 안에다 내장하는 기능도 추가되었습니다. 그림을 링크만 할지 문서에 내장시킬지를 얼마든지 쉽게 지정할 수 있으며, 한번 그렇게 한 후에도 한 상태로 된 그림을 다른 상태로 전환 역시 얼마든지 할 수 있습니다. 그렇기 때문에 전혀 어려울 게 없었습니다.

xlsx의 내부 구조를 들여다보고는 저는 기겁을 하고 말았습니다. 압축 파일 내부의 media 디렉터리에 아무 파일도 없는 걸로 보아 내장이 안 된 건 확실했는데, 이놈의 링크는 또 C:\로 시작하는 완전 절대 경로로 저장되더군요! 이런 이유로 인해, 상대방 컴퓨터에다가 그냥 그림 파일만 던져 준다고 해서 그림을 볼 수 있는 것도 아니며, 디렉터리 구조까지 완전히 일치해야 했습니다.

진짜로 문서 내부에 내장된 그림과, 이렇게 링크만 달랑 걸린 그림이 제각기 어떤 방식으로 저장되는지는 파악할 수 있었습니다만, 엑셀 프로그램 내부에서는, 아래아한글처럼 어떤 그림이 링크인지 내장인지 알려주거나 그 속성을 바꾸는 기능은 아무리 눈을 씻고 찾아 봐도 없었습니다! 이거 뭐 나더러 어쩌라고?

한국어 검색 엔진으로는 이런 문제에 대한 해결책도 거의 찾을 수 없어서 구글에게 영어 검색어로 의뢰를 해 봤지요. 통상 구글링을 해 보면 여러 해외 IT 분야 '지식인' 내지 포럼 사이트들이 검색되는 게 있습니다. 그런데 네이버 지식인 류와는 또 다른 게, 질문만 쏙 보여주고서 답변을 보려면 결제 내지 최소한 회원 가입은 해야 하는 형태인 게 많습니다. 딱 본인처럼, 그림이 들어간 HTM 표를 엑셀로 가져왔다가 나중에 낭패 본 케이스가 하나 있긴 했는데 답변을 보지는 못했습니다. 썅~

그래서 다음으로 생각해 본 방법은, xlsx의 내부 xml 코드를 고쳐서 문서 내부의 '링크 그림'을 '완전 삽입 그림'으로 인위적으로 수정하고 media 폴더에다 강제로 그림 파일도 추가한 후, 이를 다시 zip으로 압축하는 것이었습니다. 오랜만에 OpenXML 덕을 좀 보는가 싶었는데...

문제는 이 방법마저도 통하지 않았습니다. 압축을 푼 내부 구성 파일을 수정 없이 그대로 빵집 같은 유틸로 재압축만 했는데도, 엑셀은 오류가 있다면서 그 압축(=xlsx) 파일을 읽어들이길 거부한 것입니다. xlsx뿐만 아니라, 오피스 2007 SP2에서 추가된 OpenDocument (역시 xml+zip 기반) 방식 역시 마찬가지. 얘네들은 zip 압축이긴 하지만, 일반 압축 유틸리티가 생성하지 않는 메타 정보도 같이 집어넣는 것 같습니다. 이쯤 되니까 진짜 꽤 열받기 시작했죠. MS 제품이 이 정도로 개념 없는 줄은 몰랐는데.

또 한 30분을 삽질하다가 꽤 허무하게 문제를 해결은 했습니다.
htm 문서를 파일-열기로 열면 그림이 링크로 삽입되는 반면, 웹브라우저에서 이 htm을 연 것을 Ctrl+C로 복사하여 엑셀에다 붙여넣으면, 그 그림들은 완전히 내장으로 삽입된다는 것을 알게 되었기 때문입니다. 아놔~ ㅁㄴㅇㄹ

MS 제품과 아래아한글 사이의 넘사벽 이질감을 또 확인하는 계기였습니다. 이놈의 MS 제품들은 내가 문서라든가 프로그램의 내부를 확실하게 제어(under my control)한다는 느낌을 주질 않고 제멋대로 붕 뜬 상태로 알아서 하다가, 그걸 응용/변형해야 할 상황이 생길 때 사람 완전 낭패 보게 만듭니다. 좋게 말하면 당장 사용하고 결과물 만들기엔 편한 것이고, 나쁘게 말하면 사용자를 바보 만들고 일정 실력 이상은 오르는 게 거의 불가능하게 돼 있는, 좀 사악한(?) 기능 디자인이 아닐까 싶습니다.

MS 워드도 97 시절부터 10년을 넘게 써 왔지만 개요/스타일이라든가 특히 개체를 배치하는 방식에 대해, 저는 독학만으로는 절대 완전히 적응 못 하겠다는 결론을 내리고 포기했습니다. 그 반면 아래아한글은 97은 물론이고 워디안/2002 급 이후 버전도 손에 착 잘 맞는 편입니다. MS 워드에만 있던 고급 기능을 아래아한글 특유의 세밀한 스타일로 잘 배치했다는 점은 인정합니다. 지금도 아래아한글이 기술적으로 워드에게 뒤지는 면모는 있으나, 아래아한글에도 MS 워드가 절대로 흉내낼 수 없는 디자인 상의 안정성과 편안함이 있습니다. (민족주의에 호소하는 한글 표현 같은 것 말고요. 한글 표현마저도 엄밀히 말하면 오히려 MS 워드가 좀더 앞서 있습니다.)

사실 이런 비슷한 느낌은 프로그래밍 언어를 쓰면서도 받습니다. C/C++ 이외의 언어, 특히 type이 굉장히 느슨한 언어로 코딩하다 보면 이 개체가 과연 value로 전달되는지, reference로 전달되는지, new만 있고 delete가 없는 언어들은 도대체 언제 이 개체가 garbage collect되어 소멸되는지?
내가 짜는 건 한 줄이지만 이게 내부적으로 어떤 알고리즘으로 구현되며 데이터가 100개가 아니라 10만 개가 넘어가면 성능이 어떻게 될지?
이런 게 신경쓰여서 불안해서 코딩이 잘 되지 않는 경우가 있습니다. 나와 언어가 일심동체가 못 되고 붕 떠 있는 느낌.

그런 상위 계층 언어들이 how보다 what을 중시하게 하고, 익숙해질 경우 생산성은 더 뛰어난 것은 사실이나 저는 C/C++스러운 저수준 면모가 더 마음에 들고 편안하더군요.

Posted by 사무엘

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

아무리 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


블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/10   »
    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 31    

Site Stats

Total hits:
1264736
Today:
373
Yesterday:
550