내맘대로의 EPUB 제작 가이드

전자책 관련해서 여러 사람들과 얘기하다 보면 '아직 이런 정보도 모르나' 싶은 것들이 있습니다.

토리움 https://thorium.edrlab.org/en/ 장애인접근성과 멀티미디어, 인터렉티브를 지원하는 뷰어입니다.

알라딘 전자책 뷰어에서 TTS가 sup, sub 태그를 읽지 않습니다.

알라딘 측에서는

(알라딘 뷰어의 TTS)가 10의 몇 승을 그냥 10으로 읽습니다.

라는 독자의 문의에 대해 출판사에

[일반적으로 sub, sup 태그는 주석 등 읽지 않아도 되는 텍스트에 사용되며, 저희 전자책 뷰어에서는 해당 태그를 TTS로 읽지 않도록 설정되어 있습니다.]

라고 하며 sup, sub 태그를 span 태그로 수정해 달라고 하는데, 알라딘 담당자가 HTML에 대한 기초도 없는 것 같습니다.

알라딘 뷰어가 정책상 첨자 태그를 TTS가 읽지 않도록 막은 것인데 EPUB에 첨자 태그를 쓴 것 자체가 문제라는 의미로 보일수도 있습니다. 

sup, sub 태그는 인쇄상의 이유로 아래 첨자로 표시되어야 하는 인라인 텍스트를 지정합니다.

일반적으로 수학 기호, 화학식, 주석 번호 처럼 본문 보다 작은 글씨로 본문 글씨의 위 또는 아래에 걸치는 형태의 편집,

10², H₂O

처럼 되어 있는 편집을 첨자라 하며, 첨자를 표현할 때 sup, sub 태그를 사용합니다. 

따라서 10²의 위첨자 2를 sup 태그를 이용해 편집하는 것은 전혀 문제가 되지 않습니다.

책을 편집할 때 본문 보다 작은 글씨로 주석을 달 때도 "첨자" 스타일을 사용합니다.

그러니 영문 병용 표기, 괄호 설명 등에 sup, sub 태그를 쓰는 것은 HTML 편집 상 문제가 되지 않습니다.

그리고 독자의 문의 사항이었던 10의 몇승을 TTS가 읽지 못한다는 문제는

span이냐, sup냐, sub냐와는 전혀 무관합니다.

sup, sub는 인쇄 모양만 관여를 할 뿐 10²를 10의 2제곱으로 읽는 것과는 전혀 상관이 없습니다.

sup, sub 태그를 span으로 수정한다 해도, TTS는 "십이"라고 읽게 됩니다.

독자가 원하는 십의 이제곱이라고 읽지 못하지요.

첨자를 써서 제곱을 표시한 것은 유통사 뷰어가 mathml을 제대로 처리하지 못하기 때문입니다.

유통사가 뷰어에 mathml을 적용하고, TTS가 mathml을 읽을 수 있도록 바꿔야 하는데(EPUB 기술 문서 권고사항)

이런 노력은 하지 않고 독자의 요구와 전혀 상관이 없는 sup/sub를 span으로 바꿔야 한다는, 동문서답식 답변을 한 것입니다.

mathml을 당장 처리하기 어렵다면 sup 대신 10²로 편집해 달라고 해야 옳습니다. 저렇게 하면 TTS는 "십 위첨자이"라고 읽을테니까요.

어째든,

오늘의 결론.

알라딘 뷰어는 sup, sub 태그를 TTS가 처리하지 못한다.

그러니 편집할 때 무시하거나, 주의하시라... 입니다.

알라딘 뷰어(PC)에서 차례가 표시되지 않는 이슈가 있습니다.

뷰어의 기능 제한이기 때문에 오류는 아닙니다. PC 뷰어만 확인을 했고, 모바일 뷰어는 확인하지 않았습니다.

하지만 차례가 보이지 않기 때문에 제작상의 문제로 생각할 수 있습니다.

알라딘 뷰어에서 차례가 표시되지 않는 것은 제작 문제가 아니라 뷰어에서 표시하지 않는 것이니 제작/검수 할 때 참고하시기 바랍니다.

전자책 편집시 생성한 차례는 아래와 같습니다.

총 4단계로 제목이 구분되어 있고, 각 단계 별로 상위 제목에 포함되어 있습니다.

알라딘 뷰어에서는 3단계 까지만 차례가 표시되고 4단계 이후는 나타나지 않습니다.

또한 2단계 까지만 들여쓰기로 단계를 구분하고 3단계는 2단계와 같은 선에 배치됩니다.

교보ebook은 제목을 모두 표시하지만 제목 단계 구분을 3단계 까지만 합니다.

4단계 부터는 3단계와 동일한 선에 표시합니다.

아마도 단계 구분을 위해 들여쓰기를 계속 하면 오른쪽 끝에서 제목이 잘리는 문제 때문에 이렇게 지정한 것 같네요. 

리디 뷰어는 4단계 까지 제목이 표시됩니다.

이 책이 4단계 까지만 있어 5단계 이후는 알 수 없습니다.

리디북스 뷰어는 margin을 무시합니다.

정확히는 margin-top, margin-bottom을 무시합니다.

'문제'가 아니라 '이슈'라고 적은 것은, 리디북스의 정책일 수 있기 때문입니다.

