한빛출판네트워크

제공 : 한빛 네트워크
저자 : Rick Jelliffe
역자 : 이호민
원문 : Super-styling: Are our current page-breaking hints too low-level for acceptable interoperability?

과거에는 손쉽게 출판시스템을 크게 약 네 가지로 구분할 수 있었다:

• 3B2, JADE, TeX - 고품질 또는 대량 조판
• Word Perfect, AbiWord, - 워드 프로세서(WP)
• PageMaker - 데스크톱 출판 (DTP)
• Crystal Reports - 리포트 생성

최근에는 많은 제품들이 예전에 구분되지 않았던 새로운 정렬방법으로 섞여 들어가고 있어 이들을 구분하기가 어려워 졌다. 예를 들면 어도브 In-Design의 경우 DTP로 구분 지었던 디자인이 집중된 페이지에 대한 처리를 하지만 배치 실행을 할 수도 있고, 대부분의 리포트 생성과 조판 작업 또한 가능하다. 더 이상 시장의 요구 앞에서 오래된 구분법을 내세울 수 없게 되었고, 제품들은 점점 더 혼란스러워 지고 있다.

물론 큰 흐름 중 하나는 XML의 출현이다. 이것은 PDF가 미들웨어와 출력물을 완벽히 단절시킨 것만큼, 완전하게 미들웨어로 입력시의 얽힌 것들을 풀어내었다. 유사하게 워드프로세서에서 압축 XML을 지원하게 됨으로 워드프로세스를 넘어서는 영역으로의 적응성을 키우고 있다.

내가 이 차이를 구분하여 집고 넘어가는 것은, 각 시스템들이 지원하는 능력에 커다란 차이가 있기 때문이다. 그 중 내가 관심을 가지고 있었던 것은 쪽 넘김 (page-breaking) 동작 -또는, 적어도, 소프트웨어가 언제 페이지가 꽉 차서 새 쪽 넘김을 수행해야 하는지 알 수 있도록 하는 설정이나 귀띔(hint)에 대한 것-이었다.

내용이 잘리기 전에 자주 쪽 넘김을 한다

과거에는 이 일이 쉬웠다: DTP 애플리케이션은 페이지에 대해 처리하지 않았다: 구문이 꽉 차면 화면 밖으로 넘어가 버린다. 하지만 한 페이지 안에서는 객체들을 대단히 자유롭게 위치시킬 수 있다. WP 시스템들(troff 같은 초기의 배치 시스템도 포함)은 무척 단순한 메커니즘을 가지고 있었다: 전형적인 것이 needs 시스템( troff에서 .ne, Scribe에서 @needs)으로 페이지에 정해진 만큼의 공간이 남아있지 않는 경우 줄 바꿈이 생성되는 것이다.

더 높은 수준의 조판 시스템에서는 훨씬 현학적인 방법을 사용할 수 있다. 이는 프로그램 방법 (최고 수준의 조판 시스템은 실제로 복잡한 요구사항들을 코딩 할 수 있는 프로그래밍 언어이다)과 다소나마 고수준의 선언방법들을 모두 가지고 있다는 것이다. 이것들은 종종 문장 블록의 속성이나 (구조적인 도구로서) 문장 블록의 컨테이너의 속성들로 표현된다. (HTML의 div 엘리먼트 같은 것이다)

이러한 속성들은 문단들을 서로 연결하기 위한 다양한 메커니즘을 포함한다: 예를 들면 머릿글자에 keep-with-next 속성을 두어 머릿글자 뒤에 따라오는 구문이 다음 페이지로 넘어갈 경우 머릿글자도 따라가게 할 수 있다. 이러한 메커니즘들은 다양한 다른 메커니즘과 상호작용을 하게 된다: 문장 블록이 끝나지 않은 채로 쪽 넘김이 되지 않도록 문장 블록에 keep-together 속성을 줄 수 있는 시스템들이 있으며, 문단의 마지막 줄이 (다음)쪽의 첫 줄로 밀려나는 widow 현상이나, 문단의 첫 줄이 쪽의 마지막 줄에서 시작되는 orphan 현상을 막기 위한 widow, orphan 제어를 가지는 시스템들도 있다. Tex를 예로 들면 하이픈연결(옮긴이 주: 영단어의 중간에서 줄 바꿈이 될 때 "-"으로 어절을 끊어 이어 주는 것) 과 쪽 넘김을 연동하여 페이지가 하이픈으로 끝나지 않도록 해 준다.

자주 사용되는 워드 프로세서 애플리케이션의 경우 이런 특징들에 대해 매우 제한된 능력을 가지고 있다. 그 프로그램들의 사용자 모델은 사람이 문서를 작성하며 모든 일을 손으로 한다는 것이다. 반면 복잡한 조판 시스템들은 배치(다량) 모델을 가지고 있다: 여러분이 하루에(매일) 1000 페이지에 달하는 책을 작성한다면 모든 페이지들을 일일이 살펴보고 싶지는 않을 것이며 그런 일을 잘 해 내는 소프트웨어가 필요할 것이다. 일부 조판 애플리케이션들은 나쁜 쪽 넘기기라고 판단되었을 때 조판작업자에게 경고 메시지를 남기기도 한다. 마이크로소프트 워드는 이런 작업들에 대해 가장 기본적인 기능(설비)만을 제공하는 일반적인 오래된 워드프로세서 애플리케이션으로, 공백을 중요하게 고려해야 하는 고품질 출판에 사용하기에는 너무나 초보적이다.

