내맘대로의 EPUB 제작 가이드

초보 편집자는 단순하지 않은 것을 단순하게 생각할 때가 있습니다.

예를 들면 이런 스타일이요.

제목 위/아래로 이렇게 패턴처럼 보이는 선이 들어가 있습니다.

이 선은 어떻게 넣을까요?

가로로 긴 이미지를 width : 100%;로 넣으면 되지 않아?

이렇게 생각하는 분들이 많을거예요.

가로 폭에 맞춰 넣어도 문제는 없습니다.

그런데 가로 폭에 맞추면, 태블릿에서 가로보기를 하는 독자는 어떻게 보일까요?

잘못된 것은 없지만, 뭔가 아쉽지 않으세요?

그럼 아래 스타일은 어떤가요?

가로보기를 해도 일정 크기를 유지합니다.

스마트폰 처럼 화면 폭이 좁을 때는 화면 폭에 맞춰 100%을 유지하지만,

화면이 일정 크기 이상 늘어나면 더 이상 늘어나지 않도록 스타일을 잡았습니다.

이렇게 하면 PC/태블릿/스마트폰 어떤 기기로 봐도 더 깔끔해 보이지요.

이미지나 다른 패턴을 넣을 때도 무조건 100%로 하거나 고정 크기로 넣기 보다는

작은 화면과 큰 화면 모두 '잘 보이도록' 고민을 해야합니다.

Sigil은 특별한 기능을 갖고 있는 클래스/태그/속성이 몇개 있습니다.

Sigil에서만 쓰는 이런 코드를 잘 활용하면 전자책을 편하게 만들 수 있습니다.

1.  표지 추가 기능에 사용하는 속성

표지는 이미지를 선택해 추가합니다.

이미지는 폭과 높이가 제각각이기 때문에 이미지의 폭과 높이를 지정하고 싶을 때 이 속성을 사용할 수 있습니다.

width="SGC_IMAGE_WIDTH"   - 이미지의 폭을 자동으로 계산하여 픽셀 값으로 추가합니다.
height="SGC_IMAGE_HEIGHT" - 이미지의 높이를 자동으로 계산하여 픽셀 값으로 추가합니다.
href="SGC_IMAGE_FILENAME" - 이미지의 파일 경로를 자동으로 추가합니다.

예를 들어, 표지 스타일을 자신만의 코드로 만들고 싶을 때

<div class="cover">

<img class="cover_img" src="SGC_IMAGE_FILENAME" alt="SGC_IMAGE_FILENAME"/>

</div>

<style>

.cover_img {

   width : SGC_IMAGE_WIDTHpx

   height : SGC_IMAGE_HEIGHTpx

}

</style>

이렇게 사용할 수 있지요.

2. class="sigil_not_in_toc"

제목 태그를 사용하면 차례 만들기 기능으로 자동으로 TOC(Table of Contents)를 추가합니다.

그런데 제목 태그를 써도 제목에 넣고 싶지 않을 때가 있습니다.

예를 들어, 부(h1), 장(h2), 절(h3), 소단락(h4)으로 되어 있는 책에 절과 소단락을 TOC에서 빼고 싶다.

<h3 class="sigil_not_in_toc">

<h4 class="sigil_not_in_toc">

제목에 이렇게 클래스를 추가하면 h3, h4 태그가 차례 만들기에 포함되지 않습니다.

3. 장 나누기 표시 : <hr class="sigil_split_marker" />

부, 장, 절 등에서 새로 단락이 시작하는 책이 있습니다.

EPUB으로 책을 편집할 때 책의 구분에 따라 파일을 나누게 되는데

주석 같은 작업은 통으로 작업하고 마지막에 파일을 나누는게 편하지요.

이럴 때 파일을 나눠야 하는 위치에 장나누기 표시를 하면 

[장 나누기 표시 분할] 기능을 이용해 한번에 장을 나눌 수 있습니다.

4. title="..." 

이건 Sigil의 속성은 아니지만 Sigil에서는 특별한 방법으로 사용할 수 있습니다.

1장 좋은 질문을 던지지 못하는 이유 우리는 왜 뻔한 질문을 주고받을까?

장 제목이 이렇게 되어 있을 때 본문에서는

글자색, 글자 모양, 줄바꿈 등으로 제목을 편집할 수 있지만

TOC에서는 이대로 들어갑니다.

본문 제목은 그대로 두고 TOC에서만 제목을 이렇게 수정하고 싶다면?

1장 - 좋은 질문을 던지지 못하는 이유 | 우리는 왜 뻔한 질문을 주고받을까?

이럴 때 title을 사용합니다.

<h1 title="1장 - 좋은 질문을 던지지 못하는 이유 | 우리는 왜 뻔한 질문을 주고받을까?">

1장 좋은 질문을 던지지 못하는 이유 우리는 왜 뻔한 질문을 주고받을까?

