책 만들기 두 번째 이야기입니다.
두 번째 책을 시리즈로 내려면 두 권을 나란히 놨을 때 같은 책처럼 보여야 합니다. 판형, 여백, 글자 크기, 줄 간격이 같아야 한다는 뜻이지요.
출판사가 표지와 내지 양식을 내려줍니다. 그걸 쓰면 되지 않느냐 하실 텐데, 저는 양식을 아예 안 봤습니다.
이유가 있어요. 양식을 AI에게 넘겨도 AI는 그 양식을 다시 재야 합니다. 여백이 몇 mm인지, 글상자가 어디부터 어디까진지 알아야 조판을 하니까요. 그렇게 재서 만들면 전작과 다른 책이 나옵니다. 그러면 시리즈 느낌을 내려고 전작을 또 재야 해요. 결국 두 번 일하는 겁니다.
그럴 바에는 처음부터 이미 출판에 성공한 책에서 치수를 가져오는 게 낫지요. 전작은 심사를 통과해 실제로 인쇄까지 된 책입니다. 그 치수는 이미 검증된 값이에요. 양식대로 만든 것보다 확실합니다.
그래서 인쇄소에 넘겼던 전작 PDF를 꺼내 자로 재기로 했습니다.
그전에, 준비물
이번 편부터 실제로 손을 씁니다. 뭘 깔아야 하는지 먼저 적어둘게요. 전부 공짜입니다. 돈 든 건 하나도 없습니다.
그런데 솔직히 말씀드리면 이걸 제가 깐 게 아닙니다. "이런 걸 하고 싶은데 뭐가 필요하냐"고 묻고, 찾아서 깔아달라고 시켰어요. 명령어를 제가 외운 것도 아닙니다.
요즘 바이브코딩이라고들 하지요. 저는 그 앞 단계를 바이브세팅이라 부르고 싶습니다. 환경 준비부터 통째로 시켜버리는 거예요. 예전 같으면 여기서 반나절은 날렸을 겁니다. 파이썬 버전이 어떻고 경로가 어떻고 하면서요.
그러니 아래 목록은 제가 공부해서 고른 게 아니라 결과적으로 깔려 있던 것들입니다. 나중에 정리해보니 이렇더라는 기록에 가깝습니다.
파이썬 3 : 맥에는 이미 깔려 있습니다. 그리고 라이브러리 넷.
pip install python-docx pymupdf pillow pillow-heif
python-docx 는 워드 파일을 만듭니다. 종이책이 이걸로 나갑니다.
PyMuPDF(설치명은 pymupdf, 코드에선 fitz) 는 PDF를 읽고 재고 그립니다. 이번 편의 주인공입니다.
Pillow 는 사진을 자르고 줄입니다.
pillow-heif 는 아이폰 HEIC 사진을 열어줍니다. 이거 없으면 사진 절반이 안 열립니다.
리브레오피스 : 워드 파일을 PDF로 굽는 데 씁니다. 무료고, 창을 안 띄우고 명령줄로만 돌릴 수 있어서 자동화에 편합니다.
soffice --headless --convert-to pdf 파일.docx
폰트 : 부크크가 무료로 뿌리는 부크크 명조와 부크크 고딕을 씁니다. 전작이 이 폰트로 나갔거든요. 표지에는 고운바탕을 썼습니다. 셋 다 상업적 이용이 되는 무료 폰트입니다.
폰트는 저작권을 꼭 확인하세요
책은 상업물입니다. 맥에 기본으로 깔린 폰트라고 마음대로 쓰면 안 됩니다. 무료 배포 폰트라도 "인쇄물 사용 가능"인지 따로 봐야 해요. 이거 놓치면 다 만들고 나서 폰트를 바꿔야 하는데, 폰트가 바뀌면 쪽수가 바뀌고, 쪽수가 바뀌면 책등 두께가 바뀌고... 표지부터 다시 만들어야 합니다.
여기까지가 전부입니다. 인디자인 같은 건 없어도 됩니다.
PDF는 생각보다 수다스럽습니다
파이썬 PyMuPDF라는 걸 쓰면 PDF 안 글자 하나하나의 좌표를 꺼낼 수 있습니다. 어떤 글자가 몇 pt로, 어디에, 무슨 폰트로 찍혔는지가 다 들어 있어요. 만든 사람은 잊어도 파일은 기억하고 있더군요.
그렇게 캐낸 전작의 규격입니다.
판형 437×612pt, 밀리로는 154.16×215.9mm. 국판(148×210)에 사방 3mm씩 도련을 붙인 크기입니다. 도련은 재단할 때 잘려나갈 여유분이지요.
본문 10pt, 줄 간격 20pt 고정, 양쪽 정렬.
여백 안쪽 28.0mm, 판면 폭 102.90mm.
그런데 세 번 틀렸습니다
숫자 뽑는 건 금방이었어요. 문제는 제대로 재기까지 세 번을 틀렸다는 겁니다. 같은 함정에 빠지실 분이 계실 것 같아 적어둡니다.
첫째, 홀수쪽과 짝수쪽을 섞어 재면 안 됩니다. 책은 맞쪽 여백을 씁니다. 제본되는 안쪽이 바깥쪽보다 넓고, 홀수쪽과 짝수쪽은 그 방향이 뒤집혀요. 두 쪽 섞어서 평균 내면 세상에 존재하지 않는 중간값이 나옵니다. 저는 이걸 모르고 "전작보다 2.7mm 넓다"는 엉뚱한 결론을 내고 한참 헤맸습니다.
둘째, 첫 줄 들여쓰기가 값을 오염시킵니다. 문단 첫 줄은 2.93mm 들여쓰기 때문에 다른 줄보다 오른쪽에서 시작하지요. 왼쪽 여백을 재면 값이 두 무리로 갈라지는데, 여기서도 중간값을 내면 또 틀립니다. 들여쓰지 않은 줄만 골라야 해요.
셋째, 자간은 글자 폭이 아니라 이동폭에 반영됩니다. 자간을 좁혀도 글자 모양 자체는 그대로입니다. 다음 글자가 시작되는 자리만 당겨지지요. 그러니 글자 하나 폭을 아무리 재봐야 자간은 안 나옵니다. 연속한 두 글자의 시작 좌표 차이를 재야 합니다.
결국 맞춘 방법
홀수쪽만 고르고, 폭이 판면 절반을 넘는 줄만 추리고(마지막 줄 제외), 왼쪽은 가장 왼쪽 무리, 오른쪽은 최빈값. 이 잣대로 재니 전작과 오차 0.00mm로 딱 맞았습니다. 세 번 틀린 보람이 있더군요.
워드가 발목을 잡기도 합니다
전작 본문이 10.1pt였는데, 이 크기를 쓸 수가 없었어요. 워드 파일은 글자 크기를 0.5pt 단위로만 저장하거든요. 10pt 아니면 10.5pt. 10.1pt 같은 건 없습니다.
그래서 10pt로 두고 자간을 -0.15pt 좁혀 글자 이동폭을 맞췄습니다. 전작이 9.24pt였는데 9.25pt가 나왔어요. 0.01pt 차이... 이 정도면 됐지요.
토큰이 순식간에 녹는 이유
1편에서 매일 토큰과 싸웠다고 했지요. 그 정체가 바로 이 문단 작업이었습니다.
원고가 28,206자입니다. 여기에 앞부속과 사진 자리까지 더하면 4만 자가 넘어요. 한글은 글자 하나가 대략 토큰 0.7개쯤 되니, 원고를 한 번 읽히는 데만 3만 토큰이 나갑니다.
문단을 어디서 끊을지는 글을 읽어야만 정할 수 있습니다. 앞뒤 맥락을 봐야 하니까요. 그러니 이 작업은 원고 전체를 통째로 넘길 수밖에 없습니다.
문제는 제가 이걸 화 단위로 나눠서 물어봤다는 겁니다. "9화 문단 좀 봐줘", "10화도", "다시 9화 보자"... 그때마다 원고가 다시 실려 갔습니다. 스무 번 물어보면 원고를 스무 번 읽힌 셈이지요.
지금이라면 이렇게 하겠습니다
원고 전체를 읽혀야 하는 작업은 한 번에 몰아서 시킵니다. 20화를 한 번에 넘기고 결과를 한꺼번에 받는 편이, 화마다 나눠 묻는 것보다 훨씬 쌉니다.
그리고 대화를 길게 끌지 않습니다. 한 가지 일이 끝나면 끊고 새로 시작하는 게 낫더군요. 대화가 길어지면 앞에서 나눈 이야기를 계속 다시 들고 다니거든요. 정작 지금 하는 일과 상관없는 것들까지요.
이걸 몰라서 밤마다 한도에 걸렸습니다. 한 번은 1주일치를 다 써서 5일을 손 놓고 있었고요. 책은 멈춰 있는데 할 수 있는 게 없더군요.
한 문장이 한 문단이던 원고
판형만큼 손이 간 게 문단이었습니다. 브런치 연재본은 한 문장이 한 문단인 경우가 많아요. 화면에서는 시원하게 읽히는데, 종이에 그대로 옮기면 글이 뚝뚝 끊깁니다.
반대로 여섯 줄 넘어가는 긴 문단도 원고의 19%나 됐습니다. 문단 나누기는 양방향 작업이더군요. 짧은 건 묶고 긴 건 쪼개고.
636개였던 문단을 404개로 다시 묶었습니다. 3~5줄 문단이 69%가 되고, 6줄 넘는 문단은 딱 하나 남았습니다. 대화문은 원래대로 한 줄씩 세워뒀고요.
여기서 절대 양보 못 할 원칙이 하나 있었습니다. 문장은 한 글자도 바꾸지 않는다. 나누는 자리만 옮긴다. 그래서 작업할 때마다 원본과 글자를 대조해서 한 글자라도 달라지면 멈추도록 만들어뒀습니다. 남의 글, 그것도 아내 글을 다루는 일이라서요...
아내는 다시 나눈 원고를 보고 무척 신기해했습니다. 같은 글인데 숨 쉬는 자리가 생겼다는 거지요.
그런데 그렇게 토큰을 갈아 넣고도 미진한 데가 남아 있었습니다.
대화체 뒤가 특히 그랬어요. 큰따옴표로 끝난 다음에 문단이 여러 번 나뉜 자리가 그대로 남아 있었습니다. 사람이 읽으면 대번에 걸리는데 기계는 그걸 못 봤습니다. 사진을 넣기 시작하니 빈 공간도 여기저기 생겼고요.
그래서 검토가 세 번, 네 번 반복됐습니다. 고치라고 하면 고치는데, 고치는 김에 시키지도 않은 것까지 건드립니다. 사진 위치를 자꾸 제 뜻과 다르게 옮겨놨어요. 한 번은 아내가 "이 문장 뒤에 놔달라"고 지정한 사진을 앞쪽으로 당겨놔서, 제가 "왜 당겨놨냐"고 따져 물은 적도 있습니다.
기계는 자기가 보기에 더 예쁜 자리로 옮긴 겁니다. 여백이 덜 생기는 자리로요. 그런데 글 쓴 사람이 정한 자리에는 이유가 있습니다. 그 이유는 여백 계산으로 나오는 게 아니고요.
다음 편은 사진 47장을 어디에 넣을 것인가입니다. 처음 뽑았을 때 빈 페이지가 31개 생겼거든요. 서른한 개...
