Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Page2018 Adobeクリエイティブゾーンセミナーd8-2スライド
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
JunTajima
February 06, 2018
Technology
800
0
Share
Page2018 Adobeクリエイティブゾーンセミナーd8-2スライド
Page2018 Adobeクリエイティブゾーンセミナーd8-2スライド
JunTajima
February 06, 2018
More Decks by JunTajima
See All by JunTajima
日本語組版に関連するCSS規格の策定状況について
juntajima
0
600
EPUBファイルからVivliostyleでPDFを作る
juntajima
0
930
XMLパブリッシング交流会2019パネルディスカッション資料
juntajima
0
740
Page2019 Adobeクリエイティブゾーンセミナー用資料
juntajima
0
870
Page2018 XMLパブリッシング交流会プレゼン資料(田嶋分)
juntajima
0
820
Other Decks in Technology
See All in Technology
個人AIからチームAIへ:開発における品質と生産性の再設計
moongift
PRO
0
220
イベントストーミングとKiroの仕様駆動開発で実現する要件の認識合わせプロセス
syobochim
7
750
TypeScriptとAngular Signal で実現する保守性の高いアプリケーション設計 - 3層アーキテクチャによる責務分離の実践(たつかわ) https://2026.tskaigi.org/talks/10
nealle
1
370
A Harness for Behaviour: how to get AI to generate code that does what we intend, or "TDD in the age of AI"
xpmatteo
0
470
権限管理設計を完全に理解した
rsugi
2
220
自作エディターをOSSにして分かった、一人に刺さる開発が世界を動かす理由
shinyasaita
1
440
Harnessing the Power of Mocks and Stubs in PHPUnit / #laravellivejp
asumikam
0
700
Spring AI × MCP 入門〜AIエージェントへのツール公開、境界設計から始める最小構成 〜
yuyamiyamoto
0
120
責任あるソフトウェアエンジニアリングの紹介4章・5章 / RSE_Ch4-5
ido_kara_deru
0
350
インフラが苦手でも大丈夫! 紙芝居 Kubernetes -WWGT 10周年編-
aoi1
1
260
データ基盤構築・運用の現場から 〜 Snowflake Intelligence 導入で変わった、データ活用の未来 〜
wonohe
0
200
RubyでRuby拡張を書いたらRubyより35倍速になったってどういうこと??
kazuho
3
650
Featured
See All Featured
We Analyzed 250 Million AI Search Results: Here's What I Found
joshbly
1
1.3k
Designing Experiences People Love
moore
143
24k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.5k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
180
For a Future-Friendly Web
brad_frost
183
10k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
380
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
GitHub's CSS Performance
jonrohan
1033
470k
Automating Front-end Workflow
addyosmani
1370
210k
Fashionably flexible responsive web design (full day workshop)
malarkey
408
66k
Transcript
DTP データからの電子書籍データ作成の今とこれから (株)三陽社 メディア開発室 テクニカルエキスパート 田嶋 淳
ブログ「電書魂」運営中 http://densyodamasii.com/
None
None
大きく変わりつつある出版の世界
• 2015 年 6 月 栗田出版販売経営破綻 • 2016 年 6 月 トーハンが八重洲ブックセンターを傘下に
• 2016 年 9 月 日販が文教堂の筆頭株主に • 2016 年 2 月 メディアドゥが出版デジタル機構を買収 • 2016 年 2 月 芳林堂書店倒産 • 2016 年 3 月 大洋社倒産 • 2017 年 3 月 CCC が徳間書店を子会社化 • 2017 年 4 月 日販とトーハン、書籍/雑誌の共同配送開始 • 2017 年 8 月 小学館と DeNA がデジタルメディ ア事業共同出資会社を設立 • 2017 年 12 月 CCC が主婦の友社を子会社化 急速に進む出版業界の再構築
ԯԁ ిࢠग़൛ ࢴͷࢢ ग़൛Պֶݚڀॴɺ ݄ ൃදͷ౷ܭΑΓ 出版市場の段階的縮小
ԯԁ
☟☠☤☡☦☮☟ ☟☡☡☢☞☮☦ ☟☡☧☠☡☮☞ ☟☢☦☤☣☮☥ ☟☣☞☣☞☮☡ ☟☣☢☠☤☮☥ ☟☣☤☡☠☮☥ ☟☣☤☢☢☮☟☟☣☡☟☢☮☥ ☟☢☤☥☟☮☤ ☟☢☠☤☞☮☣ ☟☡☥☧☡☮☦ ☟☡☤☟☣☮☣ ☟☡☠☠☠☮☡ ☟☠☧☧☦☮☡ ☟☠☥☤☥☮☟ ☟☠☟☧☧☮☤ ☟☟☦☠☥☮☡ ☟☟☠☧☧☮☡ ☟☞☦☤☡☮☧ ☟☞☣☠☣☮☣ ☧☦☢☡☮☥ ☧☡☦☣☮☢ ☦☧☥☧☮☟ ☦☣☠☞☮☞ ☥☦☞☟☮☞ $/&5+BQBOྛஐࢯʮిࢠॻ੶Ϗδωεͷਅ૬ʯ ܝࡌهࣄ ʢIUUQTKBQBODOFUDPNBSUJDMFʣΑΓ ࡶࢽࢢͷࣈͷΈΛநग़ͯ͠࡞ɻݩσʔλग़൛ग़൛Պֶݚڀॴͷ౷ܭɻ 雑誌市場の衰退(雑誌扱いコミックを含む)
ԯԁ ిࢠࡶࢽ ిࢠॻ੶ ༧ଌ ༧ଌ ༧ଌ ༧ଌ ༧ଌ ΠϯϓϨε૯߹ݚڀॴʮిࢠॻ੶Ϗδωεௐࠪใࠂॻ ʯΑΓ 電子出版市場の伸張
ഔମผࠂඅͱ໊ (%1 ͷҠΓมΘΓʢʙ ʣ ʢ୯Ґɿԯԁʣ ʢӈ࣠ɿ໊ (%1ʣ ʢి௨ਪఆʣ Ψϕʔδχϡʔεɹ ܝࡌهࣄʢIUUQXXXHBSCBHFOFXTOFUBSDIJWFTIUNMʣΑΓ ৽ฉ ϥδΦ (%1 Πϯλʔωοτࠂ ࡶࢽ ςϨϏϝσΟΞ 41 ࠂɾϓϩϞʔγϣϯϝσΟΞ 媒体別広告費の推移 2004 年 8 月 Google 株式公開 2005 年 9 月 ティム・オライリー 「Web2.0 とは何か」 2008 年 7 月 iPhone3 日本発売開始 2010 年 5 月 iPad 販売開始 2012 年 9 月 FaceBook のアク ティブユーザー数 が 10 億人に到達 2012 年 10 月 Kindle ストア 日本展開開始 1995 年 11 月 Windows95 日本語版発売
૯ചΓ໘ੵʢສฏํϝʔτϧʣ ૯ళฮ ૯ॻళɾ૯ചΓ໘ੵਪҠʢܦ࢈লɾۀ౷ܭௐࠪΑΓʣ Ψϕʔδχϡʔεɹ ܝࡌهࣄʢIUUQXXXHBSCBHFOFXTOFUBSDIJWFTIUNMʣΑΓ 総書店数・総売り場面積推移(経産省・商業統計調査より) 総書店数は 1990 年代 から減り続けている ↓ 大規模チェーン型書店 の進出、後継者不足な どによる「街の本屋」 の減少が原因か 2009 年あたりを境に 総売り場面積も減少に 転じている ↓ 雑誌不況の影響か
• 雑誌が売れなくなったことで取次・書店の売り上げが減少、書籍にも影響が 及んでいる • 書店の数/総売り場面積の減少に伴い「本との出会いの場」が消滅 • 全国で書店を持たない自治体「2 割」 • 書店が身近になくなったことで、必然的に日常的に書店に行く生活習慣を持
たない層が増加 • 情報の入り口がスマホ、 タブレットだけの層に本を売るには、 スマホに「本」 を入れていかないと勝負にならない(ライバルは SNS やゲーム) • 紙で買うのか電子で買うのか、読者に複数の選択肢を与えたい • 紙の売り上げが落ちる中、唯一伸びているのが電子書籍 なぜ電子書籍を作る必要があるのか(エンタメなど)
• 「アクセシビリティ対応」の考え方が必須に • 読み物の主要読者層の高年齢化に伴う文字拡大の需要 • 障害者差別解消法の施行、マラケシュ条約批准に伴う「合理的配慮」の要望 • 公的機関は合理的配慮が「義務」になる→公立図書館は公的機関に含まれる • 米国では大学などに対してアクセシビリティの不備を理由とした訴訟が多数
起きている(=教育市場では配慮が必須になっている) なぜ電子書籍を作る必要があるのか(専門書など)
さまざまな「電子書籍」
Web を核として相関関係にある各種の「電子書籍」 小説投稿サイ ト カクヨム 小説家になろう etc� アプリ型電書 comico ジャンププラス
etc� 写真共有サービス Flickr Googleフォ ト etc� PDF メールマガジン 会員向け 情報提供サービス EPUB 電子辞書 Web
電子書店で販売されている現在主流の形式「EPUB3」 Ϧϑϩʔܕ ϑΟ οΫεܕ ߏԽςΩε τΛύοέʔδԽͨ͠ͷ ˓จࣈͷ֦େॖখ͕ࣗ༝ʹͰ͖Δ ɹ ʢখ͞ͳը໘ͰಡΈ͍͢ʣ ʷݫີͳ൛ͷҡ͍࣋͠
ʷ੍࡞ʹख͕͔͔ؒΔ ˓ ʢը૾σʔλͷΈͷͷʣ ɹ&16# ࣗମͷ੍࡞؆୯ খઆͳͲͷಡΈͰ༻͍ΒΕ͍ͯΔ ൛໘Λͦͷ··ύοέʔδԽͨ͠ͷ ʢը૾Խ͍ͯ͠Δྫ͕΄ͱΜͲʣ ʷʢը૾σʔλͷΈͷͷʣ ɹݕࡧɺಡΈ্͛Ͱ͖ͳ͍ ʷจࣈͷ֦େॖখͰ͖ͳ͍ ओʹίϛοΫͰΘΕ͍ͯΔ ϨΠΞ τ͕ॏཁͳҙຯΛ࣋ͭຊͳͲͰ ϑΟ οΫεܕͰిࢠԽͨ͠ྫ͋Δ ʢFYߨஊࣾϒϧʔόοΫεʣ ˓ݕࡧɺಡΈ্͕͛Մೳ ˓࠶ར༻ੑʹ༏ΕΔ
リフロー型 版面は特定の画面サイズ、 文字サイズに応じてその場で 「生成」 される。 特定の版面を作り込むという考え方は意味をなさない。
フィックス型 ページをまるごと画像化してパッケージ化しただけなので、 版面の情報はそのまま引き継がれる。
DTP データから リフロー型電子書籍を作成するにあたっての注意点
• 元データが(多くの場合)InDesign 等の DTP 組版アプリのデータ • EPUB3 の場合、 「電書協ガイド準拠」であることを求められることが多い •
制作データを Web にアップロードすること自体が禁止されているケースも • 以上の条件により、でんでんコンバーター、Romancer、一太郎等、数多く 出ている EPUB 制作ソリューションが使えない • 現状プロ向けの定番 EPUB 制作アプリと言えるものはなく、自社でシステ ム開発する、既存の Web 用アプリをうまく組み合わせて使う等の選択肢し かない 出版向けの EPUB 作成の特殊性
• (X)HTML5 の知識 • CSS の知識 • XML(OPF)の知識 • (X)HTML5
の効率的な整形のための技術(正規表現、Perl、Ruby など) • InDesign など組版ソフトの知識(元データは InDesign) • Photoshop、Illustrator などの知識 出版系の EPUB 作成に必要な要素技術
InDesign から EPUB を作るための様々な方法 InDesign データ EPUB 書き出し XML 書き出し
HTML 書き出し テキスト コピー&ペースト EPUB データ IDML/ICML 解析 変換 タグ調整、 画像差し替え etc タグ調整、画像差し 替え、オーサリング XML → XHTML 変換、 オーサリング XML → XHTML 変換、 オーサリング 手動タグ付与、 オーサリング
InDesign から EPUB を作るための様々な方法 InDesign データ EPUB 書き出し XML 書き出し
HTML 書き出し テキスト コピー&ペースト EPUB データ IDML/ICML 解析 変換 タグ調整、 画像差し替え etc タグ調整、画像差し 替え、オーサリング XML → XHTML 変換、 オーサリング XML → XHTML 変換、 オーサリング 手動タグ付与、 オーサリング ※ WYSIWYG アプリから 書き出した構造化テキス トの整備はとても大変
• InDesign が上流データである限り、表現に相当な制約を設けない限り完全 な自動変換は無理 • InDesign などのアプリ内で扱える文字(字形)の数の方が EPUB 等の中で 扱える文字の数よりも多い
• DTP データの制作段階で構造化を考えて作られていないようなデータに自 動的に構造を付与するのはほとんど無理 • InDesign のような WYSIWYG のアプリは「経験の浅いオペレータでもそれ なりに作れる」のが売りなので、構造化などは後回しになりがち • InDesign には div タグのような複数行の範囲指定の仕組みがない、タグの 入れ子に相当する仕組みがないなど、XML 系構造化文書との根本的な非互 換性も多い どんなデータでも変換できる「魔法の杖」はない
とはいえ、手間を減らすためにできることはある • Unicode にある文字はそのまま使い、外字の使用は可能な限り減らす • できる限りひとつの章のテキストは同じストーリー内に収納する • 文字をアウトライン化するなどテキスト情報を消す行為は避ける • 段落スタイル、文字スタイルなどを適切に使い、構造的に正しいデータ作成
を心がける • その他本来その目的でない機能を使って目的を達成しようとしない(バッド ティップスを使わない)
× Unicode に紐付いていない字形を持つフォントの使用 コピー&ペーストすると意味が変わって しまう。事故のもとになる。
×ローマ数字をアルファベットの文字の組み合わせで表現する ローマ数字をアルファベットの文字 の組み合わせで表現 ローマ数字を本来の Unicode の文 字で表現 印刷では同じに見えても、電子化した際の「検索」や「読み上げ」で問題が出る
×見た目の版面を整えるだけのための改行やスペース ←ぶら下がりインデントを見た目だけ 再現するための改行&全角スペース。 電子化するとぐちゃぐちゃになる。 →ぶら下がりインデントは インデントの機能を正しく 使って設定する。
×文字色を「白」や「なし」にしてインデントを表現 印刷では消えて見えても、内部的には文字情報を持っているため テキストにすると文字が出てきてしまう
×見出しやルビを別オブジェクトで置いてある ←手作業で見出しの打ち直し、ルビの 付け直しなどの作業が発生してしまう → DTP アプリの機能を適切に使って 二次利用しやすいデータを作成する。
× PostScript Type1 フォントの使用 ↑リソースフォークにデータの主体を保存していた PostScript Type1 フォントを使っていたため、データ圧縮時などにデータ (リソースフォーク)が失われて使用不可能に。 もういいかげん
PS Type1 は使用禁止にして OpenType(.otf)や TrueType(.ttf)を使おう
×文字のアウトライン ←特定のフォントの字形を保つために 見出しなどの文字をアウトライン化し てしまうと、二次利用時には再入力の 必要が生じる。
今後期待したいこと
• プリントした版面だけでなく、データの作り方もある程度チェックするべき (制作アプリ・使用フォント制限、スタイルをちゃんとつけて作るなど) • データ管理は出版社自身がやる方向になるべき • 電子版だけに留まらず、紙の本まで含んだ Web プロモーションを真剣に考 えていくべき
• IT に強くなるべき 出版社に期待したいこと
• CSS 次世代拡張に伴う日本語表現の拡充 文字間のツメ、アケの適切な自動処理 自動縦中横 肩付きルビのサポート etc... • Web Publication
による EPUB に限らない Web の中での「パッケージされ たひとかたまりのコンテンツ」の流通の可能性 • VR/AR の普及でデバイスシフトが起きてスマホがリプレースされれば、一気 に大判の本などの電子化は進む可能性がある • 電子書籍などへのコンテンツ二次使用をスムーズに行うための次世代組版ソ フト、ワークフローの普及(InDesign のリプレース) 技術面で期待したいこと
ご静聴ありがとうございました