</h1>

이렇게 하면 본문에서 제목이 어떤 구조로 되어 있든, 차례 편집기는 title의 정보를 가져옵니다.

5. 차례를 위한 ID : id="sigil_toc_id_*"

나는 추가한 적이 없는데 전자책 편집을 끝내면 이런 ID가 들어갈 때가 있습니다.

이 ID는 차례를 만들 때 자동으로 추가된 ID입니다.

같은 파일 안에서 같은 레벨의 제목이 여러개 있을 때,

<h4>소제목1</h4>

<h4>소제목2</h4>

<h4>소제목3</h4>

차례를 만들면

<h4 id="sigil_toc_id_1">소제목1</h4>

<h4 id="sigil_toc_id_2">소제목2</h4>

<h4 id="sigil_toc_id_3">소제목3</h4>

이렇게 ID가 추가됩니다.

글 제목은 이렇게 달았지만, 유통사 뷰어 지적질을 많이 하는 사람 중 하나입니다.

유통사 뷰어 별로 여러 문제가 있고, 유통사에 뷰어 문제를 개선하도록 만들 정도의 파워가 없으니

여기에라도 지적질을 해서,

혹시라도 유통사 뷰어 담당자 또는 관련자가 이 글을 보면 개선을 하지 않을까 하는 마음에서 올리는 지적질이지요.

그런데 유통사 뷰어가 엉망인 이유를, 유통사의 무능으로 매도하는 제작자들이 많습니다.

뭐가 안되네, 뭐가 문제있네 하고 문제점을 지적하는데,

알고 보면 문제가 아닌 것들도 무수히 많지요.

저는

 HTML과 CSS를 EPUB 기술사양에 맞춰 제작했을 때 제대로 반영이 되지 않으면 문제를 지적합니다.

예를 들어, 리디북스의 margin이 먹지 않는 문제, 알라딘의 이미지 height 문제 등이요.

문제를 확인하고 1년 넘었는데 개선되지 않으면 지적질을 합니다.

그런데 많은 초보 제작자들은

유통사의 정책 문제, CSS/HTML에 대한 무지로 인해 생기는 문제까지 유통사 뷰어 문제라고 얘기합니다.

예를 들어, 팝업 주석 같은 것은 정책 문제입니다. 알라딘이 epub:type:noteref을 EPUB2 뷰어에서 받아들이지 않는건 정책 문제지요. 개선해 달라고 건의는 할 수 있지만 어디까지나 정책적인 문제일뿐 epub:type:noteref를 처리하지 않는다고 뷰어에 문제가 있다고 얘기할 수는 없습니다.

그리고, 이런 정책과 CSS/HTML에 대한 문제 보다 더 큰 문제가 있습니다.

많은 유통사들이 강제로 CSS와 HTML의 표준을 무시하는 이유지요.

바로 쓰레가 같은 EPUB입니다.

표준에 맞게 제대로 EPUB을 만들면 유통사가 CSS 스타일에 예외를 둘 필요가 없습니다.

스타일에 예외를 두지 않으면 Webkit/webengin을 사용하는 전자책 뷰어는 CSS/HTML을 크롬 브라우저 수준으로 표현합니다.

그런데 예외를 두지 않으면 형편없이 만들어 올리는 EPUB 때문에 독자들의 불만이 유통사로 쏟아집니다.

유통사에 등록되는 50% 이상의 전자책이

전자책 만들 능력도 되지 않은 엉터리 편집자가 만들어 뷰어에서 제목과 본문도 제대로 구분되지 않는 파일이에요.

글자 크기를 작게 만들겠다고 h5 태그로 문단을 감싸거나

p태그가 아닌 div 태그로 모든 문단을 처리하기도 하고

문단 구분을 br 태그로 하는 등.

인라인 태그와 블럭 태그도 구분 못해 블럭태그 없이 <sub>나 <b> 같은 인라인 태그를 쓰는 경우도 많습니다.

이런 재활용도 하지 못할 수준의 EPUB이 유통사에 등록되고, 유통사는 이런 것들 조차 제대로 독자에게 보여줘야 하기 때문에 뷰어에 예외처리를 하게됩니다.

그러다 보면 뷰어에 문제가 생길 수 밖에 없지요.

유통사 뷰어 욕하기 전에,

내가 전자책을 제대로 만들고 있는지 부터 확인해 보세요.

물론 수많은 전문 업체와 전문 편집자들은 잘 만들어요.

그런데 이들이 만드는 것 보다, '전자책은 누구나 쉽게 만든다'는 헛소리를 해 대며

기초도 제대로 배우지 않고 대충 만들어 올리는 전자책이 더 많습니다.

믿기지 않는다면, '경기도 사이버 도서관' 신착자료 카테고리에 들어가보세요. 무료로 볼 수 있느니 대여해서 확인을 해 보세요.

