테이블(table) 안쪽 여백(padding)과 가운데 정렬하기

오랜만에 스타일 팁 올립니다.


어떤 분이 테이블 안쪽 여백과 테이블 가운데 정렬 방법을 물으셨어요.


테이블(table) 태그는 기본 속성(attribute)을 몇개 갖고 있습니다.


글자 영렬(align), 테두리 모양(border), 배경색(bgcolor), 폭(width)...


전자책 만들 때 이런 속성은 사용하지 마세요!!!!!


태그 기본 속성을 사용해도 별 문제는 없습니다. 그런데 W3C에서도, IDPF에서도 스타일 편집은 CSS로, 그것도 외부 CSS로 하도록 하는 추세입니다. 


만들어 놓은거라 써도 상관은 없는데 앞으로는 이런거 전부 없앨거야~


그래서 이런 속성들 대부분은 HTML5에서 지원을 하지 않습니다.


그럼 이런건 어떻게 해야할까요? 

아래 표를 보세요. 위쪽 표는 테두리 색과 border-collapse 만 적용했습니다. 확인이 편하게 하려고 적용한 속성이고 이 두 속성을 제외하면 아무 스타일도 적용하지 않았을 때 테이블이 이런 모습으로 보여요.


이런 테이블을 아래쪽 표처럼 안쪽 여백을 주고, 테이블 자체를 가운데 정렬하려면 어떻게 해야할까요?

 


안쪽 여백이니 padding,가운데 정렬이니 text-align : center;를 주면 되겠지요?

그런데 이게 안먹힙니다.


여기서 2가지 문제가 생겨요. padding을 어디에 줘야 하는지, 그리고 text-align으로 가운데 정렬이 되지 않을 때 어떻게 가운데 정렬을 하는지.


먼저 스타일 코드를 보세요.


table, tr, td {

border : 1px solid #FF0000;

border-collapse: collapse;

}


.cell_padding {

padding : 1em;

}


.table_center {

display : table;

margin-left : auto;

margin-right : auto;

}


<table class="table_center">

<tbody>

<tr>

<td class="cell_padding">

안쪽 여백, 테이블 가운데 정렬

</td>

<td class="cell_padding">

안쪽 여백, 테이블 가운데 정렬

</td>

</tr>

<tr>

<td class="cell_padding">

안쪽 여백, 테이블 가운데 정렬

</td>

<td class="cell_padding">

안쪽 여백, 테이블 가운데 정렬

</td>

</tr>

</tbody>

</table>


1. padding은 셀(td)에 적용한다.


테이블에서 글자가 들어가는 곳은 tr 태그 안쪽입니다. table, td는 테이블의 구조를 만드는 태그고, td가 텍스트가 들어가는 셀을 만드는 태그예요. 그러니 텍스트가 들어가는 셀에 여백을 주고 싶다면 td 태그에 스타일을 적용해야겠지요.


2. 테이블을 가운데 정렬하기


테이블이나 div같은 상자를 가운데정렬 할때는 text-align 속성이 제대로 적용되지 않습니다.

적용할 방법이 없는건 아닌데 그럼 코드가 복잡해져요.

이럴 때 margin-left : auto; margin-right : auto;를 사용해 보세요.


div 박스일때는 display : table; 혹은 display : box; 속성도 같이 지정해야 합니다.

여기서는 display :table;이 없어도 되지만, 확실히 해주기 위해 추가했어요.


끝으로... 테이블을 오른쪽 정렬 하고싶다면?

.table_center {

display : table;

margin-left : auto;

}


이렇게 스타일을 바꿔보세요. 그럼 가운데 있던 테이블으 오른쪽으로 정렬됩니다.





설정

트랙백

댓글

ttf vs otf 폰트

내용 추가-20170824

네이버 나눔명조 OTF파일은 안드로이드 계열에서 일부 특수문자와 한자가 표기되지 않는 문제를 확인했습니다. 문제가 수정되기 전까지 네이버 나눔명조를 쓸 때는 OTF가 아닌 TTF파일 사용을 권해드립니다.


전자책을 제작할 때 폰트 파일을 포함시킵니다.

특정 폰트를 사용하면 반드시 폰트 파일이 포함되야하지요.

그런데 폰트 파일도 여러 종류가 있습니다. 


ttf, otf, woff, bitmap.... 


가장 많이 사용하는 폰트는 ttf일거예요.

윈도우에서 사용하는 폰트고, 국내 무료 폰트는 ttf로 제공하는 곳이 많습니다.


하지만 IDPF에서 권하는 폰트는 OTF예요.


물론 의무사항은 아닙니다.(It is advisable for a Reading System to support the OpenType font format, but this is not a conformance requirement; a reading system may support no embedded font formats at all.)


IDPF에서는 OTF 폰트를 권하고 있지만 최근까지 뷰어가 OTF를 제대로 지원하지 못했습니다. 뷰어 문제는 아니었어요. 구 버전 안드로이드 중 일부에서 OTF를 넣으면 표현이 되지 않는 문제가 있었습니다. 그래서 저도 OTF보다는 TTF를 주로 사용했지요.


그런데 EPUB3를 제작해 보신 분들은 TTF 폰트 사용시 info메시지가 표시되는걸 경험하셨을 거예요.


오류는 아닙니다.

TTF 파일을 사용해도 아무 문제가 없어요.

그래도 저런 메시지가 뜨면 화장실 갔다 뒷처리 안한 것 처럼 개운하지 못합니다.

EPUB2에서는 저런 메시지가 표시되지 않아요. 그래도 IDPF 표준문서를 보면 폰트는 OTF를 포함시켜야 한다고 되어 있습니다.(At least one file in OpenType format should always be included in the list.)

* http://www.idpf.org/epub/20/spec/OPS_2.0.1_draft.htm#Section3.4


EPUB3.01문서에는 이를 좀 더 강하게 요구하고 있습니다. 

Core Media Type에 사용할 수 있는 폰트를 OTF, WOFF로 명시해 놨습니다.


* EPUB3.01 Core Media Type http://www.idpf.org/epub/301/spec/epub-publications.html#sec-core-media-types


EPUB2때처럼 강제사항은 아니지만(but this is not a conformance requirement;) EPUB3에서는 적합성 검사를 할 때 표준 폰트가 아니라는 메시지를 보여주고 있습니다. IDPF의 다음 정책을 예상해 볼 수 있을거예요.


다행히 전자책을 볼 수 있는 최신 스마트기기에서는 TTF, OTF, WOFF 폰트를 모두 지원합니다. 유통사마다 차이는 있지만 TTF와 OTF는 지원이 됩니다.


IDPF에서 EPUB3.01 Core Media Type에 TTF를 제외시키고 OTF와 WOFF만 포함시켰다면 다음 표준에서는 OTF와 WOFF 사용을 조금 더 강하게 강제할 수 있습니다. 그렇게 될지는 결정이 나기 전까지 아무도 모르지만, 지금까지의 방향을 놓고 보면 그럴 가능성이 높다고 봐야겠지요.


물론 TTF를 사용할 수 없게 하지는 않을거예요. EPUB2.0문서에서도, 3.0 문서에서도 뷰어(Reading system)는 가능한 다양한 폰트를 지원하도록 하고 있습니다. 다만, OTF폰트는 반드시 하나를 포함시켜야 한다(At least one file in OpenType format should always be included in the list.)는 정책을 강하게 가져갈 수 있다는 의미예요.


오래 전에 테스트 했을 때 일부 OS에서 OTF 폰트에 문제가 있어 TTF를 주로 썼는데 앞으로는 TTF보다는 OTF를 활용해야 겠습니다. 


TTF를 쓴다고 문제가 되냐?

전혀 문제 될거 없습니다. 앞으로도 문제가 될 가능성은 아주 낮아요.

TTF를 쓰든 OTF를 쓰든 독자들은 아무 생각 없습니다. 독자는 책만 잘 보이면 불만이 없을거예요.


그래도 전자책을 제작하는 사람이라면 TTF와 OTF의 차이는 알고 있어야 하지 않을까요?