"need" 또는 "keep-with-next"를 사용하는 시스템은 공간을 낭비하는 경향이 있다: 예상하지 못했던 방향으로 내용물들이 다양해 질수록 쪽 넘김은 더 엉망진창이 된다. 다음과 같이 극단적인 경우를 생각해 보자: 책에서 한 장(chapter)의 마지막 단어가 왼쪽 면에 들어가지 못하고 넘치게 되면, 그 결과물로 앞뒤로 거의 빈 공간뿐인 쪽이 생기게 된다. (옮긴이 주; 새 장은 오른쪽 면에서 시작하기 때문.)

산업 조판

또한 언제 쪽 넘김을 하는지가 매우 중요한 사용 예가 있다. 예를 들면, 기술 표준이나 동작 설명서 등에 관한 오랜 군사 문서 표준으로, ‘경고에 해당하는 모든 것들은 같은 페이지 안에 있어야 한다’와 같은 것이다: 다음과 같은 문구를 생각해 보자; "빨간 선을 자르기<쪽 넘김>전에 파란 선을 먼저 잘라야 한다. 이 순서를 따르지 않으면 폭발한다." 혹은, 때때로, ‘경고 문구는 그것을 참조하는 내용과 같은 쪽에 있어야 된다’는 것도 있다.

게다가, 전화번호부나 데이터북, 카탈로그 같이 큰 주제와 함께 다중-열을 가진 인쇄물을 다룰 때는 최적화된 페이지를 구성하는 것은 혹독하게 어려울 수 있다: 이 경우 낭비되는 쪽이 없어야 된다. 예를 들면 전화번호부의 인명록의 위치는 조절 가능하며 그가 속하는 머릿글자 보다 먼저 위치하게 되더라도, 가장 잘 맞는 곳에 위치하기 위해 몇 페이지 가량 앞/뒤로 이동하여 조판할 수도 있다. (나는 최적화된 쪽 배치의 결과로 앞으로 네 페이지나 찾아야 하는 시스템을 본 적이 있다.) 이 "유동성"은 미치도록 까다로우며, 일반적인 워드프로세서의 능력으로는 어림 없는 일이다.

그리고 사실, 쪽 넘김 동작을 명시하기 위한 여러 다른 메커니즘이 존재한다. 또한, 다른 시스템들이 제공하는 각각의 메커니즘 간에도 각기 다른 제어 정도의 차이를 가지고 있다: 예를 들면 orphan 제어는 기능은 있지만 widow제어는 지원하지 않는 시스템이 있을 수 있다. 이러한 문제점은 뜻밖에 다른 곳에서도 나타난다: 팀 브레이가 두께(bold)를 표현하기 위한 두 가지 방법이 있을 필요가 없다고 말했을 때 나는 그가 각각의 글꼴들은 다른 두께로 구현되었다는 사실을 말하고자 했다고 생각한다. 그리고 그걸 숨기기 보다는 밝히는 것이 좋다: 예로, semi-bold(역자주: 반쯤 두꺼운) 글꼴의 경우 완전히 다른 글꼴로 취급(OOXML의 경우로 bold와 bold가 아닌 경우로 처리하며 중간단계는 없다) 해야 할까 아니면 속성으로 취급(XSL-FO의 경우 글꼴 두께를 위한 font-weight 수가 있으며, ODF의 경우 양쪽 모두를 담고 있어, 글꼴을 지칭하고 “bold”/“normal”을 선택하기 위한 font-adornment 속성과XSL-FO이 사용하는 수치화된 선택 또한 제공한다) 해야 할까?

ODF/OOXML 병합(OOXML/CSS 병합, UOF/ODF 병합등과 같은 것들에는 신경을 끄자)시의 숙제 중 하나는 이렇게 간단하지 않은 일을 처리하기 위한 최적의 전락을 찾아내는 것이다. 단순히 모든 것을 추가한다면 개발자에게 큰 부담이 될 것이며 반면에, 간단한 기능만을 추가한 경우 판형에 꼭 필요함에도 빠진 기능들로 필요 이상으로 다시 쪽 넘김을 해야 하는 수고를 겪어야 할 것이다. 그리고 일부 기능만을 적당히 제공하는 중간적인 방법으로는 극단적인 문제점들을 피할 수 없을 것이다.

슈퍼스타일