유통사 신간 코너 들어가면 책을 열어보지 않아도 문제가 있겠구나 싶은 책이 제대로 만들었겠다 싶은 책 보다 훨씬 많이 들어옵니다.

유통사 뷰어 욕하기 전에

EPUB 부터 제대로 만들어야 합니다.

그래야 유통사가 뷰어를 제대로 만들 수 있어요.

쓰레기 같은 전자책을 제대로 보여주려면

제대로 된 뷰어를 만들기 어렵습니다.

페이지 계산을 위한 판형, 글자크기, 여백 설정은 이 글을 참고하시기 바랍니다. https://epubguide.tistory.com/407 

전자책은 페이지가 없기 때문에

제작 단가 처럼 페이지 기준으로 계산을 해야 할 때 어려움을 겪을 수 있습니다.

종이책이 있다면 종이책 페이지를 기준으로 하면 됩니다.

하지만 이 경우에도 공공기관 책자 처럼 A4 판형에 글자 크기가 9pt보다 작게 나온 책은

신국판에 11pt로 나온 책과 같은 기준으로 페이지를 정하기 어렵습니다.

그리고, 페이지를 기준으로 제작 단가를 산정하면 일부 양심 없는 사람들이 이상한 장난을 치지요.

HWP에서 A4 사이즈에 상하좌우 여백 10mm, 글자 크기 7pt, 줄간격 120%...

이렇게 해 놓고 '100쪽이다' 주장을 합니다. 제가 실제로 경험한 사례예요.

이걸 시중에 가장 많이 판매되는 신국판(또는 변형) 기준으로 잡으면 400쪽이 넘어갑니다.

그래서 저는 '일반적인' 판형과 글자크기가 아니면 아래 기준으로 페이지를 정합니다.

========
편집 기준
========
한글워드(HWP)
용지 : 신국판(148 * 225)
여백 : 상하 25mm / 좌우 20mm
글꼴 : 함초롬바탕
글자 크기 : 11pt
줄간격 : 200%

이렇게 해야 양심 없는 사람들의 장난질을 막을 수 있어요.

그런데 이 기준으로 해도,

모든 의뢰자에게 HWP에 넣어 페이지를 계산해 달라고 할 수는 없습니다.

로판무 같은 연재 원고는 텍스트 파일로 작업하는 경우도 있고요.

그래서 글자 수 기준으로 페이지를 대신 할 때가 있습니다.

이럴 때는 어떻게 할까 고민을 하다,

제가 편집하는 책 몇권의 글자 수를 직접 세 봤습니다.

그림/표/도표가 없는 소설을, 장 구분 없이 텍스트만 꽉 채워서 계산해 보니

대략 아래처럼 나오네요.

========
글자 수 기준 : 공백 제외(실제 글자 수)
========
400쪽 : 200,000자
300쪽 : 140,000자
200쪽 : 90,000자
100쪽 : 50,000자

========
글자 수 기준 : 공백 포함(실제 글자 수)
========
400쪽 : 250,000자
300쪽 : 180,000자
200쪽 : 120,000자
100쪽 : 60,000자

평균치이고, 10,000단위에서 올리거나 내렸습니다.

반올림도 애매하고, 버림이나 올림도 애매해 임의로 판단해 잘랐어요.

그래도 대략 반올림이다 생각하면 됩니다.

이렇게 계산해 놓고 보니,

대략 100쪽이 공백 제외 기준 5만자, 공백 포함 6만자입니다.

200, 300, 400쪽 배수로 해도 이 기준으로 하면 어느정도 맞아 떨어집니다.

책의 분량을 계산해야 하는데 기준이 모호해 합의가 어려울 때

글자 수를 기준으로 하면 깔끔하게 정리할 수 있지 않을까요?

물론, 이 기준은 글자 수만 계산했기 때문에

표/도표/이미지 같은 부속 요소가 포함된 책에도 같은 기준을 적용할 수는 없습니다.

이미지가 많이 들어간 책이라면 5만자라도 200쪽이 넘어갈 수 있지요.

100쪽 분량에 1장인 책과 10쪽 분량이 1장인 책 역시 같은 5만자여도 10쪽 이상 차이가 날 수 있습니다.

이미지가 많이 들어간 2.5만자 100쪽 책과

이미지가 없는 5만자 100쪽 책을 글자 수로 계산해 제작 난이도를 따질 수도 없습니다.

그래서 글자수로만 책의 분량을 정하고, 분량에 따라 제작 난이도를 판단해서는 안됩니다.

전자책 제작 시간은

글자 수, 부속 요소(이미지/도표/표 등), 본문과 다른 편집 요소(첨자, 주석, 박스글 등),

별면, 부/장/절 구분 등 다양한 편집 항목이 서로 영향을 주기 때문이지요.