오래 전에 OTF는 문제가 있으니 TTF를 권장한다는 글을 쓴 적이 있는데(http://epubguide.net/114), 그 내용을 바로잡기 위해 이 글을 작성합니다. 그때는 TTF가 더 나은 선택이었지만, 지금은 OTF가 '더' 적합합니다.




설정

트랙백

댓글

글꼴 암호화(난독) 처리

폰트 저작권 관련 내용을 살펴보다가 일부 유료 폰트는 임베디드 할 때 암호화(난독)를 해야한다는걸 알게 됐습니다. (요즘 폰트 유통사 매출이 좋지 않은가봐요. 낚시 공문 돌리네요ㅜ.ㅜ 종이책 표지를 전자책에 그대로 사용해도 딴지 걸어요. 저작권법 상에 문제는 없지만, 폰트 업체들의 사용 계약을 들이밀며... 돈 많은 출판사에서 '불공정 약관'으로 맞고소 안해주려나...)


전자책 DRM은 업체마다 조금씩 다르지만 대부분 이런 2단계로 처리합니다.


1. EPUB 파일 암호화

   - EPUB 파일은 zip 형태의 압축파일입니다. 

   - 전자책을 보려면 EPUB 파일을 다운로드 하는데 이 파일은 sdcard 등에 저장되기 때문에 복사가 쉬워요.

   - 하지만 EPUB 파일 자체에 암호를 걸어 EPUB 파일을 빼내도 다른 뷰어에서 볼 수 없습니다. 


2. 압축 해제된 파일의 개별 암호화

   - 다운 받은 EPUB 파일을 뷰어에서 볼 수 있도록 압축을 풀어놓습니다. 

   - 주요 콘텐츠(본문 xhtml 파일, 이미지 등)는 암호를 걸어 압축이 풀려있어도 볼 수 없습니다.

   - 메타데이터나 스타일 등 콘텐츠 내용이 담겨있지 않은 파일은 암호가 걸리지 않습니다.

   - 폰트 파일 역시 암호화가 되어 있지 않습니다.

       * 유통사마다 암호화 되는 파일이 다름


둘 중 한가지 방식이 아니고 1, 2단계가 모두 적용이 되는거예요. 

EPUB파일 자체를 내려받았을 경우는 문제가 되지 않습니다. 다만, 전자책을 보려면 압축이 풀려야 하는데 이때 폰트가 암호화되지 않아요. 유통사 DRM에서 폰트를 암호화 시키지 않기 때문에 전자책에 사용 가능한 라이선스를 구입해도 일부 폰트는 사용을 할 수 없습니다.


IDPF에서는 EPUB 파일에 폰트를 추가할 때 암호화를 시키도록 했기 때문에 유통사가 DRM으로 암호화 하지 않는다고 문제되지는 않아요. 그리고 DRM에서 폰트를 암호화 시키면 EPUB 파일에 암호화 된 폰트가 들어갔을 때 이중으로 암호가 걸려 다른 문제가 생길 수 있지요. 그래서 IDPF에서도 EPUB파일을 제작할 때 폰트를 암호화 하도록 표준을 제안했습니다.


폰트 암호화는 Sigil에서도 지원을 해요. 아주 간단히 클릭 몇번으로 암호화가 가능합니다. 

그런데 문제는 폰트 암호화를 뷰어가 지원하느냐예요.


아쉽게도 국내 유통사 중에 IDPF의 암호화 폰트를 지원하는 뷰어가 없네요.

뷰어가 지원을 안해도 콘텐츠는 볼 수 있어요. 다만 암호화된 폰트가 지원되지 않기 때문에 시스템 기본 폰트(혹은 뷰어 기본 폰트)로 책이 보입니다.


뷰어별 폰트 암호화 지원 여부(2017년 6월 22일 기준)

유통사

 구글 Playbook

리디움 

캘리버 

 iBooks

 국내 유통사*

 지원여부

 지원

지원 

지원

 지원

 미지원

* 국내 유통사 : 교보문고, 리디북스, 예스24, 알라딘


국내 전자책은 대부분 무료 폰트를 사용하고 있습니다. 

폰트 이용 범위 때문에 본문에는 네이버 나눔체, 코펍체, 은글꼴 등을 사용하는데 이제 표지 파일 같은 이미지에도 라이선스를 요구하는 추세입니다. 그럼 종이책과 다른 폰트로 전자책 표지를 만들거나 전자책까지 이용 가능한 라이선스를 구입해야겠지요.


전자책 라이선스까지 구입을 했다면 본문에 유료 폰트를 써도 됩니다. 이때 폰트 암호화가 필요한지 확인을 해야하고요.


아직은 국내 뷰어에서 폰트 암호화를 지원하지 않기 때문에 임베드시 암호화를 요구하는 폰트는 전자책에 사용하지 않는게 좋아요. 


낚시(?)질에 당하는 일 없도록 폰트 구입시 라이선스 사용 범위와 조건을 잘 확인해서 사용하세요~






설정

트랙백

댓글

단위 em의 의미, 그리고 이미지로 글자 넣을때 편리한 팁

전자책 편집을 하다보면 em, px, %, pt, cm 등 다양한 단위가 나옵니다. 그 중에 가장 많이 나오는 단위가 em과 px에요.


px는 큰 이슈가 없습니다. 절대적인 크기이기 때문에 변하지 않습니다. 뷰어에 따라 글자크기나 일부 설정이 변경될 수 있고, 해상도에 따라 같은 화면크기(예를 들면 5")에서 1px의 크기가 다를 수는 있지만, 어째든 1px이라는건 변함 없지요.


그런데 em은 가변적인 크기입니다. 그기가 마음대로 변해요. 이런 가변크기는 %도 있어요. 글자 크기를 얘기할 때 100%를 1em이라고 설명하곤 합니다. 


font-size : 100%; = font-size : 1em;


강의를 듣는 분들이 대부분 초보라 %와 em의 차이를 설명하면 더 혼란을 느끼실 것 같아 이렇게 얘기하는데 엄밀히 두 단위는 차이가 있습니다. 


1em은 '시스템 기본 글자 크기'라고 설명할 때도 있습니다. 하지만 이것도 정확한 1em의 의미는 아니에요.


아래 예를 볼까요?


.test_1em {

font-size : 1em;

}


.test_2em {

font-size : 2em;

}


.font_change {

font-size : 1em;

}


<div class="font_change">

<p class="test_1em">em의 의미</p>


<p class="test_2em">em의 의미</p>

</div>


두 문단의 글자 크기는 어떻게 보일까요?

test_1em의 글자 크기는 1em입니다.

test_2em의 글자 크기는 2em이고요.

그런데 div의 font_change의 글자 크기는 1em이에요.


1em이 시스템의 기본 글자 크기라면 두 문단의 글자 크기가 같아야되요.

그런데 text_2em의 글자 크기는 2em으로 나옵니다. 아래 이미지 1번이 test_1em, 2번이 test_2em이에요.


1em의 정확한 의미는 '현재의 글자 크기'예요. 


이러면 또 설명이 어려워집니다.


test_1em 속성(font-size : 1em;)이 지정된 문단에서 1em은 위 이미지 1번 크기예요. test_2em(font-size 2em;)이 지정된 문단에서 1em은 2번 크기예요.


한번에 이해를 하신 분도 계시겠지만 좀 헷갈릴 수 있어요. test_2em은 분명 2em으로 글자 크기가 지정돼 있는데 1em이 2em 크기라는 얘기잖아요.


다시 예를 들어볼게요.(font_?em이 font-size : ?em이라 생각해 주시고...)


이런 글자 크기의 문장을 만들고 싶어요.


<p>이런 <span class="font_2em">글자 크기</span>의 문장을 만들고 싶어요</p>


이건 이해가 쉽게 되지요? 기본 글자보다 큰 글씨니까 2em을 주면 되잖아요. 


이런 글자 크기의 문장을 만들고 싶어요.


<p class="font_2em">이런 <span class="font_?em">글자 크기</span>의 문장을 만들고 싶어요">


이건 어떤가요? font_?em 속성의 글자 크기는 몇 em일까요?(글자 크기가 1/2라고 가정하고)


1em이라고 생각한 분은 틀렸습니다.

0.5em이라고 생각한 분이 맞아요.


본문 글자 크기가 2em인데, 글자 크기를 1/2로 줄이려면 1em이어야 하지 않나요? 그런데 1/4인 0.5em이 되야한다니요?


1em의 글자 크기는 '현재 글자 크기'입니다. 그러니 <p class="font_2em">으로 감싸인 부분의 글자 크기가 '현재의 글자 크기'가 됩니다. 따라서 <span class="1em">은 <p class="font_2em">과 같은 크기인거예요.


설명이 무지 복잡하고 난해하지요? ㅜ.ㅜ 

설명 능력이 부족해 이보다 쉽게는 설명을 못하겠네요. 직접 스타일을 만들어 테스트해 보면 쉽게 이해하실거예요.


em은 %와 다릅니다.


em은 글자 크기를 기준으로 해요.

%는 단위가 적용된 개체를 기준으로 하고요.


따라서 글자 크기 1em은 100%와 같습니다. 1em은 글자크기이고, 글자에 적용된 100%는 글자 크기를 기준으로 하기 때문이에요.


그런데 이미지에 적용되면 둘은 큰 차이를 보입니다. 





이 이미지는 가로 46px, 세로 28픽셀 이미지예요. 이 이미지에 em과 %를 지정해 볼게요.


.img_h_1em {

height : 1em;

}

.img_h_100p {

height : 100%;

}


<p><img class="img_h_1em" alt="img" src="../Images/img.png"/>의 의미(이미지 height 1em)</p>

<p><img class="img_h_100p" alt="img" src="../Images/img.png"/>의 의미(이미지 height 100%)</p>


결과



이미지 height : 100%;와 이미지 height : 1em;일때 두 이미지의 결과를 보세요.


이걸 보고 '아!' 하고 무릎을 탁 치는 분이 계셨으면 좋겠어요.


느낌이 팍! 하고 오지 않나요?

저는 이걸 깨닫고 그동안 만들었던 많은 책을 떠올리며 '전부 수정했으면 좋겠다'는 생각을 했거든요.


무슨 얘기냐고요?


폰트에 없는 특수 한자, 특수 문자, 이미지로 된 글머리 기호...


예를 들어 훈민정음 언해본을 EPUB으로 만든다고 생각해 보세요.

언해본을 위해 폰트를 넣을 수 없는 상황이고.

텍스트로 넣으면 이렇게 보입니다.



나눔 옛한글 글꼴이 배포되기 전에는 훈민정음 언해본을 제대로 표현할 수 있는 폰트가 많지 않았어요. 그리고 유료였지요. 전자책 만들려고 비싼 유료 폰트를 사기 힘든 영세 출판사에서는 글자를 이미지로 만들어 넣을 수 밖에 없었습니다. 그럼 이런 문제가 생겨요.



글자 크기를 키우면 이미지로 된 글자가 너무 작아지고,



글자 크기를 줄이면 이미지로 된 글자만 너무 켜지고


좀 과장이 섞여있지만 경험해 보신 분들은 100% 공감하실거예요.


이럴때 em을 쓸 수 있어요.



글자 크기에 따라 이미지가 커졌다가



글자 크기가 작아지면 이미지도 작아짐


sample.epub 파일을 첨부하니 참고하세요.


1em은 '현재 글자 크기'의 단위입니다.

현재 문단의 글자가 3em이라면, 이 문단 안에 스타일을 넣을 때는 3em이 1em의 글자크기라 생각하고 스타일을 적용해야되요. 설명이 깔끔하지 못하지만, 연습해보시면 이해 할 수 있을거예요.


그리고 em은 이미지에도 사용할 수 있습니다.

이미지와 글자 크기를 딱 맞춰야 할 때 em을 쓰면 글자 크기가 변경되도 이미지가 그에 맞춰 변경되요. 대신 글자를 이미지로 넣었다면 이미지 크기는 기본 글자 크기의 4배 정도로 크게 넣어주세요. 그래야 독자들이 글자 크기를 키워도 이미지가 깨지지 않아요. 기본 글자 크기에 이미지를 딱 맞추면 글자를 키웠을 때 이미지 글자가 깨져보입니다. 


설정

트랙백

댓글

네이버 나눔명조 사용시 주의하세요.(2017. 06. 16일자 기준)

이 글은 2017년 6월 16일에 작성됐습니다. 네이버 나눔글꼴이 업데이트 되면 이 글 내용은 신경쓰지 않으셔도 되요.


전자책 만들 때 네이버 나눔명조 사용하시는 분들은 아래 내용 확인하고 작업하세요.


폰트 파일에도 버전이 있습니다. 폰트도 오류가 생길 수 있고 새로운 코드가 추가될 수도 있어요. 그럼 새로운 버전을 내게 됩니다. 사용자들은 폰트 버전을 확인하는 경우가 별로 없어 '나눔명조'하면 모두 똑같다고 생각을 하지만 버전에 따라 다를 수 있습니다.


제가 갖고 있는 나눔명조 파일은 


나눔명조 v3.01

나눔명조 v3.011

모바일 나눔명조


나눔명조 v3.01과 나눔명조 v3.011은 파일명이 똑같이 NanumMyeongjo.ttf(otf), 글자 모양도 똑같아 그냥 보면 구분이 되지 않습니다. 파일 버전을 확인하려면 폰트 관리자로 열어봐야되요.



폰트 관리자로 파일을 열면 이렇게 폰트 버전을 확인할 수 있습니다.


갑자기 폰트 얘기를 왜 꺼냈냐 하면, 나눔명조 3.01버전에 문제가 있어서 이 버전으로 전자책을 만들면 모바일 뷰어에서 오류가 나기 때문이에요.


아래 이미지를 보세요. 같은 EPUB 파일에 한쪽은 나눔명조3.01, 다른 한쪽은 나눔명조3.011 버전을 적용했을 때 모바일(안드로이드) 기기에서 이렇게 보입니다. 본문에 나눔명조를 적용했는데 3.01은 굴림/고딕 계열의 시스템폰트로 대체됩니다. 


왼쪽이 나눔명조 3.01 오른쪽이 3.011 버전. 폰트 외 모든 설정은 동일함


이 문제를 확인한건 한참 됐는데 그동안은 문제라 생각하지 않았어요. 네이버 홈페이지(http://hangeul.naver.com/font)에서 최신 버전(3.011)을 배포하고 있었거든요. 1년 전인지 2년 전인지는 정확히 기억 안나지만 문제를 파악하고 새로 폰트를 내려받았을 때 수정된 버전이 올라와 있었습니다. 수정 버전을 넣으니 정상으로 보였고요. 


그런데 최근(2017년 7월 16일 기준) 다시 받아보니 문제가 있는 구버전 파일로 바뀌었습니다. 

이유는 모르겠지만 최근에 네이버에서 나눔명조 파일을 다운로드 받은 분이라면 나눔명조 파일로 전자책을 만들면 안드로이드 계열 스마트폰에서는 명조 글꼴이 반영되지 않을거예요. 아이폰 계열은 확인해 보지 못했습니다. 


PC는 나눔명조3.01이 반영되기 때문에 휴대폰에서 확인하지 않으면 이상 없다고 생각하고 유통사에 등록할 수 있습니다. 그러니 등록 전에 꼭 휴대폰에서 확인을 해보세요.



만약 나눔명조를 반영했는데 나눔명조가 아닌 시스템 기본 폰트가 반영됐다면 이 폰트를 다운받아 사용하세요. 


은바탕도 비슷한 문제가 있습니다. 은바탕은 버전이 1.02로 동일한데 2008년에 수정된 배포본이 있어요. 버전 변경은 되지 않아 나눔명조처럼 버전으로 확인은 어렵고, EPUB 파일에 넣어 스마트폰 뷰어로 확인해 봐야 문제가 있는지 알 수 있습니다.


은글꼴에 문제가 있는 분은 이 파일을 다운받아 사용하시면 정상으로 보일거예요.




이 글은 2017년 6월 16일에 작성됐습니다. 네이버 나눔글꼴이 업데이트 되면 이 글 내용은 신경쓰지 않으셔도 되요.

설정

트랙백

댓글

전자책(EPUB)의 품질(Quality)

얼마 전 모 출판사 영업자를 만났습니다.

전자책 제작과 관련해 얘기를 하는데 제작 업체와 스타일을 맞춰 만족할 만한 수준까지 오는데 1년 가까이 걸렸다고 하더군요. 이 작업을 다시 하고싶지 않아 같은 업체에 제작을 계속 맡긴다고 했습니다.


이 얘기를 듣고 깜짝 놀랐습니다.

무슨 스타일을 맞추는데 1년식이나 걸리지?

종이책을 기준으로 스타일을 잡고, 출판사에서 수정해 달라는 부분 수정하면 되는데 스타일을 잡는데 1년이 걸린다는건 상식적으로 이해가 되지 않았습니다.  


그런데 최근에 제게 문의를 주신 출판사 대표님을 보고 출판사와 제작사 사이에 무슨 일이 벌어지는지 이해를 할 수 있게 됐습니다. 출판사 대표님이 제작사에 콘텐츠 문제를 몇가지 얘기하며 수정을 요청했는데 제작사에서는 대표님이 전자책을 잘 몰라 그런다며 'EPUB의 특성'이라는 답변을 받았다고 합니다. 정말 대표님의 전자책에 대한 이해가 낮아서 그런건지 저한테 샘플을 보내 확인해 달라고 하셨습니다. 


전자책(EPUB) 파일은 뷰어로 봅니다.

뷰어로 볼 때 글자와 이미지가 제대로 보이면 문제 없다고 생각하지요.

그런데 뷰어로 보이는 부분이 전부가 아닙니다.

뷰어에 글자와 이미지 같은 콘텐츠가 배치되도록 하는 HTML과 CSS라는 코드가 정말 중요합니다.

제가 얘기하는 전자책의 품질은 이 부분입니다.


제가 확인한 제작사의 EPUB은 품질이 형편없었습니다. 

이름만 대면 알만한 규모가 큰 제작사였는데 이 파일을 만든 사람이 전자책 제작 경험이 있나 싶을 정도로 수준이 낮았습니다. 이러니 스타일 잡는데 1년이나 걸리지 하는 생각이 들더군요.


1. 불필요한 코드와 스타일 남발의 문제


* 콘텐츠와 제작사 공개를 원치 않아 내용 파악이 가능할 정도만 남기고 모자이크 처리를 했습니다. 모자이크 윤곽만으로 설명에 대한 이해가 어렵더라도 양해 부탁드립니다. 


불필요한 스타일과 코드가 가득한 제작사의 EPUB(왼쪽)과 이를 수정한 코드


제작사의 EPUB은 필요 없는 코드와 스타일이 가득했습니다. CSS 스타일시트에 정의하지 않은 스타일시트가 본문에 쓰이기도 했고, 


들어갈 이유가 '전혀' 없는 코드도 가득했습니다. 수십만원을 받고 전자책 제작을 전혀 모르는 사람이 편집 프로그램으로 대충 만든 결과물을 제공했던 것이지요.



<span> 태그는 단독으로 쓰일 이유가 전혀 없다. 


쓸 필요가 없는 <span>태그를 남발하고 class="db dbron2 co_23" 같은 의미 없는 속성을 반복해서 사용한다. <p class="txt b1 t1"> <p class="txt b1 t1"> 같은 속성도 쓸 이유가 전혀 없는데 거의 모든 본문에 사용됐다. 



이렇게 만든 결과물이 뷰어에서 제대로 보일리 없습니다. 아래 이미지는 제작사에서 만든 결과물이 뷰어에서 글자크기, 페이지 구분에 따라 어떤 문제가 생기는지 보여줍니다.



이미지의 배치 순서를 보면 아래처럼 오른쪽 어울림 처리한 작은 이미지가 먼저 나오고, 가운데 정렬 된 큰 이미지가 다음에 나와야 한다.(수정한 파일)




제작사의 원본 파일은 일부 뷰어에서는 제대로 보이지만 글자크기나 화면 크기에 따라 엉뚱한 결과가 나온다. 뒷쪽에 들어간 가운데 정렬 이미지가 먼저 나오고, 오른쪽 어울림으로 넣은 이미지가 본문 내용과 상관 없는 자리에 배치됐다.(제작사 원본 파일)


이런 문제는 'EPUB의 특성'이 아닙니다. 그냥 제작을 잘못 한 것 뿐입니다. 그런데 이 문제를 수정해 달라고 하자 EPUB의 특성이라는 답변을 받았다고 합니다. 쓸데 없는 코드가 반복되고, 필요 없는 스타일을 의미 없이 추가하다 보면 제작하는 프로그램에서는 제대로 보이지만 다른 뷰어에서는 엉뚱한 결과가 나올 수 밖에 없습니다. 이 문제를 샘플이 아주 잘 보여주고 있습니다.





2. '실력 없음'은 EPUB의 특성이 아니다.


문제는 이 뿐 아닙니다. 편집자가 CSS의 속성에 대한 이해만 조금 있어도 해결할 수 있는 문제조차 수정이 제대로 되지 않았다고 합니다. 



아래 이미지를 보면(모자이크 처리로 문제점이 한눈에 들어오지 않을 수 있습니다) 왼쪽 이미지는 본문 안에 배치된 사진이 화면 상단에 여백 없이 붙습니다. 오른쪽 이미지는 화면 상단과 사진 사이에 여백이 들어가지요.


배경색이 없었다면 본문 사진의 상단 여백은 아무 문제가 되지 않습니다. 그런데 본문에 배경색이 들어가면 오른쪽 처럼 상단에 여백이 없을 경우 편집에 문제가 있는 것 처럼 보입니다. 편집자라면 당연히 눈에 거슬릴테고 수정을 요청하겠지요.



왼쪽이 제작사, 오른쪽이 수정한 파일. 이미지에 여백을 살짝 주면 해결할 수 있다. 절대 EPUB의 특성 때문에 생기는 현상이 아니다.


EPUB의 특성은 맞습니다. 글자 크기나 화면 크기에 따라 사진이 앞쪽에 들어갈 수도 있고 텍스트 사이에 나올 수도 있습니다. 이렇게 화면 위에 텍스트 없이 사진이 먼저 나오지 않을 수 있지요. 저도 이런 부분을 놓치고 편집한 적이 많이 있습니다.


그런데 검수 과정에서 눈에 띄지 않아 지나친 것과, 출판사에서 문제점을 발견해 수정을 해 달라고 했는데 'EPUB의 특성' 운운하며 문제가 없다고 답변한 것은 차원이 다릅니다. 이 문제 역시 간단히 수정할 수 있었음에도 불구하고 제대로 조치를 취하지 않았다면 이건 실력이 없는것입니다. 



이런 예는 또 있습니다. 아래 이미지는 원래 본문에 텍스트와 오른쪽 어울림으로 이미지가 배치돼야 합니다. 그런데 이 역시 글자크기/화면 크기에 따라 이렇게(왼쪽 이미지) 본문 끝에 배치가 되었습니다. 어떤 뷰어에서는 제대로 보이지만 뷰어에 따라 이런 엉뚱한 결과가 나온 것입니다. 이 역시 간단히 수정을 할 수 있었습니다(오른쪽 이미지) 

수정을 하고 나니 어떤 뷰어에서도 오른쪽과 같은 오류는 나오지 않았습니다. 항상 왼쪽 이미지처럼 본문과 배치가 됐습니다. 수정이 어렵지도 않습니다. CSS에서 속성 한두개만 수정하면 끝나는 아주 간단한 작업입니다. 



이미지는 글자크기/화면 크기와 상관 없이 편집자가 배치한 곳에 표시되야 한다. 본문과 상관 없는 곳에 이미지가 표시되서는 안된다





3. 진짜 EPUB의 특성일 수도 있다. 하지만 방법이 없는건 아니다.


'EPUB의 특성'으로 어쩔 수 없는 부분도 있습니다. 아래처럼 이미지 아래에 텍스트로 캡션을 넣을 경우 한 페이지 내에 이미지와 캡션이 들어갈 공간이 없으면 다음 페이지로 텍스트가 넘어갑니다. 이건 진짜 EPUB의 특성으로 태그와 CSS를 이용해 해결하기 어렵습니다.


그래도 해결 방법이 전혀 없는건 아닙니다. 

저는 전자책을 제작할 때 캡션을 텍스트로 넣을지, 이미지로 넣을지를 고민합니다. 대부분 텍스트로 넣는데 간혹 텍스트를 이미지에 포함시키기도 합니다. 어떤 경우에 이미지로 넣는지 설명은 불가능합니다. 책의 특성에 따라 그때 그때 달라지기 때문이지요.




이 책에도 이미지 크기가 세로로 길어 캡션이 다음페이지로 넘어가는 경우가 생겼습니다. 대표님은 이게 마음에 들지 않아 한 페이지에 표시되기를 원했습니다. 


이 경우 해결 방법은 2가지입니다. 이미지에 텍스트를 넣어 다음 페이지로 넘어가지 않도록 하는 방법과 '제대로 된 설명'을 통해 이 문제를 받아들이도록 하는 것이지요. 저라면 제대로 된 설명을 해서 설득을 했을 것입니다. 


EPUB의 특성은 맞는데 'EPUB의 특성이니 어쩔 수 없다'는 말도 안되는 답변 대신, 왜 이런 문제가 생기고, 이미지로 넣었을 때의 장단점과 텍스트로 넣을 때의 장단점을 제대로 전달한 후 선택을 하도록 했어야합니다.




꾸준히 책을 내는 규모있는 출판사는 1년씩 걸려 스타일을 잡아주고, 가끔 전자책을 제작하는 작은 규모의 출판사에는 'EPUB의 특성'이라며 간단히 수정할 수 있는 것 조차 수정하지 않았다는건 말이 되지 않습니다.


그 전에, 스타일을 맞추는데 1년이 걸린다는 것 자체가 말이 되지 않습니다. HTML과 CSS에 대해 제대로 이해를 하고, 전자책이 홈페이지와 어떤 차이가 있는지를 알면 스타일을 맞추는데 1년이 걸리지 않습니다. 책 한권만 작업하면 출판사가 원하는 편집이 무엇인지 파악할 수 있어야지요.


출판사도 '전자책의 품질'에 관심을 가져야 합니다. 제작사에 맡겨놓고 결과물을 제대로 보지 않으면 이런 문제가 계속 생길 수 밖에 없습니다. 제작사에서 온 EPUB 파일을 유통사 뷰어에 넣고 제대로 보이는지 문제는 없는지 확인해야 합니다. 확인해서 문제가 있다면 수정을 해달라고 요구를 해야하고요.


끝으로...

전자책(EPUB)은 종이책과 다릅니다. 그래서 늘 종이책과 전자책을 똑같이 만들지 말라고 강조를 합니다. 하지만 이 차이를 제작 실력 부족을 감추기 위해 사용해서는 안됩니다. 전자책과 종이책은 분명 다르지만 'EPUB의 특성'을 핑계로 수정 가능한 '문제'를 EPUB의 '특성'으로 속이는 짓을 하는 전자책 제작자는 사라졌으면 하는 바람입니다. 



(출판사 대표님의 요청으로 일부 내용을 수정했습니다.)


설정

트랙백

댓글

EPUB2를 EPUB3로 변환해 보자 - 2) Sigil로 변환하기

앞 글(http://epubguide.net/224)에서 EPUB2를 EPUB3로 변환해야 하는 상황을 설명드렸습니다. 사족이 너무 길어져 글을 나누게 됐지만, 전자책을 만들다 보면 EPUB2를 EPUB3파일로 변환해야 하는 일이 생길 수 있습니다.


이번 글은 Sigil에서 EPUB2를 EPUB3로 변환하는 방법을 설명드리려고 합니다. 


EPUB2에서 epub:type 속성을 사용하거나 aside 등의 태그를 쓰면 아래처럼 오류가 발생합니다. 



뷰어에서 보면 아무 문제도 없지만, 유통사에 등록할 때 오류 때문에 등록이 안된다고 할 수 있어요.

오류를 없애는 방법은 2가지. 


1. 팝업 주석을 없애고 링크로 연결하거나 미주 처리 한다.

2. EPUB3로 바꾼다.


1번은 고려 대상이 아니기 때문에 EPUB3로 바꿔야 합니다. EPUB2를 EPUB3로 바꾸는 방법은 생각보다 간단해요.




1단계. 파일의 패키지 버전을 3.0으로 바꾼다



OPF 파일의 package version="2.0" 을 version="3.0"으로 수정합니다.

하지만 Sigil에서 수정을 하면 지원하지 않는 버전이라면서 2.0으로 바뀝니다. 

그래서 압축파일을 풀고(EPUB이 zip 압축 파일이라는건 설명 안하겠습니다.) 메모장이나 텍스트 에디터로 version="3.0"으로 수정을 합니다.


수정을 하면 다시 압축을 하고 확장자를 epub으로 수정합니다.




Sigil의 '기본설정'에서 파일 버전을 3.0으로 수정합니다.(안해도 될 것 같은데 확인해 보지는 않았어요)

그리고 파일을 Sigil에서 불러옵니다. 그럼 Sigil 상단 제목창에 EPUB3.0으로 표시됩니다.


여기까지 했다면 50%는 성공한거예요.





2단계. 목차를 생성한다.


EPUB2를 EPUB3 로 변환했기 때문에 NCX파일의 목차는 그대로 있습니다. 하지만 '차례' 창에 목차가 나타나지 않습니다. EPUB3 파일은 목차정보를 XHTML로 만들기 때문에 NCX파일이 필요 없습니다. NCX파일이 있으면 EPUB2 뷰어와 호환성을 유지할 수 있으니 EPUB2용 NCX 목차는 그대로 두고, EPUB3를 위한 nav.xhtml 파일로 목차를 새로 생성합니다. 


패키지 버전을 EPUB3로 변경하고 Sigil에서 불러오면 nav.xhtml이 하나 만들어집니다. 이게 EPUB3의 목차 파일입니다.



여기에 목차를 넣게 되는데, 목차를 만드는 방법은 EPUB2와 동일합니다.

메뉴의 [도구 > 차례 > Generate Table of Contents]로 생성합니다.






제목이 생성되면 오른쪽에 있는 '차례' 창에 목차가 표시됩니다.





3단계. 메타데이터를 수정합니다.


2단계까지 하고 EPUBCheck를 실행하면 오류가 몇개 나옵니다. 

그런데 오류를 보면 전부 OPF파일에서 발생한거예요.

아랫쪽에 toc.ncx 파일 오류가 있지만 이건 샘플파일 만들면서 NCX 파일을 정리하지 않아 그런거고, 정상적인 EPUB2파일이라면 2단계까지 했을 때 epub:type, aside, ruby 등의 오류는 사라지고 opf파일 오류만 남습니다. 



그리고 하늘색으로 폰트에 관한 INFO가 뜨는데 이건 오류가 아니라 신경쓰지 않아도 됩니다. (이렇게 쓰면 '몰라서 그러는거 아냐?' 라는 의심의 눈초리를 보내는 분이 계신데 ㅎㅎ, EPUB Publications 3.0.1에 있는 EPUB Core Media Types에 폰트는 OpenType, Woff를 지원하고 TTF는 없습니다. 그래서 TTF 폰트를 non-standard font type으로 인식하는 것 같아요^^)



opf파일 오류는 모두 메타데이터 때문입니다. EPUB2에서 EPUB3로 넘어가면서 메타데이터 정의가 많이 변경됐습니다. 그래서 EPUB2의 OPF파일에 있는 메타정보의 속성과 값을 변경해 줘야합니다.


EPUB3에서 필수로 요구하는 메타정보는 아래와 같습니다.


1. unique-identifier : <dc:identifier id=”pub-id”>urn:uuid:A1B0D67E-2E81-4DF5-9E67-A64CBE366809</dc:identifier>

2. 책 제목 : <dc:title>책 제목</dc:title>

3. 언어 : <dc:language>ko</dc:language>

4. 수정일 : <meta property=”dcterms:modified”>2011-01-01T12:00:00Z</meta>


여기에 추가로 '성실한' 편집자라면 ISBN, 출판사명(Publisher), 저자명 등의 추가 정보를 입력하면 됩니다.


Sigil의 메타데이터 편집기를 열고, 입력되어 있는 정보를 수정하면 되는데, 반드시 수정해야 하는 정보가 있고 EPUB2에 있는 정보를 그대로 사용할 수 있는 데이터도 있습니다.


메타 정보는 책마다 다르기 때문에 하나씩 설명하기는 어렵고 예로 보여드릴게요.


EPUB3 메타정보 

 EPUB2 메타정보

 

<dc:title>거울 나라의 앨리스</dc:title>

<dc:language>ko</dc:language>

<dc:identifier>urn:isbn:979-11-000000</dc:identifier>

<dc:publisher>심야책방</dc:publisher>

<dc:creator id="cre">루이스 캐럴</dc:creator>

<meta scheme="marc:relators" refines="#cre" property="role">aut</meta>

<dc:identifier id="BookId">urn:uuid:e0d7dc1c-afa9-49ba-9d25-1fce2f4857b1</dc:identifier>

<meta property="dcterms:modified">2017-06-02T14:30:40Z</meta>


<dc:title>거울 나라의 앨리스</dc:title> 


<dc:language>ko</dc:language>


<dc:identifier opf:scheme="ISBN">979-11-00000000</dc:identifier>


<dc:publisher>심야책방</dc:publisher>


<dc:creator opf:role="aut">루이스 캐럴</dc:creator>


<dc:identifier opf:scheme="UUID" id="BookId">urn:uuid:e0d7dc1c-afa9-49ba-9d25-1fce2f4857b1</dc:identifier>


<dc:date opf:event="modification">2017-06-02</dc:date>



빨간 색으로 표시된 부분이 수정되야 하는 메타데이터입니다. EPUB3에서는 opf:scheme, opf:role 등의 형식을 사용하지 않기 때문에 이 부분을 EPUB3에 맞게 수정을 합니다. 수정 방법은 간단합니다. 메타데이터 편집기에서 오류가 있는 정보를 삭제하고 다시 입력하면 되요.


이렇게 수정을 하고 EPUBCheck로 적합성 검증을 하면 오류가 사라집니다.



참고로, nav.xhtml은 전자책 뷰어에서 보이지 않습니다. 뷰어의 [목차] 메뉴에서 보는 정보여서 스타일로 편집을 하지 않아도 되지만, 그래도 스타일을 넣고싶다면 아래 두 태그의 스타일을 적용하면 됩니다.


/*목차*/ ol { margin-bottom : 1em; } li { font-size : 1em; margin-left : 1em; margin-bottom : 1em; list-style-type: none; }


제가 임의로 잡은거라, ol, li 태그의 스타일을 원하는 형태로 수정해 주면 됩니다.


그리고 이 목차 파일을 뷰어에서 볼 수 있게 하려면 opf 파일을 수정해 주세요.

<itemref idref="nav.xhtml" /> /*목차가 뷰어에 표시되고 [목차] 메뉴로 볼 수 있음*/

<itemref idref="nav.xhtml" linear="no"/> /*목차가 뷰어에 표시되지 않고 [목차] 메뉴로 볼 수 있음*/


여기까지 하고 저장을 하면 EPUB2 파일이 EPUB3 파일이 됩니다.

동영상, MP3 이런거 없어도 package version="3.0", nav.xhtml, 그리고 일부 메타정보가 수정되면 EPUB2와 똑같아 보여도 EPUB3 파일이에요.


오늘은 여기까지...




설정

트랙백

댓글

EPUB2를 EPUB3로 변환해 보자 - 1) 왜 변환해야 하지?

아래의 긴 내용을 간단히 요약하면....

국내 유통사는 EPUB2에서 ruby, aside, mark 등의 태그를 허용합니다. 하지만 이 태그는 EPUBCheck로 검사하면 오류가 나기 때문에 구글 플레이북 같은 곳에 등록하려면 EPUB3로 변환을 해야합니다. 


EPUB2, EPUB3의 차이를 알고 계신가요?


많은 분들이 'EPUB3는 멀티미디어를 포함한 콘텐츠' 정도로 막연히 알고 있습니다. 동영상이나 MP3가 포함되면 EPUB3고 그렇지 않으면 EPUB2라는 정도로 알고 있습니다. 이렇게 알고 있다면 '완전히' 잘못 알고 있는 것입니다.


EPUB2와 EPUB3를 구분할 때 멀티미디어(동영상, MP3등)의 포함 여부는 '전혀' 중요하지 않습니다. 


정확히 EPUB2와 EPUB3의 차이를 구분하기는 어렵습니다. 너무 많은 요소들이 섞여있기 때문에 몇줄로 이 둘을 규정할만한 설명을 하는건 불가능합니다. 이 둘의 차이를 가장 명확히 설명해 놓은 문서가 IDPF에서 관리하고 있는 EPUB2.0.1EPUB3.0.1 표준 명세서인데 이 내용을 제대로 읽고 이해하기는 어렵지요. 그리고 전자책 편집자라 해도 이 내용을 알 필요는 없습니다.


어렵긴 하지만, EPUB2와 EPUB3의 차이를 정리해 보면 이렇습니다.

구분 

 EPUB2(2.0.1)

EPUB3(3.0.1)

 HTML

 XHTML 1.1 사용 

 HTML5 사용(하위 버전 포함)

 CSS

 CSS2.0 

 CSS2.1, CSS3 (하위 버전 포함)

 스크립트 등

 미지원 

 지원(스크립트, MathML, 미디어오버레이 등)

 목차

 NCX 파일 

 XHTML 파일 

 뷰어

 네트워크에 연결되지 않은 흑백 디스플레이를 고려함 - 외부 링크, 멀티미디어, 색상 등에 제한이 있음.

 EPUB2이전 버전을 지원(을 권장)하고 광범위한 콘텐츠 유형을 지원할 수 있다.


이렇게 정리를 해도 복잡하지요? XHTML은 뭐고 HTML5는 뭔지, CSS2는 뭐고, CSS3 는 뭔지, 이런 것들이 외계어처럼 해석이 안되는 분들이 많을거예요. 오늘 설명드리려는 내용은 사실 이런 내용과 별 상관 없습니다. 


그렇다면 왜 이런 내용을...?

EPUB2와 EPUB3를 잘 비교해보세요. MP3, 동영상이 둘의 구분하지 않습니다. 비교표를 잘 보시면 EPUB3는 EPUB2를 모두 포함하고 있다는 것을 알 수 있습니다. 이해하기 쉽게 설명하자면 이렇습니다.


MS-DOS 시절 사용하던 HWP2.0 프로그램은 HWP2012로 만든 한글 문서를 읽을 수 없습니다. 그런데 HWP2012프로그램은 HWP2.0 문서를 읽을 수 있지요. 


EPUB3도 마찬가지예요. EPUB2로 만든 전자책은 EPUB3로 만들 수 있습니다.

EPUB2는 텍스트와 이미지, EPUB3는 MP3, 동영상이 포함된 콘텐츠로 둘을 구분하는 것이 아니고, 파일의 구조 차이입니다. 그러니 EPUB2로 된 파일은 EPUB3로 변환이 가능한 것이지요.


이게 왜 필요할까요?

어차피 EPUB3 뷰어에서 EPUB2 파일도 볼 수 있게 되어 있는데 왜 변환할 일이 있을까요?


제작 작업을 하다 보니 이런 일이 필요할 때가 생기더라구요.


왜 변환이 필요한지 설명을 하려면 또다시 기술적인 내용이 조금 들어가야 되는데... ㅜ.ㅜ


EPUB2는 아주 오래된 버전이에요. 그래서 요즘 나오는 스마트폰서 구현 가능한데 표준이 따르지 못하는 부분이 있습니다. 예를 들면 ruby, mark, aside 등의 태그처럼이요.



루비ruby 태그는 ***를 위해 만들졌는데 활용도가 다양해요.  루비, 일본어 라는 단어 위에 영문 표기와 *표를 붙인게 보이지요? 시중에 나온 책중에 이런 편집이 많이 있습니다. 이걸 해주는게 ruby 태그예요.


mark는 형광펜 스타일을 쉽게 표현해 줍니다. mark라는 단어에 적용된 노란색 바탕을 표현하려면 CSS로 배경색 스타일을 지정하고 span 태그로 스타일을 적용해 줘야 하는데, mark 태그를 사용하면 <mark>mark</mark> 이렇게 간단히 표현할 수 있습니다. 


aside는 주석을 표현하면서 설명을 한 적이 있습니다.(http://epubguide.net/135) aside가 주석을 위한 태그는 아니예요. 의미적 마크업(Semantic Markup)이라고 해서 section, nav, aside 등의 태그가 새로 추가됐는데 aside가 주석을 표현할 때 유용해서 다른 태그보다 사용을 많이 합니다.


이런 태그는 EPUB2에서 사용하면 오류가 납니다. 원칙을 철저히 지키면 사용할 수 없는 태그예요. 그런데 전자책을 제작하다 보면 이 태그들이 꼭 필요합니다. mark 태그는 스타일로 대체할 수 있다 해도, ruby와 aside는 대체가 어렵거나 대체하려면 코드가 엄청 복잡해지거든요.


그러다 보니 EPUB2 파일로 제작을 할 때 이런 태그를 쓰게 됐고, 국내 유통사들은 출판사의 요청을 받아서 이런 태그가 문제 없이 뷰어에서 표현되도록 해놨습니다.


여기엔 논란의 소지가 조금 있어요. EPUB2 표준을 위반해서 이런 태그를 사용해도 되는가 하는 문제입니다.

그런데 엄밀히 말하면 표준 위반이라고 할 수도 없습니다. 설명하자면 표준문서 항목까지 열거하며 must, should, recommand 등의 단어 의미까지 따져야 하니 간단히 설명을 드릴게요.


법에 보면 상위법과 하위법이 있잖아요. 전자책을 만드는 표준에도 상위, 하위 법이 있어요. EPUB은 W3C라는 단체가 만든 웹표준을 지키고 있습니다. W3C의 웹 표준이 '헌법' 같은 상위법이에요. 그리고 EPUB 표준은 민법, 상법 같은 하위법입니다. 민법, 상법에 구체적으로 명시되지 않은 내용이 있다면 상위법인 헌법을 따르지요? 


EPUB2는 웹 표준의 하위법입니다. 하위법에 포함되지 않은 내용인데 시대가 변하면서 필요해 졌고, 그게 상위법에 나와있다면 하위법(EPUB2)에는 나와있지 않지만 상위법(웹표준)을 따르는게 맞겠지요.


EPUB2 표준에서는  ruby, aside, mark 같은 태그에 대해 명확히 명시하지 않았습니다. 물론 XHTML1.1을 따른다고 했으니 문제의 소지는 있지만 뷰어가 이런 태그들을 표현하면 안된다는 내용은 없습니다. 그러니 국내 유통사가 EPUB2에서 지원하지 않는 ruby, aside, mark 등의 태그를 지원해도 표준에 위배되는 것은 아닙니다. 


사족이 정말 길어졌는데, 중요한건 여기부터!!!


EPUB2에 ruby나 aside 태그를 사용하면 EPUBCheck에서 오류가 납니다. 국내 유통사는 문제되지 않아요. 오류가 나도 이런 태그들은 허용을 하거든요. 그런데 구글 플레이북 같은 플랫폼에서는 EPUBCheck에서 오류가 나는 콘텐츠를 허용하지 않습니다. 


IDPF의 표준을 따라 ruby 태그로 글자 위에 점이나 영문설명을 넣거나, 팝업 주석을 넣으려면 EPUB3로 만들어야 하는데 국내 유통사 중 EPUB3 파일을 받지 않는 곳이 많아요. EPUB2로 팝업 주석을 넣고 ruby 태그를 쓰면 구글 플레이북에는 유통을 할 수 없습니다. 그러니 국내 유통을 위해서는 EPUB2로, 구글에 등록하려면 EPUB3로 파일을 만들어야 하는거지요. 


그럼 시길에서 EPUB2 파일을 EPUB3로 어떻게 변환을 할까요?


궁금하면 다음편을 봐주세요 ^^






설정

트랙백

댓글

이미지에 캡션 달기


오랜만에 글을 올리네요.

4월 28일에 글을 올리고 거의 한달만입니다. 강의도 있고, 긴급히 제작해야 하는 전자책도 생기고 해서 정신이 없었어요.


오늘은 이미지에 캡션 다는 스타일을 알려드리려고 해요.

CSS가 익숙한 분들이야 별거 아니겠지만, 이미지 캡션이 처음인 분들은 막막할거예요.

방명록에 캡션을 달았는데 몇가지 문제가 생긴다고 해결 방법을 묻는 글이 올라와서 한번 정리해 보겠습니다.


이미지에 캡션이 달린 책을 몇권 봤는데 많은 분들이 사용하는 방식은 이런거였습니다.


<div class="img_style"><img.....></div>

<p class="img_caption"> 캡션 내용</p>

<p>본문</p>


가장 간단한 방법이긴 한데, 이미지와 캡션 한 묶음으로 움직이지 않아요. 그리고 float : left; float:right;를 했을 때 제대로 적용되지 않고요. 캡션 내용이 엄청나게 많아져도 문제가 됩니다. 문의 주신 분은 이 부분의 문제를 해결하지 못하셨던 것 같아요.


제가 쓰는 캡션 스타일은 이렇습니다. 샘플파일 다운로드 하면 뷰어에서 확인이 가능해요.


img {

width : 100%;

}


.img_caption {

font-size : 0.7em;

text-align : justify;

display : block;

margin : 0 0.5em 0 0.5em;

}


.img_center {

width : 100%;

text-align : center;

text-indent : 0;

}


.img_left {

float : left;

text-indent : 0;

text-align : left;

margin : 1em;

padding-right : 1em;

width : 45%;

}


.img_right {

float : right;

text-indent : 0;

text-align : right;

margin : 1em;

padding-left : 1em;

width : 45%;

}


<p class="img_right"><img alt="img007" src="../Images/img007.png"/><span class="img_caption">앨리스는 이내 토끼가 부채와 하얀 양가죽 장갑을 찾고 있다는 걸 알아챘다. </span></p>


/*p태그 대신 div 태그를 사용해도 됩니다.*/



줄간격, 여백, 글자색 등 스타일은 편집자가 원하는 대로 수정이 가능하니 책에 맞게 수정해서 사용하세요.


캡션을 넣을 때 이미지가 들어가는 상자를 하나 만들고 그 안에 이미지와 캡션을 같이 넣어 이미지와 캡션이 항상 한 묶음으로 움직이도록 만들어 놨습니다. 그래서 캡션 내용이 길어 다음 페이지로 넘어가더라도 캡션이 본문과 섞이지 않고 이미지 상자 안에 남아있게 됩니다.


샘플파일을 뷰어에서 보면 이렇게 나옵니다.


문의 주신 분의 설명 내용을 구현해 보려고 캡션을 과장되게 넣어봤습니다.


샘플은 [심야책방 세계문학 시리즈 '이상한 나라의 앨리스']에서 텍스트를 일부 발췌해 사용했습니다.





이 스타일이 실제 적용된 책입니다.



[시대의창 : 서울, 도시의 품격]



[시대의창 : 권력에 맞선 상상력 - 문화운동 연대기]


설정

트랙백

댓글

복잡한 이미지+텍스트 편집 : shape-outside

오랜만에 글을 올리네요.

한달 좀 넘게 여행을 다녀와서 현실 적응을 하느라 한참 제정신이 아니었어요.


오늘은 고난도 기술을 소개하려고 합니다.  


만약 이 잡지 표지를 한장의 이미지가 아닌, 이미지 위에 텍스트를 얹어 편집해야 한다면?

가운데 인물이 있고, 좌우에 텍스트를 배치해야 되요. 그런데 글자가 인물 안으로 들어가면 안되고 인물 주위에 자연스럽게 배치되야 합니다. 그리고 가장 중요한거. 글자 크기가 변경되도 편집이 틀어지면 안되고요. 어깨 아랫쪽으로 글자가 내려가는것 까지는 막을 수 없지만, 글자 크기가 커져도 얼굴 쪽으로 글자가 넘어가면 안됩니다. 가능할까요?



div 태그와 display : box; display :table; 등의 속성을 이용하면 비슷한 위치에 글자 배치는 가능해요. 그런데 글자를 키우면 틀어질거예요. 글자 크기가 변경 가능하면서 얼굴 선을 따라 곡선형으로 글자 배치하는건 정말 어렵고요. 이럴 때 쓸 수 있는 CSS속성이 있습니다. 예전에 한번 소개한 적이 있는 속성(http://epubguide.net/207)인데 어렵긴 하지만 활용도는 아주 높아요.


shape-outside

-webkit-shape-outside


The shape-outside CSS property uses shape values to define the float area for a float and will cause inline content to wrap around the shape instead of the float's bounding box.


자세한 내용은 여기로 https://developer.mozilla.org/ko/docs/Web/CSS/shape-outside


이 속성이 어떤건지 바로 이해를 하고 싶다면 아래 사이트에 들어가 보세요.


http://galjot.si/css-exclusions#examples-print


아랫쪽으로 쭉 내려가면 텍스트를 네모, 세모, 동그라미 모양으로 배치한걸 볼 수 있습니다. 텍스트를 이렇게 배치할 수 있게 해주는 속성이 shape-outside예요.


속성에 대한 설명은 모질라 재단 홈페이지에 나와있는걸 그대로 보여드릴게요. 속성에 대한 값이 너무 많아 다시 설명드리는건 낭비입니다!라는 핑계를 대며... ^^;;


/* Keyword values */
shape-outside: none;
shape-outside: margin-box;
shape-outside: content-box;
shape-outside: border-box;
shape-outside: padding-box;

/* Function values */
shape-outside: circle();
shape-outside: ellipse();
shape-outside: inset(10px 10px 10px 10px);
shape-outside: polygon(10px 10px, 20px 20px, 30px 30px);

/* <url> value */
shape-outside: url(image.png);

/* Gradient value */
shape-outside: linear-gradient(45deg, rgba(255, 255, 255, 0) 150px, red 150px);

/* Global values */
shape-outside: initial;
shape-outside: inherit;
shape-outside: unset;

여러가지 속성이 있는데 오늘 설명드릴건 polygon이라는 값이에요.

이 값을 잘 활용하면 전자책 편집하다 난감했던 문제들을 풀 수 있습니다.


오늘 예제는 '이상한 나라의 앨리스'예요. 

아래 이미지를 보세요.


이 이미지가 있는 부분을 제대로 편집한 전자책은 보기 힘들어요. 저도 예전에 한참을 고민하다가 앨리스와 체셔고양이 부분을 나눠서 편집한 적이 있습니다. 독자들은 별로 신경쓰지 않겠지만(ㅡ.ㅡ;) 그래도 전자책 제작 전문가라는 자부심이 있는데 이것 하나 해결 못하나 하는 자괴감이 들기도 하고...


왜 예전에는 shape-outside를 안썼냐고 하시면, 변명으로 들리시겠지만(^^;;) 안드로이드 구형 버전에서는 이 속성이 제대로 구현하지 못했어요. 안드로이드 4.4 이후 버전부터 구현이 되다가 5.0 버전 이후부터는 아무 문제 없이 적용이 됩니다. 그러다 보니 몇년 전에는 이 속성을 편집에서 쓸 생각조차 하지 않았습니다.


잡담은 그만 하고, 이제 본론으로 들어가서...


앞에서도 말했지만 오늘 소개할 속성은 이거예요.


shape-outside: polygon(10px 10px, 20px 20px, 30px 30px);


polygon 속성을 사용하면 다각형을 그릴 수 있습니다. 3각, 4각, 5각, 6각형 등을 표현할 수 있고, 별처럼 복잡한 도형도 그릴 수 있어요.


shape-outside : polygon(X좌표 X좌표 Y좌표, X좌표 Y좌표, X좌표 Y좌표);


이 스타일을 보면 좌표값이 3개 있습니다. polygon은 최소 3개의 좌표가 필요해요. 도형은 최소한 3개의 좌표를 필요로 하기 때문에 그래요. 사각형이라면 4개, 5각형이라면 5개의 좌표를 추가해 주면 됩니다. 좌표는 X축과 Y축이 한 쌍이에요. 그래서 2개가 한 쌍으로 콤마로 구분을 합니다. 화면 크기에 따라 변경되게 하고 싶다면 %단위를 쓸 수 있어요.


설명은 아무리 들어도 어렵지요^^?

이 속성은 직접 사용해 보기 전까지는 이해하기 어려워요. 저도 아직 X좌표가 가로축인지 세로축인지 자주 헛갈려요.


그럼 좀 더 이해하기 쉽게 예제로 설명을 드릴게요. 조금 많이 복잡하니 잘 따라오세요.



체셔고양이가 나오는 이미지는 오른쪽 중간부터 텍스트가 나옵니다. 이미지는 사각형이기 때문에 이미지를 넣고 float을 쓰면 오른쪽 중간 부분은 흰색으로 나와요. 이 부분을 채우려면 어떻게 해야 할까요? 컴퓨터가 이미지를 텍스트가 들어간 부분이 비어있는 다각형이라고 생각하도록 만들면 됩니다.



컴퓨터가 이미지를 이런 다각형이라고 생각하면 이미지가 들어간 영역을 제외한 나머지 부분에 텍스트를 채울거예요. 텍스트 크기가 변경되도 상관 없어요. 이미지 모양에 맞춰 텍스트가 알아서 채워지거든요.


이 이미지는 6각형이에요. 그러니 좌표가 6개여야 합니다. 좌표값은 이미지에 표시해 뒀으니 참고하세요.


이미지를 저렇게 만들기 위해 shape-outside 속성과 polygon 값을 아래같이 설정했어요.

.img_polygon_b_r {

width : 100%;

margin : 0;

padding : 0;

float : left;

shape-outside : polygon(0 0, 100% 0, 100% 45%, 45% 45%, 45% 100%, 0 100%);

-webkit-shape-outside : polygon(0 0, 100% 0, 100% 45%, 45% 45%, 45% 100%, 0 100%);

}

<p class="img_polygon_b_r"><img style="width :100%;" alt="img023" src="../Images/img023.png"/></p>

<p>“그건 네가 어디로 가고 싶은가에 달렸지.”</p>

<p>앨리스가 말했다.</p>

<p>“난 어디건 별로 상관없는데.”</p>

....


좌표를 찾는게 어려워요. 한번에 찾을 수는 없고 눈대중으로 이쯤 되겠다 싶은 좌표를 찍은 다음 조정을 해줘야 되요. 정확한 이미지의 가로/세로 길이를 알면 계산을 해서 값을 잡아도 되지만, 그렇게 하는게 시간이 더 걸리더라고요.


참고로, Sigil에서는 shape-outside 속성이 표현되지 않습니다. Sigil에서 작업하기는 어렵습니다. 저는 텍스트 편집기와 브라우저를 열어놓고 작업했어요.


제가 설명을 건더뛰며 했기 때문에 설명만으로는 이해하기 어려울거예요. 모질라 사이트에 나와있는 예제와 이상한 나라의 앨리스 샘플을 직접 적용해 보면서 좌표가 바뀌면 도형이 어떻게 변하는지 확인해 보세요.


이 속성을 잘 활용하면 이미지와 텍스트가 복잡하게 얽힌 책도 편집을 할 수 있습니다. 시간이 많이 걸리긴 하겠지만요 ^^;







설정

트랙백

댓글


티스토리 툴바