최근 들어 나는 고전적인 WP 시스템들로부터 파생된 우리의 쪽 넘김 방식이 조판 출력을 위한 훨신 더 메커니즘 독립적인 좀 더 고 수준의 스타일 개념으로 변환될 수 있을지에 대해 고려해 왔다. 이 일은 최근에 이르기 까지 수년 동안 여러 직업들에서 중복되게 수행되었던 것이다. 기본적인 아이디어를 제공하기 위해 모든 요소들에도 적용될 수 있는 세가지 특징들 가져왔다:

• Announcement(알림) 은 한 요소가 그것을 둘러싼 것들로부터 시각적으로 분리되어 있어야 할 때 사용한다. 여기에는 두가지 특질(falvor)이 있다: starting, ending.
• Cohesiveness(응집력) 은 한 요소가 한 쪽이나 칼럼, 줄 위에 있어야 할 때 사용한다. 세가지 특질로 구분했다: initial cohesiveness (첫 번째 쪽, 칼럼, 줄 …), final cohesiveness, general cohesiveness.
• Relevance(관련성) 은 요소가 정확히 순서대로 나열되어야 할 때 사용한다. 유동 범위를 같은 수준(sibling)이나 상위수준(ancestor)로 더 허용하기 위해 다음 특질들로 구분했다: forward, backward

이 아이디어는 이 속성들의 설정들을 다양한 조판 시스템이 제공하는 keep-with-next, widow/orphan, soft/hard page-break등의 다양한 기능들과 조화롭게 사용할 수 있을 만큼 확실히 현실적인 것이 될 것 이다. 따라서 이러한 슈퍼스타일을 사용한 문서는 판이하게 다른 조판 시스템간에서도 메커니즘의 관점에서 시스템 제작사 간의 장벽 없이 재사용 할 수 있게 된다.

예를 들면, 장(chapter) 요서의 경우 매우 높은 starting announcement (오른 쪽에서 강제로 쪽 넘김을 수행하기 위함)과 매우 놓은 end cohesiveness (마지막 줄만 다음 페이지에 남겨지지 않기 위함)을 가지게 될 것이다. 절(section)의 경우 중급의 starting announcement(쪽의 아주 낮은 위치에서 시작되지 않는 이상 강제로 쪽 넘김을 하지 않도록 한다)을 가지지만, 높은 initial cohesiveness로 머릿글자가 쪽의 마지막에 홀로 남겨지지(orphan) 않고 다음 쪽으로 따라 이동하도록 한다. 군사 경고문은 낮은 announcements와 높은 cohesions , 높은 relevances를 가지게 될 것이다. 도표의 경우 낮은 relevances , 높은 cohesions (주석이 떨어져 있는 것을 방지), 중급의 announcements를 가지게 될 것이다.

머릿글자 이면서 그 뒤에 따르는 문단과 이어지는 것을 런인헤딩(Run-in headings)이라고 한다: 많은 워드프로세서에서의 기능 중에는 같은 블록에서 계속되는 요소라는 개념이 없기 때문에 런인헤딩은 다소 까다로운 존재이다; 따라서 여러분은 자주 그 요소들을 뒤따르는 절로 옮기도록 데이터를 변환하여야 했을 것이다. 슈퍼스타일에서는 중급의 initial-announcement과, 0보다 더 낮은 end announcement로 런인헤딩을 표현할 수 있게 된다.

이런 슈퍼스타일의 장점은 무엇일까? 가장 간단히 말하면 메커니즘에 독립적이라는 것이다. 그리고, 이론적으로, 그 속성들은 기존의 스타일/포맷의 속성들로부터 리버스엔지니어링 될 수 있다. 한 메커니즘에서 다른 메커니즘이나 속성으로의 전달시의 투명성을 높임으로써 모든 시스템이 모든 일을 다시 할 필요가 줄어들게 될 수 있다.

또한 이 경우 다른 장점이 두 가지 있다. 첫째로 이 방법은 추상화된 스타일을 제공하기 때문에 시각적인 표현이 아닌 경우에까지 적용할 수 있다. 예를 들면, 문서 트리에서 굉장히 높은 곳에 위치할 만큼의 high announcement를 가진 연속적인 요소(element)들은 자동으로 별도의 HTML 페이지들(또는 사용자 에이전트에서 별도의 탭들)로 나뉠 수 있을 것이다. 마찬가지로, low relevance의 요소들은 다른 페이지나 HTML 변환 시에 다른 div 안으로 놓여질 수 있을 것이다. high annoucement의 요소들은 음성 합성기를 통해 음성화 되기 전에 잠시 멈추거나 효과음을 내는 등의 극적인 처리를 할 수도 있다.

두 번째는 이 방법이 나쁜 쪽 넘김을 발견해 낼 수 있는 메커니즘을 제공한다는 것이며, 원시적인 메커니즘만을 가진 시스템에서도 적용될 수 있다. 예를 들면, 페이지에 공백이 많이 나오면 이를 수용할 것인지 아닌지를 검사할 수 있다. 이는 아마도, SOHO 사용자들 보다는 자동 조판 기술이 적용되는 장문의 큰 책을 위한 조판 시스템을 개발하는 개발자들이 더 관심 있는 것일 것이다.