리디북스 제작가이드를 보면 이런 문구가 있는데, 

하단에 뷰어로 보면 스타일이 적용된다고 되어 있지만,

일부 스타일은 뷰어에서도 무시를 합니다.

리디 뷰어에서 이렇게 보이더라도,

스트레스 받지 말고 뷰어 특성이구나 생각하시면 됩니다.

왼쪽이 리디뷰어, 오른쪽은 Readium 뷰어입니다.

Readium 뿐 아니고 교보문고, 알라딘 예스24 모두 오른쪽처럼 

제목과 본문 사이 여백이 표시됩니다.

리디 뷰어에서만 margin을 무시하고 있습니다.

제작을 의뢰한 쪽에서 리디 뷰어로 검수를 하면 margin이 보이지 않으니 수정해 달라고 합니다.

EPUB 문제가 아니고 리디 뷰어의 정책으로 보이기 때문에 이건 수정을 할 수 없습니다.

제작을 잘못한 게 아니기 때문에 스트레스 받지 마시고,

리디 뷰어에서는 리디 정책으로 인해 margin이 적용되지 않는다고 하세요.

제목만 그런 것이 아닙니다.

margin-top, margin-bottom 두 속성은 모든 곳에서 무시를 합니다.

왼쪽이 리디 뷰어(PC) 오른쪽은 Readium을 포함한 교보, 예스, 알라딘 뷰어의  margin이에요.

이렇게 제목, 이미지 등 margin-top, margin-bottom을 어디에 적용하든 무시합니다.

물론 해결은 할 수 있습니다.

첫번째 이미지의 책에 margin이 적용되도록 했습니다. 

리디 뷰어에서도 margin을 적용할 수 있긴 합니다.

이미지도 margin이 적용되도록 수정을 했지요.

출판사에서 요구를 했기 때문에 이렇게 스타일을 잡았습니다.

하지만 유통사의 정책을 무시하고 이렇게 스타일이 적용되도록 하는 건 그리 좋은 방법이 아닙니다.

유통사도 스타일을 무시하는 이유가 있을거예요.

그러니 리디 뷰어에서 margin이 적용되지 않는다고 스트레스 받지 마시고

타 유통사 뷰어와 Readium, Calibre, iBooks 같은 뷰어에서 제대로 적용되면 

리디 뷰어 특성이구나 생각하고 넘어가세요.

정확히 언제부터인지는 모릅니다.

3~4개월쯤 전 업데이트일 수도 있고, 제가 파악한건 대략 2달 정도 됐습니다.

알라딘 PC 뷰어에서 페이지가 밀리는 현상이 있어요.

이 문제를 파악한건 좀 됐는데,

최근에 '알라딘 뷰어 오류' 키워드로 유입이 많이 늘어난 이유가 이 때문이 아닐까 싶어 공유합니다.

유통사 뷰어 문제를 공유하는 것은, 특정 유통사를 비난하기 위함이 아닙니다.

유통사에서 문제를 파악하고 해결해 줬으면 하는 바람과,

EPUB 편집자들이 뷰어 문제로 고생하지 않았으면 하기 때문이에요.

유통사 뷰어 문제는 대부분 유통사 담당자들이 현상을 확인하면 빠르게 해결합니다.

** 블로그의 특성상, 이후 내용까지 업데이트는 어렵습니다.

** 이 글이 있다고 뷰어 문제가 계속 남아있는 것은 아니에요.

** 이 글의 작성일을 보시고, 그 이후 업데이트가 있었다면 뷰어 문제는 해결되었을 수 있습니다.

아래 영상, 뷰어 하단의 페이지를 보세요.

페이지 넘김을 누르면 페이지는 변하는데 내용은 그대로 있습니다.

그대로 있는건 아니에요. 좌우로 1px 정도 살짝 밀리고, 페이지 번호가 바뀌지요.

이건 다른 책입니다.

영상 초반에 페이지 번호를 보세요.

70쪽에서 71쪽 넘기면 빈면이 나옵니다. 

이거 보면 EPUB 제작을 잘못한 것 같을거예요. 쓸데 없이 빈면을 넣었다고 오해받을 수 있습니다.

하지만 영상 중반 이후를 보세요. 뷰어 폭을 약간 조절하고 나면, 빈면이 사라집니다.

이 현상을 7월부터 확인했습니다.

아마도 6월~7월 사이 업데이트 하면서 생긴 문제 같습니다.

아주 오래 전에도 알라딘 뷰어에서 비슷한 문제가 있었어요. 

알라딘에서 이 문제를 해결했는데 다시 나타난 것 같습니다.

7월에는 테두리 선이 다음 페이지로 넘어가는 현상까지 있었어요.

그런데 최근 업데이트에서 이 문제는 해결이 된 것 같습니다.

아래 이미지 왼쪽을 보면 1~2px 정도 선이 있습니다.

이 선은 앞 페이지의 이미지나 테두리 선이 다음 페이지에 표시되는 현상이에요.

최근 업데이트 후 앞페이지의 이미지/테두리가 다음페이지에 보이는 문제는 해결되었는데,

페이지 밀리는 현상은 담당자가 파악하지 못한게 아닐까 싶습니다.