ちくちく日記

DTP系備忘録。真面目にやってます。

NAVERまとめにぱくられたらやるべき対処

その他

NAVERまとめで文章と画像をぱくられてましたよ…！


以前にかいた「もじもじカフェ　映画字幕師・佐藤英夫の仕事とデジタル化」のテキストと画像が、勝手にNAVERまとめに使われておりました。



▲リンクはると相手のアクセス数上がって業腹なのでスクリーンショットのみはります。

広いWEBの片隅で細々とマイナーなDTP情報を好き勝手書き散らしているだけのこんなブログで、まさかNAVERまとめにひっかかることがあるとは思わなかったよ…！

別に引用して紹介してあるだけなら腹は立たなかったのだけど、このまとめ「出典」とかかいてあるけど、該当のURLははっておらず、こちらのサイト名もかいてない。
画像も勝手につかってるし、私の趣旨とは違う使い方してある。
私はこのブログの画像はすべて「表示-非営利-改変禁止：原著作者の氏名を表示し、非営利で、改変をしない場合に限り、誰でも自由に使用できます。頒布することもできます。」という設定にしてある。なので「原著作者の氏名を表示」していないこのまとめはライセンス違反。


ということで、とれる限りの対処法をとってみました！
同じようにNAVERまとめにパクられてしまった人の参考に手順をまとめておきます

NAVERまとめに権利侵害申告をする

まずは該当サービスであるNAVERまとめに「私の著作権が侵害されてます！」と申告しましょう。
権利侵害申告はNAVERの「お問い合わせ窓口」から行います


NAVER　お問い合わせ窓口　

申告手順

  • 「お問い合わせ：対象サービス」から「まとめ」を選ぶ
  • 「お問い合わせの種類：種類」で「権利侵害申告」を選ぶ

名前、メールアドレスなどこちらの情報を記入（名前はアカウント名などでも良いようです）

  • 「権利侵害の内容：権利者確認 ：権利者本人（権利侵害被害の当人）」
  • 「権利侵害の内容：権利侵害の種類：著作権 」
  • 「権利侵害が行われている弊社サービスURL：（該当のまとめURLを記入）」
  • 「権利侵害の内容を確認できるお客さまのサイトURL：（ぱくられた記事のURLを記入）」
  • 「お問い合わせの内容：内容」権利侵害の内容を書く。とりあえず、私はこんな感じに書きました

まとめ内で、私のブログの記事と画像が勝手に使われています。
出典とかいてありますが、引用先のURLはなく、引用先名も正確なものではありません。
私の記事の趣旨と違う形で画像やテキストをつかわれており、私の著作権を侵害しています。
勝手に利用された画像
＜勝手に利用された画像のURL＞
勝手に利用されたテキスト
＜勝手に利用されたテキスト＞

該当まとめ記事を即刻削除いただくようお願い致します。

これで送信。

NAVERからの返信はすぐに来ました
以下返信メールから抜粋。

NAVERをご利用いただき、誠にありがとうございます。
NAVERヘルプセンターです。

お問い合わせくださいました件について、ご案内させていただきます。

このたびは、弊社ユーザーがご迷惑をお掛けすることとなり、
申し訳ございません。

大変恐縮ではございますが、お客さまがブログ権利者様であることの
確認をいたしたく、下記内容についてご対応、
ご連絡いただけますようお願い申し上げます。

1．対象まとめ内の画像が掲載されているお客さまブログ記事内
　http://d.hatena.ne.jp/akane_neko/20130828/1377642076
　こちらにNAVERまとめへの転載を禁止する以下の文面の
　記載を追加お願いいたします。

　　「このページ内の画像をNAVERまとめに転載することを禁止します。」

ブログの権利者である事を確認するために、ブログの方に「NAVERまとめに転載するなよ」と追記してねということみたい。
すぐに対応し、返信したところ

ご連絡いただいた内容につきまして調査させていただき
該当の投稿に対し、公開制限措置を行いましたので、
お手数ではございますがご確認いただけますよう、お願い申し上げます。


おお、対応早いぞNAVER！

さっそく確認してみると…あれ？NAVERまとめ自体は削除されてない…

どうやら、まとめのなかで私が権利侵害を申請した部分のみ削除されたようです。

▲申請した画像とテキストのみ削除されてる

仕方ないんだろうけど、全削除してほしかった私としてはちょっとくやしい…。


Googleに著作権侵害による削除を申し立てる

そもそも私がこのまとめに気がついたのは、あるキーワードでGoogle検索したときに、私のページが表示されたすぐ下にこのまとめサイトがきていたから。
まだかろうじて私の方が検索上位にいるが、こんなのに並ばれるのは腹が立つ。
ということで、Googleさんにも「検索結果からこのまとめを取り除いて頂戴」と削除申し立てをしました。


Google 著作権侵害による削除　

申し立て手順

  • 「Google 著作権侵害による削除　」にアクセスする
  • Googleアカウントでログイン
  • 「新しい通知を作成する」で申し込みフォームを表示
  • 「氏名：（氏名を入力）」
  • 「自分が代理を務める著作権所有者: 本人」
  • 「メールアドレス：（メールアドレスを入力）」
  • 「国/地域:日本」
  • 「著作権対象物：著作権対象物を特定する情報とその著作物の説明」

著作権を侵害しているコンテンツについての説明を書く。今回の場合該当NAVERまとめのなかの画像とテキストの説明

  • 「著作権対象物：当該著作物が許可を受けて掲載されている場所」

著作権侵害されたコンテンツがのっているURLを書く。今回の場合は私のブログの該当ページのURL

  • 「著作権対象物：権利を侵害している著作物の場所」

削除してほしいURLを書く。今回の場合はNAVERまとめの該当URL

  • 「宣誓供述書」にチェック
  • 「署名」の「署名日」と「署名」に入力
  • 「私はロボットではありません」にチェック

これで送信！
（Googleさんに削除されるまえにNAVERのコンテンツが削除されたので、この申請は通るかどうか微妙なんだけど…）

相手を呪う

こういう風に自分の書いたものがぱくられたのを見つけてしまったのは初めてだけど、実に嫌なものですね。
特に腹が立ったのは、引用先のURLもなく、サイト名もまともに表示してないかった事。あれがちゃんと引用先としてこちらのURLが記載されているものだったら、むしろ紹介してくれたことをうれしく感じたかもしれません。

NAVERやGoogleに削除申請はしましたが、NAVERでは自分のコンテンツ部分のみの削除で該当まとめ自体は削除されませんし、Googleもいつ削除されるかわかりません。
勝手にコンテンツを使われた自分としてはどうにも腹の虫が治まらないものがあります。

なので、そのやりどころのない怒りを向かわせるべく、私のサイトをぱくった相手に全身全霊でもって呪いをかけてやることにします。




う　ん　こ　も　れ　ろ！！！！！




皆さんも、もし自分のコンテンツがぱくられてしまったら参考にしてください。以上。

LETS FontACE3.2.0がコレジャナイ

Font その他

「LETS POWER UP TOOL KIT　2015→2016」が届きましたよ！
今年のPUTKではフォント管理ツール「LETS FontACE」がv3.2.0にバージョンアップって情報を聞いていたので楽しみにしてたのだ。
とくに楽しみにしてたのはここ。


▲任意の場所に保存しているフォントの管理機能

v3.2.0では「任意の場所に保存しているフォントの管理機能」が！（1バイトフォントに関しては以前もできていたけど、今回日本語フォントに対応！）
さらに。


▲フォルダごとドラッグ＆ドロップで登録可能


おおーーーーー！これこれ！欲しかった機能だよーーー！
これ、Linotype FontExplorerとかだと当然のようにできるんだよねー。
外部フォルダでフォント管理してると、フォルダ分けしたフォントをいちいち選択して登録するなんてめんどくさいから、一括登録できるのはすごくありがたい。


外部フォント管理機能を試す

そして届いたLETS POWER UP TOOL KIT。さっそく試させていただきましょう！

LETS FontACE3.2.0を起動。フォルダ分けしたフォントをドロップ！


▲フォントワークスのフォントが入ったフォルダをドロップ！


…あれっ…？


確かに、ドロップしたフォルダの中のフォントが登録されてる…けど…


▲ドロップしたフォントワークスのフォントが登録されてる


もう一回、今度は違うフォルダをドロップしてみよう！


▲モリサワのフォントが入ったフォルダをドロップ！


…えっ…？






うん、確かに。確かに、ドロップしたフォルダの中のフォントが「ユーザー管理：外部」のフォントとして登録されてる。

でもさ、でもさ！どうして別々のフォルダをドロップしたのに一緒くたにまとめて「ユーザー管理：外部」に入れちゃうの！！！！
これだと、せっかくフォルダ分けしてたのがごちゃ混ぜじゃんか！

コレジャナイ！コレジャナイんだよーーーーーー！！！！！！！


どうしてあと一歩！あと一歩進んで「ドロップされたフォルダ内のフォントを「ユーザー管理：外部」に登録すると同時にフォルダ名のフォントグループを作成し、そのグループに登録する」ってとこまでやってくれないのだ！もしくは「任意のフォントグループにドロップしたらフォントの登録と同時にそのフォントグループに入れる」でもいい！


考えてみてくれ！わざわざフォントをシステムフォルダに突っ込まず外部フォルダに入れているような人間が、全部のフォントを一緒くたに入れている訳ないだろう！

今の仕様じゃ、わざわざフォルダ分けしたフォントをドロップして、そのあと全部一緒に突っ込まれてしまったフォントをもう一度フォントグループで分類する、ってことになるんだよ！
前にFontACEについて書いたときにも言ったけど（LETS FontACE　その2）、登録されたフォントから一個一個選んでフォントグループを作るの、すごくめんどくさいんだよ！そんなめんどくさいことやってられっか！！！！！

それと、小さいことだけど、LETSでインストールされたフォント「フォントサーバ：インストール」が「インストール済み」ってなるんだけど、これ、システムフォントフォルダに入ってるフォントだけが対象で外部フォルダで管理していても「未インストール」になっちゃう。外部フォルダまでちゃんと見て欲しい。

▲外部フォルダにインストールしてあっても「未インストール」

3.2.0の他の機能

望んでいた機能がきたーーー！とおもったら「コレジャナイ」でしょんぼりしてしまいましたが、せっかくテストするんだから他のとこもチェックしておきましょう。

3.2.0では外部フォント管理以外に、重複フォントの検知ができるようになってます。
以前のバージョンでは同名フォントがあってもなんの警告もなかったのですが、今回のバージョンでは「重複」という項目にチェックが。

▲重複したフォントにチェックが

でも、でもさぁ。

これ「重複」にチェックが入るだけで、どちらもオンにできちゃうんですよ…。

▲小塚のバージョン違いをオンにしてみた


いや、オンにできてもいいんだけど、これだとどれがイキになってんだかわからないよね…。

重複されたフォントがオンになるときは、FontExplorerみたいに警告出して、どちらかをオフにするのが正解だと思うんだけど。

▲FontExplorerは「どっちをオンにするのか選べ！」って聞いてくる

あと、ドロップされたフォントに重複がある場合、有無を言わさず新しく登録される方をオンにして従来のフォントをオフにするのも、これもどちらにするか聞くべきじゃないだろうか。

▲どっちをイキにするか聞いて欲しい…
そもそも登録したら同時にオンにするのも余計なお世話な気がする…。



もうすこしがんばりましょう

久しぶりにLETS FontACEを使ってみた。外部フォルダのフォントを管理できるようになったり、ドラッグ＆ドロップで登録できたり、いい方向に進化はしてるんだけど、使い勝手を考えるとあと一歩足りない！
結局今の機能じゃ、おまけツールという位置付けから抜け出せず、ガチでフォント管理したい人には向いてない。

とりあえず感想は

って感じかな。

がんばれFontACE！

JEPAセミナー「デジタル教科書の世界標準EDUPUB」

セミナー 電子書籍

JEPAセミナー「デジタル教科書の世界標準EDUPUB」に行ってきました。
備忘録代わりにレポート。
長々とよむのがめんどくさい方は途中途中に【感想】ってまとめ挟んでますので、それだけどうぞ。

注意：レポートはセミナー中に私がメモしたものを書き起こしてまとめなおしたものです。間違っている部分があるかもしれませんし、書きもらしもあります。
当日の資料と公演映像はhttp://www.jepa.or.jp/sem/20150728/から入手できるので、気になる方はそちらをごらんください。
レポート内四角で囲まれた部分は当日のスライド資料などからの引用です。

EPUB 3.1の制定と国際規格化（EPUB JWG北京会議報告、EPUB3.1、W3C動向(DPUB、Open Annotationなど)

スピーカー:村田 真（ISO SC34、JEPA CTO）


最初のスピーカーは村田 真氏。北京で行われたEPUB JWG北京会議報告を元に、EPUBの次期バージョンv3.1についての説明

まず、EPUBとは何かの説明から。（会場からは「ここでその説明はいらないんじゃないの」といった笑いがもれる。）

EPUBとはすなわち、Web技術と出版の一体化である。
本がWeb技術を用いて作られるようになっている。

EPUBの注目度合いをGoogleTrendで見てみると、注目度は一時期のピークほどではない。しかし、これはEPUBが今は成熟期に入っているため。一時のように「EPUBで作りました」ぐらいで注目されたりしない。EPUBが当たり前のものになってきているということ。

EPUBの歴史
•EPUB2 (2007年)
•2009年末に北米での普及が本格化
•EPUB 3(2011年)
•国際化、日本での普及
•EPUB 3.0.1(2014年)
•EPUBモジュール 制定中
•EPUB 3.1 これから制定開始

EPUBの現在の最新バージョンは3.0.1、v3との違いは固定レイアウトなどマイナーな変更のみ。
機能拡張モジュールは現在提案中である。

EPUB 3.1の性格付け
•EPUB3以来の大幅な拡張
•紙の模倣よりデジタルならではの機能
•利用経験からのフィードバックにもとづく拡張

EPUB3.1の性格付け。EPUB3.1は伝統的組版のための拡張ではなく、デジタルならではの機能追加であるということ。
また3.0.1で追加された機能を実際に使って作ってみた人からの、ここがおかしいこうして欲しいといったフィードバックへの対応もはいっている。

EPUB 3.1の主な追加項目
•スクリプトを安定して動作させること
•Webとの整合をさらに進めること
•アクセシビリティについての機能を追加すること
•拡張モジュールを組み込むこと

EPUB3.1で主な追加項目はjavascriptへの対応。javascript対応はv2では使えなかったし、v3では一応対応しているが使い物にならなかった。
javascriptを使っての対話的項目が3.1で安定動作するようになる。
Webとの整合はHTML5、CSS3などとの整合をさらにすすめていく。
辞書、索引、プレビューといった拡張も盛り込まれる

EPUB 3.1への制約
•既存EPUB 3実装でまったく扱えない機能はできるだけ導入しない。
•EPUB 3.1の実装を難しくしすぎないようによる。
•とても重要な理由があり、重要な利害関係者が必要としている機能を導入する。
•W3Cとの不整合を避ける

3.1の前提条件として、既存のEPUB3の実装で全く使えないような機能はできるだけつけない。とはいいつつ、Scriptは現在まったく動いていないのを入れるのだから矛盾はしているが。
せめて「scriptが動きません」というフォールバックは出せるようにする
EPUB3.1の実装は難しくならないように。難しいと世の中がついてこられない。欧米ではEPUB2.0で用が足りるので、EPUB3.0はほとんど普及していない。W3Cとの不整合はさける。IDPFがW3Cを無視して勝手に機能を拡張しても結局その機能は使われない。W3Cに合わせて機能を拡張する。

制定スケジュール
•2015年後半から2016年前半に開発
•完成後にISO/IECで国際規格へ

2016年前半に開発とアナウンスされてはいるが、経験上おそらく2016年いっぱいはかかるだろう。
完成後にISO/IEC登録するのはは確定したことではないが流れとしてそうなる。
今のEPUBは承認されていはいるがテクニカル的に問題を残しているとされていた。それは（内部で利用されている）HTML5がその時点でまだ承認されたものではなかったから。今度は問題がないので、国際規格を目指していくことになる。

制定中の拡張モジュール
•複数レンディション
•プレビュー
•領域ベースのナビゲーション
•注釈
•スクリプト付き部品
•スクリプト付き部品のパッケージ化と統合

ここまでは組み込み予定

•辞書と索引
•EDUPUBプロファイル
•EDUPUB構造意味
•頒布可能オブジェクト

これらは組み込み予定なし

スクリプト付き部品(widget)
•対話的なEPUB : スクリプト付き部品　=　電気回路 : 電子ブロック
•対話的な電子出版物(有料販売)
•問題集

必要性
•文芸書の電子化だけ、マンガの電子化だけなら要らない
•EPUB3では、Javascriptの使用を推奨はしていなかった。ただし、環境によっては使えた。
•対話的な教育用コンテンツでは、スクリプトが必要。
•部品によって、EPUB出版物としての作りやすさを

EPUB3.0は書籍と漫画などの電子化が対象だった。これだけならスクリプトは必要ない。
3.0.1のスペックでもjsは使えるが、閲覧環境によって動作しない、組むのが難しいなどの問題があった。
今後のEPUBの教育用コンテンツでの利用を考えるとスクリプトによる対話など、スクリプトでないと実現できないような機能が必要になる。
教育関係を考えるとできるだけ簡単に作れるようにしたい。部品をくみ上げるだけで作れるように。

仕様書および検討中の案
•EPUB Scriptable Components 1.0
http://www.idpf.org/epub/sc/api/
•EPUB Scriptable Components Packaging and Integration 1.0
http://www.idpf.org/epub/sc/pkg/
•サンプル
https://github.com/IDPF/scriptable-components
https://docs.google.com/document/d/1jffqS4xyvLhrfH_UR3XFILwPgZbhfe109 8lP7UwxMAs/edit#

「EPUB Scriptable Components 1.0 」は部品そのものの仕様
「EPUB Scriptable Components Packaging and Integration 1.0」はどうやって流通するか、パッケージはどうやっているか
サンプルの「scriptable-components」は内容は薄い。おもちゃのようなもの。「docs.google.com/document」のほうが内容はまだまし。


EPUB3.1に組み込まれる機能の説明。

通信
•通信機構
•状態管理
•イベント処理
•組み立て
•Domain local storage
•ドメインごとのローカル記憶
•アクセシビリティ
•表示とレイアウト制御

通信機構
•HTML5 Web MessagingのpostMessageを使う
•IDPF ePub Widget Framework(オープンソース実装) https://github.com/IDPF/archive-widgets/tree/master/CommunicationAPI

EPUB3.1に組み込まれる機能のうち、通信機構、状態管理、イベント処理、組み立て、はウィジェット内での通信はどうなっているのかというと、イベントの発生→取得→表示などを行う。
イベントの通路があってそこにイベントが流れる。イベントの受け流しを行うだけなので、部品を入れ替えたりなくなったりしても動作に影響がない。

Rendition　Selection
いくつかの固定レイアウト/リフローから最適なものを選択する
•一つのEPUBファイル中に、等価ないくつかの表現を入れて、実行時に選択させる
•日本語版と英語版
•高解像度用と低解像度用
•画像による表現とHTMLによる表現
•普通の表現と点字
•http://www.daisy.org/projects/tobi/readium/?epub=epub_content/WCAG-ch1-multipleRenditions

Rendition　SelectionはEPUBファイルの中に複数のレイアウトを入れておいて、そこから最適な物を選択する仕組み。
いまは1種類のレイアウトしか表示できないが、例えば英語レイアウトと日本語レイアウトを切り替えたり、学習レベルによって漢字やルビを変えた内容に切り替えたり、点字や音声読み上げなどのアクセシビリティー対応レイアウトに切り替えたりできる。

Annotations(注釈)
•教科書に生徒・先生が注釈をつける
•虎の巻を、教科書への注釈として出版する
•手書き注釈も可能
•よく聞く話、以前からある話ではある
•日本の固定レイアウトデジタル教科書でも実装されている
•ソーシャルリーディングはいまの電子書籍リーダでも実装されている。

メリットとデメリット
↑特定の電子書籍リーダに依存しない
↑標準化された形式で注釈が保存されるので、安心して使える
↓W3Cにおける標準化はCommunity Specificationこそあるが、WGによる標準化はまだWorking Draftでしかない。

仕様書
•仕様書 Open Annotation in EPUB http://www.idpf.org/epub/oa/
•要求仕様 EPUB annotations - use cases http://goo.gl/dEvSLg
•W3CのOpen Annotation Data Model(Community Draft) http://www.openannotation.org/spec/core/20130208/
•W3CのWeb Annotation Data Model(First Public Working Draft) http://www.w3.org/TR/annotation-model/

参考資料(日本語)
•日本よっ!これがOpen Annotationだっ! ! http://code.kzakza.com/2013/08/open-annotation_data_model/

注釈機能は今でもいくつかのデジタル教科書などで独自機能として搭載されているが、標準化することで様々なシステムで使えるようになる。
注釈機能にはW3Cのスペックを利用してるが、コミュニティ提案の段階、まだワーキングドラフト（草案）なので安心して使える段階ではない。W3Cの勧告まちである

EPUBについての懸念 その1
•EPUB出版物は、20年後にもちゃんと読めるか?
•オフィス文書はどうか?→読めるけれど崩れていることがある
•Webページはどうか?→読めないことが多い
•Web技術をベースにするEPUBは読めなくなる?

EPUBについて懸念されること。EPUBで作られたデータは20年後もちゃんと読めるのか？
IDPFはデータの長期的な有効性についてはあまり気にしていない傾向がある。
このデータの長期的な保管については特に図書館関係者が気にしている。

EPUBについての懸念 その2
•アクセシビリティ関係者の無償奉仕に頼っている
•いつ無償奉仕が止まってもおかしくない。アクセシビリティを必要とする人にいま役立つことは別にある。
•Epubcheckがメンテナンスされなくなったらどうなる?
•EPUBの仕様のメンテナンスをきちんとできるか?
•ビジネスのためのインフラなのだから、ビジネスとしてやっているところが貢献すべき。

EPUBのアクセシビリティ対応について、EPUBがアクセシビリティ対応になると聞いたとき、従来のアクセシビリティ関係者はとても期待していた。
この規格がちゃんと制定されれば、これまでよりももっとアクセシビリティを考慮した対応したデータが出てくるのではないかと理想に燃えて協力してきた。しかし現実的にはEPUB3でもアクセシビリティ対応を実現しているものは少ない。
アクセシビリティに関する規格についてはごく少数のアクセシビリティ関係者が安い報酬でボランティア的に規格制定をやっている。しかし、世の中のアクセシビリティ対応が遅れれば、EPUBでアクセシビリティの規格をつくっても、障害者の役には立たないということになる。そうなればそういった関係者はアクセシビリティ規格に関わるのをやめてしまう。
例えば皆がいま使っているEpubcheck、あれもたった一人でやっている。あれがなくなったらどうするのか？
今のところEPUBをビジネスで使う人たちもそういうアクセシビリティ関係者の無償奉仕にただ乗りしている状態。ビジネスで使うのであればそういったところがちゃんと貢献していくべき。

ISO/IECにおけるEPUB
•IDPFのフォーラム標準というだけでは国際的な普及には十分ではない
•現時点で、ISO/IECのTechnical Specifications
•EPUB 3.1を追認して、国際規格にする可能性大

EPUBはこれで正式な国際規格として認められる

長期保存についての
ISO/IEC EPUB JWGの活動
•文書が長期(100年以上)にわたって理解できるようにするにはどうしたらよいか?
•EPUB以外のフォーマット、EPUBのいろんなバージョンを扱う
•一つ以上の閲覧システムを対象とする
•変換はいつかは必要になる
•すでに存在する技術
•Open Archival Information System (OAIS)
•Metadata Encoding and Transmission Standard (METS)
•Preservation metadata (PREMIS)
•EPUBを、これらの技術から利用できるようにする。

文書を長期にわたって保存することについて、電子文書は極めてタチが悪い。
EPUBを長期保存する方法について、特に図書館関係者は気にしていて、その方法を探っている。
現段階で電子文書の保管についてはすでに幾つかの技術が存在する。
一つの文書がどのフォーマットで存在し、どのタイミングでツールがなくなるからコンバートが必要になるのかを管理し、どうやって、コンバートし、エミュレートし、情報の欠落を管理していくかということを決めた技術
これらの技術をEPUBで利用できるようにする必要が話し合われている

まとめ
•EPUB 3.1は、デジタルならではの電子書籍に踏み出したEPUBであり、おそらく国際規格になる。
•EPUBのインフラは、アクセシビリティ関連のボランティアが支えているが、それに頼っていては危ないのではないか?
•EPUB出版物が、何十年たっても読めることを保証するためにはどうすればよいか?ISO/IEC EPUB JWGが助けになる?


【感想】
EPUB3.1はjavascriptに正式対応ということで、また新たなフェーズを迎えることになりそうです。
いままでのEPUBが「紙」の置き換えだったのに対して「紙」とは違う次元のものに。

アクセシビリティの規格制定について、少数の関係者の無償奉仕にただのりしているという指摘は考えさせられる。この件に限らず、オープンソースで公開されたものをを当然のようにビジネスで使いなんの還元もしないことや、少数の関係者がほとんど無償で規格を作っていて、ビジネス利用する側がなにも協力しないというのはよくある話。
オープンソースや標準規格というのはタダであるがタダではない。それが作られるまでたくさんの人の労力が使われている。タダ乗りする人ばかりではこれらの活動は続けていけない。ビジネスで使うのであれば、還元することを考える必要がある。

EPUBの保管について、電子書籍について話すとき、現時点では皆、これらのデータが未来永劫読めるものとは信じていないように思う。
実際、電子データがこんなに身近になったのはこの20年ぐらいで、その間を考えても20年前の電子文書がいまも問題なく読めるというのは少ない。
EPUBも3.0まではEPUB内部の構造や表現についてだけの規格だったけど、ついに「保管」がキーワードに入ってきたんだなぁ。
またその保管の仕方も「データをいかに残すか」ではなく「環境が変わっていくなかで、データを読み繋いでいくために、コンバートやエミュレート法を管理して情報が失われるのを防ぐ」という方式。文書そのものを残すというより、文書のなかの情報を（多少形が変わっても）失わずにつなぐことに着目している。



ISO/IEC JTC1/SC36 Rouen Mtg. / ICT Connect 21技術標準化WG

スピーカー:田村 恭久（上智大学、ICTconnect21 技術標準化WG座長、JEPAフェロー）

ISO SC36パリ会議報告、ICTconnect21技術標準化について

ISO/IECのRouen Mtgででたトピックのレポート

SC36（Standardization subcommittee in JTC1）では現在教育とトレーニングについての8つの規格が動いている
– WG1: Vocabulary
– WG2: Collaborative Technology
– WG3: Participant Information
– WG4: Management and Delivery
– WG5: Quality Assurance
– WG6: Platform and Service
– WG7: Culture and Language
– WG8: Learning Analytics

これらはISOメンバーだけで決めるのではなく、提案された規格を検討する形で様々な団体と共同して動いている。

Rouen Meetingの主なトピック

•WG6 議論の進展
– e-Textbook Project: 従来中国のe-Schoolbag Project の紹介を元に作成
– 韓国提案でEDUPUBの概要・仕様を含めることに

中国の電子教科書について、北京と上海の二つの流れがあり、上海を元に議論していたがこれではあまり必要項目をカバーできないのでなんとかならないかという話があり、韓国からの提案でEDUPUBの仕様を含めることになった。中国から反対意見がでるかと思ったがすんなり通った。

•WG8 (Learning Analytics) の発足
– Convener(議長):Yong-Sang Cho (KERIS)
– ISO/IEC TR 20748
•WG8/N0010: Reference Model
•WG8/N0011: System Requirements
– Study Group
•Systems governance for learning analytics
•Data framework for learning analytics interoperability

WG8 学習履歴の取得と分析のワーキンググループが発足

Learning Analyticsの位置付け

Learning Analyticsとは学習において教科書を読んだ後のアクション、履歴の管理。
つまり、授業で電子教科書を使うなかで、どのページをどのタイミングでめくったかといったような、学習者の行動の履歴をとる。
履歴を管理することでその人がこれからどんな行動をとるかを予測したり、どのぐらい理解しているかを予測できる

履歴の取得
たとえば、易しい授業、科目では先生が教科書を読み上げて説明している間学生はどんどん次のページをめくって先の情報を見たりする。今先生が説明している内容を目で追うのではなく、次になにがでるか、今日の課題は何になるかなどを先をみて知ろうとする
しかし、内容の難しい課題の場合は先生の説明に集中し、該当ページから動かない傾向がある

その学生の学習スタイル傾向が分析できる
先生の読む先をどんどん読もうとする学生、逆に同じところをずっと見ている学生など、こういった個人ごとの学習行動情報を分析していけばその生徒のタイプにあわせて教え方を変えると言ったナビゲーションをすることができるはず。

また、逆にこの分析によって「この先生の話は誰も聞いていない」ということもわかったりする。学校側から先生に対する指導に使えるかもしれない。
イギリスなどではスクールアセスメントとして学校の評価が盛んである。これはそういったことの判断材料になるかもしれない。

Learning Analyticsがなぜ今注目されているか、こういった学習行動履歴の分析は媒体が紙である時はできなかった。
LMSやタブレットの普及で電子教科書がつかわれ、こういった生徒の活動履歴を貯めることが可能になった。

ICT Connect 21 技術標準化WG

ICT Connect 21(みらいのまなび共創会議)

•2015年2月発足の民間団体
– 目的:「学習・教育オープンプラットフォーム」に関連する技術の標準などを策定し、その普及を図り、教材コンテンツや教育ICTサービスなどの流通や利活用を促進することで、誰もがいつでもどこでも多様な学習・教育サービスを享受できる環境の実現を目指し、利用者とサービス提供者双方の利便性の向上ならびに教育の情報化の一層の進展に寄与するとともに、社会の発展に貢献すること

ICT Connect 21は民間団体であるが、背景には総務省が関わっている。
教科書の内容や授業内容については文科省の担当分野であるのだが、総務省はそれ以外の公務関連の事柄について、例えば導入されるコンピューターの管理や整備、クラウド環境の構築、プラットフォームの普及などを考える役割。
総務省が「この規格を使え」というのは問題があるため、ICT Connectが間に入って代わりに提案する役割になっている。

たとえば、生徒の成績や情報をクラウドで管理することに不安や抵抗を覚える学校関係者は多い。そういった関係者を説得するためのプロモーションなどを行う。

総務省 先導的教育システム実証事業
http://www.soumu.go.jp/main_sosiki/joho_tsusin/kyouiku_joho-ka/sendou.html

総務省は先導的教育システム実証事業として実証実験を開始している。


ICT Connectの構成。
ICT Connectには普及推進WGと技術標準化WGがある。
技術標準化WGでは以下のような内容が話しあわれる予定

国際連携SWG
•既存・策定中の標準規格やガイドライン(国際含む)の調査
•規格やガイドライン相互の整合性検討
•国内で議論された仕様の国際規格への提案

既存の規格の調査や整合性調査

校務系ー学習系情報連携SWG
•校務情報における各種標準規格やガイドラインの調査
•将来ICT Connect 21で扱う仕様とするための検討
•連携すべき情報・学籍情報・仕様化の検討

公務系の標準規格の調査

ユーザー認証SWG
•全国レベルの「教育の情報化」に必要なID、属性の管理や信頼関係の構築、運用といった技術、ポリシーに関連した国内外の技術動向、標準規格、事例の調査
•上記の認証に関連する仕様の検討

システム内でユーザーを特定するにはどうするか、IDの管理についての調査。マイナンバーなどの既存IDを使うのか？

CBT SWG
•CBT (Computer-based Testing)に関する技術の調査
•関連する仕様の検討

試験サービス全般の仕様について。


【感想】
教育分野のデジタル化というのはいまとてもアツいジャンルであるのだけど、教育分野でデジタルを活用しようとすると、単純に教科書や教材をデジタルに置き換えただけではだめで、それを取り巻く環境（サーバーやデータ通信、ID管理やデータ分析など）の構築が必要になる。そういった求められるものに対して規格がまだまだ整っていないというのが現状。

どういったものが必要になるのか、については以前参加したJEPAのセミナーレポートにある（JEPA　国際 デジタル教科書 技術ワークショップ）
そのなかのMarkus Gylling氏のセッションから引用

（デジタル教科書を利用した教育システムを構築するにあたって）ベンダーに縛られず、中立であるために必要な物

•サーバー
•閲覧するための端末、リーダーソフト
•コミニケーションプロトコル
•コンテンツ

この中でコミニケーションプロトコルについて、システムに必要な機能は以下のものが考えられる

・コンテンツ（教材）の発行に伴う権利を付加する機能が必要
・どんなカリキュラム、コースであるかの管理
・クラウドベースでの（クライアントの）状態管理
　生徒がどこまで進んでいるか理解できているかの把握
・宿題をどのように割当て、管理するか
　生徒の理解度などによって、適切な宿題を出す、またその提出などの管理
・テストをどうやって実施するか
・生徒や教師が教材に注釈を自由に入れられる、その注釈をお互いに見たり、自分だけで見たり、特定のメンバーで共有したりできる

さらに、いくつかの必要条件があります

・デバイスについて、どのデバイスでも問題なく動く必要がある
・トレードブル、「ここがわからない」というコメントに先生や生徒がコメントをつけられること
・マルチモーダル、テキストだけでなく、絵や音声をつける事が出来る必要がある
・権利とオーナーシップ、誰がそのコンテンツの権利を持っているかの情報管理
・シェアリング、一人がアクセスするか、誰でも見られるか特定の人だけが見られるかの管理
・注釈のインポート/エクスポート、教材に書き込まれた注釈を書き出して別の環境で再現する方法が必要

今回WGが発足したLearning Analyticsはこのなかの「クラウドベースでの（クライアントの）状態管理」に該当するかな。
さらに総務省 先導的教育システム実証事業で、実証実験も開始されている。

以前このセミナーを受けたときは、決めなければならないものが多すぎて、先の長さにめまいがしたのだけど、その後定期的教育関連のセミナーを受けていると、少しずつではあるが規格の制定や実証実験が行われ、着実に進歩しているんだなと感じられる（というか、結構なスピードで動いていると言っていいかも）


IMS/GLC 2015 東京セミナー報告 Caliper 1.0

スピーカー:高瀬 拓史 （イースト）

IMS東京会議報告、Caliper、aQTIについて

Caliper 1.0
Learning Analytics（生徒の行動を蓄積し分析する）
学習分析フレームワークの標準
学習活動を取得して蓄積し分析に役立てる。
データやAPIを標準化し相互運用性を高める。

2015/05/06仕様が最終リリース候補となる

Caliper 1.0の文書として以下のものが公開される予定

•Caliper Analytics Implemenation Guide
Metric Profilesの定義、Sensor実装の紹介"

•Caliper Analytics Getting Started and Best Practice Guide
sensorコードライブラリ、サンプルアプリのインストールと使い方
ベストプラクティスの事例が幾つか"

•Caliper Analytics Conformance Guide
テストフレームワークの利用法、Caliperイベントの要件一覧"

•LTI Implementation Guide
CaliperをLTIで使うためのツールプロファイルの記述方法

Caliper 1.0は学習活動の収集に焦点を当てている。蓄積や活用はこれから。

収集（記述・転送）→保持（蓄積）→活用（分析・可視化…）

IMSは日本語の情報がまったくないため、すべての事柄をいちいち調べていかなければならないが、そのなかで色々な視点を得られる
IMSは長い歴史の中で教育分野の多岐に渡る標準を作り上げてきた。
IMSの標準を知ることで、Eラーニングに必要となる技術について俯瞰的な視点が得られる。
Caliper 1.0はかなり限定的。現時点では簡潔でわかりやすい反面、実用にはさまざまな補完を自前で用意する必要があるだろう。


【感想】
Caliperについてがメインだったのと、技術内容は公開されている資料（http://www.jepa.or.jp/sem/20150728/）を見た方がわかるので概要だけまとめ。

Glyphsの初心者向け勉強会があるよのお知らせ

文字 セミナー Font

── こんにちわ！「ちくちく日記」です！

「こんにちは、ちくわです。…うわぁ！久しぶりすぎる！」

── 一年ちょっとぶりだね！（ちくわその1　ちくわその2）

「なんかもう、マスコットキャラとか忘れられてるのかと思ってました」

── もともと一回かぎり使い捨てのつもりで出したキャラだったからねー。

「ひど！扱いひど！っていうか、そもそもあなたブログ全然更新してないじゃないですか。この一年で書いたのがたった4本ってあんまりじゃないですか？」

── 今年は新年の目標で「月に一本はブログ更新！」って目標たてたよ！

「もう3月なんですけど！すでに全然守れてねぇ！」

── このままWebの大海に沈んで消えてしまうのもいいかもしれない…

「その割に忘れた頃に更新してますよね。往生際悪いなー」

── まぁいいじゃない。それじゃ恒例の新しい体だよ

「頭がアンパンの人みたいな言い方はやめてください。また適当な写真ですか」

── はい。

「袋のまま！！！せめて袋からだしてくださいよ！」

── わざわざ写真とるために買ってきた。見栄はって一番高いやつな！いつもはPB製品の一番安い奴しか買わないのに！

「それ言っちゃったら見栄はった意味ないです。一番高い奴っていっても購入が近所のスーパーってあたりにやる気のなさがでてますよ。それで、今日はどういう用件なんですか」

── じゃーん「Glyphsの初心者向け勉強会があるよのお知らせ」です！2015年4月19日、エッサム神田ホールにて！

「え？また？またやるの？てか、僕Glyphs勉強会限定キャラになってません？」

── またやるっていうか、今回は私じゃなくて、東京DTPの勉強会さんの主催だよ。


「あ、勉強会さんでやるのか。それでなんでここでお知らせするんです？」

── Glyphs勉強会ってことで、去年あれだけ大騒ぎして勉強会をやった私としては他人事と思えないからね。それに講師はものかのさんと照山さん！ものかのさんには去年の勉強会でも講師をやってもらったご恩があるし、照山さんはその勉強会からGlyphsを使い始めたっていう、うちから産まれたといっても過言ではないGlyphs使い！

「いやいやいやいや過言だろそれは」

── 実際照山さんは、初心者向け勉強会に参加した後、FacebookのGlyphsユーザーグループ、Glyphs日本支部で積極的に質問して、次々に「やわらかあたまなふぉんと」を作り出しているんだよ

「『やわらかあたまなふぉんと』ってなんです、それ」

── 例えばね「図版で範囲を{}(波カッコ)で囲むときに、自動的にサイズに合わせて伸び縮みする{}(波カッコ)文字」


「あっ、これは便利だ。へぇGlyphsを使うとこういうフォントも作れるのか」


── 「数値を入力すると自動的に棒グラフになるフォント」


「なるほど。フォントを作るっていうと書体デザインをやるのかなーと思うけど、入力したら形が出る機能って考えれば色んな利用法があるんですね」


── こんなのもある「時刻に合わせて秒針が動くアナログ時計フォント」

(こちらのリンク先で動作をご確認ください)
「えっ…！えっっ…！なにこれ…！これ、もしかして、アナログ時計の部分がフォント！？えっなにそれ！！！！！！！なんでうごくのこれ！」

── Webフォントの仕組みらしいんだけどね。うん。ここまでやると立派な変態さんだね！（褒め言葉）

「『褒め言葉』ってつければ何言ってもいいってわけじゃないですよ！でも変態だ！！！！」

── 柔軟な発想をもてば、フォントひとつで色んな事ができるってことだよ

「…なんか難しそうですね…」

── いやこれは照山さんが変態さんなだけでね！勉強会ではもっと簡単なとこから入るからから大丈夫！フォントを作るってやってみると簡単だよ。こんな多機能なフォントじゃなくても、普段インライングラフィックでつかっている外字をフォントに置き換えるだけですごく作業効率はあがるし。あとフォントってどういう仕組みなのかなっていう知識を得られるってのも役に立つと思う。

「今度の勉強会は初心者向きなんですよね。…あれ？ハンズオン？ってことはパソコン持ち込みでってこと？」

── そう。実際にGlyphsを触ってみて、使い方を一から教えてもらえる。去年私が勉強会をやった時も初心者向きのハンズオンセッションはものすっっごく好評だったんだよね。

「えー、でも『Glyphs、Illustrator、InDesignがインストールされている事』って…、すごくハードル高いですよ…全部持ってる人ってそういないんじゃ…」

── 体験版があるじゃない！体験版なら無料！

「うーん、でも操作に慣れてないから、ハンズオンでもついていけないかも…」

── 会場ではスタッフがサポート役としてつく事になってるからつまずいてもサポートしてもらえるよ。今回は少人数で行うセミナーだしね。

「それに…僕、Macもってないんですけど！」

── おまえちくわだもんな！！！！

「ぼくの体ではマウスもキーボードも操作できませんし！」

── その体に手足はえてたら気持ち悪いから！…いや、いいよ。うん、マシン持ち込みなし見てるだけ受講もありってことで。

「えっ、いいんですか？」

── うん、真面目な話、見てるだけでも勉強になると思うんだよね。実際、前回初心者だった照山さんは、あっというまに引きずり込まれて今じゃどっぷり文字っ子の沼の住人だし。

「なんですか、その文字っ子の沼って」

── 文字の世界ってさ、なんかちょっと興味をもって「あれ？面白いかも」とか話を聞いているうちに、ずぶずぶと深い世界に飲み込まれるっていうかそういう感じなんだよね。そういう人がいっぱい生息してるのが「文字っ子の沼」

「せめて泉とか池とか海とかきれいな言い方はないんですか」

── あ、一番深くて濁ってるのは文字コードのエリアだから！あそこらへんの住人の濃さは半端ない。タイポグラフィデザインとかそういうあたりは、深さはあっても水は澄んでてきれい感あるよね！

「でも今回のGlyphs入門っていうのは、あくまで初心者向きだし、フォントを作ってみるだけならそんな泥沼ワールドってわけじゃないですよね」

── なにいってんの！いいか、フォントを作るって言うのはね、タイポグラフィデザイン、文字コード、フォント構造、システム、アプリケーションの挙動、すべての文字沼ジャンルに足を突っ込むってことなんだよ！いわば文字っ子変態道のエリートコース！！

「初心者を怖がらせるような言い方するなよ！」

── はじめてさんにも、ものかの先生が優しく指導！

「あっ、あの人優しそうだもんね。それなら大丈夫かな」

── 「怖くないですからねー、大丈夫ですからねー」っていいながら、腕をつかんで文字の沼にずぶずぶずぶずぶずぶーーーーーーーーっっと！！！

「妖怪かよ！なんだ引きずり込むって！！」

── だってあの人、文字の沼最深部の住人だもん。語り口やさしいし、説明がわかりやすいからうっかりだまされるけど、話してる内容はディープ！

「そこは『難しい内容もわかりやすく教えてもらえます』っていうだけでいいんじゃないの」

── さあみんな！いっしょに変態になろう！

「文字に関わる人みんな変態みたいな言い方はやめろ！」

── おいでよ文字っ子の沼！

「住人は妖怪ばっかりか！」

── みなさんの参加をおまちしております！


★今回は少人数での開催ということですが、まだ少しなら席があるようです。パソコン持ち込みなし、聴講のみの参加もOKだそうです。お申し込みはこちらからどうぞ。

大日本印刷の活版印刷設備

文字 その他

ちょっと前の話なのだけど、書いとかないと忘れちゃうからな、というわけで久しぶりに日記。

大日本印刷の活版印刷設備を見学してきました！

活版印刷ってあれですよ、銀河鉄道の夜でジョバンニが家計を助ける為にやってた字を拾う仕事（文選）のやつ！鉛で出来た活字を一文字一文字並べて印刷の版を作るやつです！（乏しい知識による説明）

▲これな。（映画「銀河鉄道の夜」より）

最近はそのでこぼことした風合いが味があるということで、ちょっとこだわりの名刺とかはがきとかを印刷してくれる活版印刷所というのが人気だそうですが、どこも小物が中心の小規模な印刷で書籍や雑誌などの大物を扱えるような規模ではありません。
活版で大規模な印刷をしていたのなんて、もう30年、40年、いやもっと前の話です。写植ができて電算写植になってその後DTPに移行したこの50年の間に、活版印刷は衰退し、当然設備なんかも（小規模の印刷所程度しか）残っていないと思ってました。


ところが、その活版印刷の大規模な設備がまだ大日本印刷に残っている！え！なにそれ！ってことで見学させてもらってきました！


分け入っても分け入ってもDNP

活版印刷の設備が残っているのはDNP、市ヶ谷の工場。あの大日本印刷の工場や建物が林立している「DNP村」と呼ばれるエリアです。
いやー、私ここには初めて行ったんだけど、ほんとあのエリアって大日本の建物ばっかりなのね。「分け入っても分け入ってもDNP」って感じで。右を見ても左を見てもDNPの建物。
山手線の内側エリアにこんだけ広大な敷地で工場とか建物があるってすごいわー…。さすがに日本一位の印刷会社だぜ…。

活版印刷設備はこのエリアの、今はもう使われていないスタジオに保管されていました。


▲保管された活版印刷設備

写真だとわかりにくいけど、このスタジオ広いんです。
バスケットコートぐらい…？はあったかな…。その広いエリアにぎっしりと活字棚。

この設備がどのぐらいの規模なのかというと「活版印刷での週刊誌を組むのに必要な数の活字棚」が揃っている。
つまり、名刺やはがきのように文字が少ししかいらない端物印刷と違って、週刊誌、文芸誌などを組もうと思えばそれだけの数の活字と、短期間で必要なページをくみ上げるだけの職人の為の活字棚が必要。大量の活字と活字棚。必然的にこのぐらいの物量になる。

さらに活字だけでなく、必要な活字を鋳造する為の鋳造機も必要。もちろんこれも残ってる


▲鋳造機。鉛を溶かして活字を鋳造する。銀色のは鉛の延べ棒。



組み上がった活字を入れた木の箱（ゲラ）を校正用に印刷する機械も。これで刷った物がほんとのゲラ刷りというやつ。

▲ゲラ刷り機


ちなみに、今回見学できたのは大日本印刷の方から「興味あるなら見学しますか？」というお話があり、ありがたく参加させていただいたため。設備も倉庫も通常一般公開しているものではありません。

2004年まで現役だった活版印刷

さて、これらの設備、こんだけ大規模な設備がまだ残っているなんて、大日本印刷物持ちいいなー、何十年保管してるんだよ…と思ったら。

「実は2004年頃まで、活版印刷での週刊誌制作を行っていたんです」


にっ…2004年…っ！？


えっ？えっ？10年まえだよ？？？写植どころかDTPあるよ？？？QuarkどころかInDesignあるよ？？？？？
そのころに活版印刷で週刊誌制作？？？？？？週刊誌？？？しゅうかんしぃいいいいい？？？？？


なにかんがえてたんですか大日本さん！！！！！


…どういった理由からかは聞き損ねましたが、大日本印刷では2004頃まで、活版印刷での情報誌（週刊誌、文芸誌など数冊）制作を行っていて、現役でこれらの設備が使われていたのだそうです。
た、たしかに残されている活字棚をみると「インターネット」「ワールドカップ」などの近代的な言葉が用意されているのがわかる（活字棚は組まれる仕事にあわせてよく使う活字をまとめて並べらているのです）まじだ…まじで10年前までやってたんだ…。



▲なんか廃屋で古いエロ雑誌みつけたみたいな風情がただよう活字棚
残された文字にどことなくいやらしさが漂うのは最後まで活版印刷を行っていた業務がスポーツ系雑誌とエロ系文芸誌だったから。

10年前に活版印刷が終了した後、一旦すべての設備をこの空きスタジオに移設し保管しているのだそうで。
設備を動かす際、活字や活字棚をそのまま移設するため、運搬業者がすべての棚にナンバリング、梱包して搬送。その後元通りに復元するのに丸一ヶ月かかったとか。がんばったな日通…（活字の重さ、細かさ、量の多さを考えると、見積もり依頼された段階で断ってしまいたいような案件じゃなかったかと思う…）

ちなみにこの空きスタジオも近々取り壊されるため、再度のお引っ越しが予定されているのだそうです！それも日通かな！がんばれ日通！


これからどこへいく

これらの活版設備の今後について、とりあえず今のところは「全部残しとく」という方針なのだそうですが、いつまでその方針なのか、この先どうするのかは決まっていないとのこと。
うーん、確かにこれだけの規模の設備をどうするっていっても難しいなぁ…。たとえば博物館などに展示するといっても、活版印刷の仕組みを知るだけなら活字棚一つ、鋳造機一つぐらいあれば用は足りてしまう。ここまでの数をそろえておく必要はない。
だけどこの設備の価値は「これだけの規模で残っている」っていうとこなのだ。

印刷物を作るというのがどれだけ大変な仕事だったか

見学をさせていただいたのは10月の中頃で、その時期ちょうど「ドットDNP」(大日本印刷が運営するイベントや展示を行うコミュニケーションスペース)で「ドット電車フェア」という展示が行われていた。
電車をテーマにした展示なのだけど、その中に「電車の時刻表を活版印刷で再現する」として、東海道新幹線開業当時の時刻表を当時と同じ活版印刷で再現したものが展示されていた。


▲展示されていた時刻表の活版組版。ものすごい細かさ。

この組版、現役の活版印刷所の職人さんにお願いして植字してもらったそうなのですが、ベテランの職人さんにおねがいしても「1ページが組み上がるのに朝の9時から始めて丸一日かかった」のだそうです。

時刻表という超絶に細かい文字組だからというところを割り引いたとしても、活字による組版はそれだけ時間がかかるもの。

そんな手間のかかる作業で、時間との勝負である週刊誌、大量の文字を扱う文芸誌を組もうと思ったらどれだけの人手が必要であるか。また日本語という、ひらがな、カタカナそして大量の漢字が必要な言語で文章をつくるためにはどれだけの活字が必要になるのか。

印刷物を作るという事がいかに大変なことだったかが、この膨大な設備を見ると本当によくわかるのだ。


そしてこの設備は「これだけの規模で残っている」というところが価値であるが、同時に「これだけの設備が残っていてもまったく意味がない」ものである。
道具としては、いまでも週刊誌が組めるほどの機械、材料が残っている。だけどやろうと思っても、もうこの設備で週刊誌は作れない。
なぜならこの設備はこれを使いこなせる人間がいて初めて使える物だから。
大量の活字の中から、短時間で目的の文字を拾い集める文選工、集められた活字を正しく組み上げる植字工、それぞれの専門的能力をもった熟練者がいなければここから印刷物を作り出す事はできない。

10年前まで活版印刷が行われていたこの現場で働いていたのは、ほとんど70歳代など年配の職人さん達だったそうです。
多分定年後もその業務のために継続して勤めておられたのでしょう。活版印刷による制作が終了したと同時にその職人さん達も引退している。
そして職人さん達がいなくなった時点でここの活字達は「印刷物を生み出す為の道具」から「ただそこにあるだけの物」になってしまったのだ。


この設備を見学する前、今回の見学を設定してくださった大日本印刷の方から「（あの設備を）見ると、一台のパソコンの中にこの設備と同じ文字がはいってるなんて、PASSPORTすげーーーーー！！！ってなりますよ」って言われたんだけど、うん、なった。
PASSPORTすげえっていうより、これだけの設備が必要だった印刷が、たった一台のパソコンでできるようになっちゃってるなんて、なんてすごい事なんだろうってものすごく実感した。

この設備が今後どうなるのか、どこにいくのかはわからないけど、多分これだけの規模の活版設備を見られるのはもうここが最後の場所じゃないかな。
なくなってしまう前に、ここをみることができてほんとうによかったとおもう。

そして、最後までここで働いていたという活版印刷の職人さん達、年代からいって就職してずっと社会人生活すべてが活版印刷とともにあった世代だ。
多分、後年数十年の間は活版印刷の終わりをひしひしと感じながらのお仕事だっただろう。「この仕事はいつまでやれるのか」と不安になったりもしただろう。だけど、結局最後の最後まで活版印刷でお仕事をして、その終わりまで見届ける事ができた。それはとても幸せなお仕事人生だったのではないかな。

私もこういう風に最後の最後まで仕事したーっていうお仕事人生がいいなぁ。…あれ？でもその場合私のお仕事人生を伴走してくれる相棒は何になるんだろう…。



…。
……。
…………もしかしてこいつ？

▲神様…


なんだろうものすごい「お前かよ…」感！
活版印刷の職人さんたちは活字と共に走った仕事人生だけど、こっちはAd○beに走らされ、翻弄される仕事人生だよ！ちくしょう！

ブックフェア/電子出版EXPO 2014不真面目レポート

セミナー その他

ブックフェア/電子出版EXPO 2014に行ってきました。
真面目なレポートを書こうと思ったんだけど書いてて途中で飽きちゃったのと、レポート自体は他のところでもいっぱいでてるしなぁと思うといまいちやる気がでないので、他が書きそうにないとこだけ先に書く事にしました。

「口説く写真集」


今回のブックフェア、凸版印刷のブースで展示してあったこれ。

「口説く写真集」
アイドルとチャット形式でお話してると、写真集の画像が見られるというアプリ。

要は写真集アプリで、チャットという形をとりながら画像を見せるという、ただそれだけのものなんだけど。
チャットの会話は事前に用意された言葉を返すだけですが、それなりにこちらの会話に合わせた返事が返ってくるようになってる。
説明員氏のお話によると、最近「写真集」というものが売れなくなってきている中、なんとか写真集を売りたいという思いからこういうアプリを考えたんだそうです。真面目にやってるんだそうです。


展示では説明員の方が実際に操作をしながら説明してくれたのですが。

『ねぇねぇ♪ひなたのどんなところが好き？』
『顔？からだ？性格？…それとも、おっぱいとか？』

「顔」

そこは「おっぱい」だろ！

説明員氏「ちょっと今は昼間ですし、こういう場所ですので…」

そんなとこだけ中途半端に真面目になるなよ！ふっきれよ！



んで、このアプリ、他にも機能がついてまして。


▲モザイク消しゴム…！

ほんとーにアホですばらしいな！

消すのか！モザイクを！さらに左隣にあるのは「袋とじツール」だ！

実際にどんなモザイクを消してくれるのかぜひ実演して欲しかったのですが、そこまでの仕込みがないのか、それとも私が女だから実演がはばかられたのか、やってもらえませんでした。


わたくし、このアプリはくだらなくてほんとーにすばらしい！と思ったのですが、会場であった知り合いに「あれいいよね！」と熱弁をふるっても誰一人同意してもらえなくてつらかった。

え？なんで？だってモザイク消しゴムよ！？モザイク消してくれるのよ！？


「そもそも、今時の若い人はネットで無修正見慣れてるし、モザイク消したいってのがよくわからないんじゃないか」



まじで…！このロマンがわからないなんて、つまんない時代になったもんだな…！

CSS3のルビ機能を考える

電子書籍 文字 その他

昨年来日し、CSS3の日本語組版について楽しいディスカッションを提供してくれたCSS3のエディターfantasaiさんが今年も来日されました。

去年、fantasaiさんを囲んでの食事会ということで居酒屋に集まって穏やかに親睦を深めるだけのつもりがfantasaiさんから「日本語縦中横の横幅はどうあるべきか」という楽しいお題がだされてしまった結果、集まった皆がfantasaiさんをほっぽらかして大激論をやる、という盛り上がりを見せてしまったため、今年は「それなら最初から議論するつもりで集まった方がいいんじゃないか」と主催の方が考えたのかどうかはわかりませんが、とにかく今年は「CSS3が開く日本語組版の未来」と銘打ち、会議室をかりての勉強会開催となりました。
告知が開催二日前という直前だったにも関わらず、なかなかに濃いメンツが顔を揃えたのはさすがというか。（参加者リスト）



ここから当日話された内容についてレポートしますが、レポートは私の手書きメモをもとに書いています。録音からの書き起こしなどではないのと、fantasaiさんの話を聞いて「こういうことだろう」と推測したものも混ざっているので、細かい部分などは間違っている可能性があります。それとその場で話された話だけでなくその後の懇親会でさらに話をした内容なども含みます。

第一部　fantasaiさんからの提示

第一部はfantasaiさんから「現在CSS3で決めようとしている仕様」について。

【問題】

文章にルビをふる際に、親文字に対して長過ぎるルビ文字がきたときの組版処理はどうあるのが一番よいか


現在仕様をまとめているルビ処理についてfantasaiさんから「親文字が終わっても、ルビだけの行が次の行まで続くような処理を容認できるか？」という質問がありました。



▲親文字が終わってもルビが次の行まで続く。つまりこういうことですな

CSS3で使われる場合、ページ幅というのが可変なので、たとえばスマホ画面のような狭い画面に親文字より長いルビ文字が来た場合、ルビ文字だけが改行するという処理になるかもしれないと。



▲改行してルビだけの行が出来た状態。左はfantasaiさんがボードで説明した図、右は実際に組んでみたもの


しかし、この「ルビ行だけが改行する」って実際作ってみると奇妙だなぁ…。
あの場ではホワイトボードに手書きだったから「まぁそうするしかないかな」という感じだったんだけど、実際にルビ行だけが折り返す表示の奇妙さよ…！
まあ日本語組版においても、ラノベとかでやたら長いルビとかあるけど…。
CSSでの表示、この場合ルビだけの行ができてしまい、もしかしたら改ページしちゃう可能性もあるって事だよね…。
「デフォルトはルビの改行禁止にしてオプションで改行可という処理にする」という話もでてたのだけど、改行禁止の場合長過ぎるルビはどうなるのかはききそこねた。


さらにfantasaiさんは「ルビ機能は今後こういったケースにもつかうことが考えられる」として以下のような例をだしました。


▲日本語の文章に対して、英語、フランス語の対訳をルビとしてふる。左はfantasaiさんがボードで説明した図、右は実際に組んでみたもの


ルビ機能は「単語に対してその読みを添える」機能というだけではなく「文章に対して追随する添え文機能」なので、こういった文章の対訳を併記するような使い方が考えられる。親文字に対して長文になることもあり得るし、ルビが1行ではなく2行、3行とつくこともあり。
この場合、通常のルビのように単語に対してその意味を対応させるというのが難しいので、どこで改行させるべきかという問題などがある。

会場からは「これはルビではなく注記といったものであると考えられるので、ルビのように単語と単語で対応させる必要はない。つまりそのまま肩付きにして流すしかない」という意見や「親文字がジャスティフィケーション指定されたとき、ルビの扱いと、ルビのつかない文字部分との扱いはどうあるべきか」といった議論がありました。


▲ジャスティフィケーショ処理でルビ部分と親文字部分、それ以外の部分をどうスペース処理するか


さらに「ルビが入ったときの行間のありかたはどうあるべきか」というような話題
上の行とルビの行間の間隔が均一だと、ルビが上の行についているのか下の行についてるのか判断しづらくなるので、上の行と下の行のルビ間はルビ親文字とルビ間より大きくなければならない。


▲親字のマージン設定を活かすべきかどうか？といった説明

マージン設定を活かすと上下左右のマージンと干渉するので、それよりもルビオフセットといったルビ下空きを指定するプロパティを作って、そこで設定するほうがよいか？という議論。
ルビオフセットというオプションを作った方が設定はすっきりするが、こんどはボーダーの指定と重なったときにどこからどこまでをルビオフセットと考えるかなど。



【感想】
CSS3の組版機能を考えるというのは「ありとあらゆる可能性に対して一番問題の出ないであろうデフォルト処理を考える」ということである。
例えば「ルビが長過ぎて行（またはページ）をまたいでしまいそう」といった場合、今までの紙の組版であれば「前後の文章（コンテンツ）を変更し調整する」といった処理でにげることができた。
しかしCSS3という「可変の文章を表示するためのルール」となると、コンテンツを変更して対応するといったことは不可能。となると、まず優先されるのは「とにかく読める事」である。まずコンテンツが欠落せずに表示できること、これが第一の優先事項。その次に読みやすさ、美しさがくる。
言い方は悪いけど「読めればいいじゃん」というのが最優先。
この中でどこまで今までの『美しい組版』が生き残っていけるか。というか必要なのか。
処理として必要とされるところまでは採用されるが、美しさのみを目的とするものは採用されないのではないか。

fantasaiさんの提案はどれも「まず読める事」を第一にしてよく考えられていたと思う。正直「ルビだけが改行する」という仕様は実際見ると変だなぁと感じるのだけど、じゃあどうすればいいかといっても対案を思いつけない。

さらに、このルールは日本語だけを対象にしたものではない。
日本語の処理をもとに搭載された機能であっても、規格となった時点ですべての言語でこれが使われると考えなければならない。「日本語ではそういう使い方はしない」というのは通用しないのである。

紙の組版に必要とされる美しさと電子の組版に必要とされる組版は違うのだから、CSSの規格としてはこれでいい、という考え方もあるけど、今後CSSを使って紙の組版を作る、という流れもある（電子書籍から印刷するとかね）と考えると、どういう規格になっていくのか興味深いところ。
残念ながらfantasaiさんはこの後予定があるということで、第一部のみの参加だったのだけど、fantasaiさんの考えるCSSの組版処理が聞けて、普段日本語組版だけを相手にしている私たちにとって大変示唆にとんだ時間となりました。


第二部　標準はどうやってつくられているか


後半はCSSのエディターである石井宏治氏や村上真雄氏）、この会の主催者である小形克宏氏による「W3Cの標準規格というのはどうやって決まるのか」といったテーマでのお話。


今CSSで日本語組版が取り込まれようとしている。これはインタナショナライゼーションというか国際化の流れ。
昔のCSSはラテン文字による横書きを前提としてた。だけど、Webという全地球的に使われるものの中で英語（ラテン文字）だけを前提とせず、色んな文字体系に対応していかなければならない。その流れのなかで日本語組版への対応がある。

CSSが目指しているのは「日本語組版」ではなく「多言語組版」。
今日もfantasaiさんは日本語組版の話はしていない。ルビの話でも、それが英語、フランス語でつかわれる場合の話をしている。

W3Cの規格というのはどういったものであるのか。W3Cの規格とは大きな物で言えばHTML、CSSといったあたり。
一番大事なのはW3Cは「実装」を前提とする規格だというところ。


W3Cの規格はどうやって決まるか

W3Cで規格として登録されるには、WD（草案）→LC（最終草案）→CR（勧告候補）→PR（勧告案）→REC（勧告）という手順をふむ

WD（草案）ここでどういった仕様にするかの草案をだして

↓

LC（最終草案）CSSワーキンググループでその草案を議論して練る

↓

CR（勧告候補）勧告候補になったら「実装の呼びかけ」が行われる

↓

PR（勧告案）規格を実装したアプリケーションが複数あると認められれば勧告案へ

↓

REC（勧告）規格として認定！


まず仕様はWD（草案）としてメーリングリストで議論される。ここはオープンな場なのでその気になれば誰でも参加できる。fantasaiさんは17歳でメーリングリストに参加して学生の内にエディターになった。
メーリングリストで叩かれ、練られた草案はCR（勧告候補）へ進み「実装の呼びかけ」が行われる。
CRの段階で「実装の呼びかけ」が行われるというのがW3Cの大きな特徴。実装が伴わなければ次の段階に進めない。提案された（HTMLなりCSSの）規格を実際に搭載したアプリケーションというのがなければ、実際の規格として認めるところにいかないということ。
CRの段階まで進んだ規格であっても、その後実装するアプリケーションがなければWDに差し戻されることもある。

実際、2003年MicrosoftがつくったCSSテキストの縦組標準はCRまでいきIEに実装したが、それ以外のアプリケーションで実装するものがなくWDに差し戻されている。（IEほどのブラウザが搭載したといってもそれだけでは認められない）

この「実装とともに進む」というのはものすごく時間のかかるやり方。他の標準規格でこういったやり方をやっているところはない。ここがW3Cの大きな特徴。

実装が認められる条件も厳しく「2種以上のアプリケーション」で「実装具合が問題ない（規格の条件を満たしている）」こと。
この「2種以上のアプリケーション」については、どんなマイナーなアプリケーションでも認められるわけではなく、ある程度規模が大きく、影響力（このブラウザが搭載すれば、他のブラウザも追随するといったような）が強くなければだめ。つまり、IE、Safari、Firefoxといったあたりが実装するような。

仕様と実装について、その仕様がちゃんと実装されているかどうかといったテストは誰がやるのか？というと、ボランティアでやるということになるのだけど、そういっても誰もやらないので、現実的にはブラウザベンダーが自社の開発のためにテストをかいて、それを寄付しているということになる。


W3Cの難しいところ

ISOやJISのようなデジュール標準（特定の機関で話合いの結果登録された規格）は、登録された規格に対して特許がとれる。対してW3Cはデファクト標準（多くの人が使っているという事実を基準として規格とする）なので、規格としてRECまで進むと特許の請求を破棄しなければならない。つまり企業にとっては苦労して規格を作っても直接の利益にはならない。
このため、W3Cはどうやってお金を回すかという問題が常につきまとっている。

W3Cで規格を通すには
・仕様を書く人（エディター）
・実装する人
・テストを行う人
が必要。これを全部もっているブラウザベンダーなどがやるのが一番話が早いのだけど、大手ブラウザベンダーなどは自社の利益に関係なければなかなかやってくれない。

特に問題なのは実装とテスト。ここをやるのにはお金がかかる。今やっているCSS Writing Modes、縦組などの実装も、諸々ひっくるめてやるのには3千万から5千万円ぐらいのお金が必要。


ブラウザとしてもレイアウトに関する部分というのはプライオリティが低い。レイアウトに手を入れるよりその分HTMLの読み込みが1％でも早くなった方がいいでしょという考え。
ブラウザの開発にテスターも含めて1チーム2-300人ぐらいいてもその中でレイアウトの部分をやっているのは7人ぐらい。縦書きというはブラウザの中でもかなり下の方のコードに手を入れなければならないので、大変な実装になる。実装をやってもらおうと思ったらその7人の中からこれが出来る人を押さえて確保しないといけない。


ユーザーに何ができるのか

ベンダーに機能を実装してもらおうと思ったら、ユーザーの要望が多いという事実をみせるしかない。
（影響力の大きそうな）ブラウザベンダーに「この機能いれてよ」と要望する。要望の数が多ければベンダーは実装する。



居酒屋談義（その後懇親会での雑談）

考え方として、こういったオープンな規格の策定というのに、積極的に関わって（お金をだして）規格が標準になった後で、それまで得たノウハウその他を自社の強みとして商売に活かすというのが最近の主流なんだけど、日本ではこういったことに対して積極的に投資しようという企業が少ない。
CSS Ruby Module、ルビ機能についても、ずっと支援してやってる会社があるのだけど、さすがに一社だけでやり続けるのは厳しい。
CSSの規格はEPUBなど電子書籍の表示にも使われる物なのだし、印刷会社や出版社のような組版に関連するところが出してくれるといいのだけど。



【感想】
こういった規格というのはなんとなく「どこか雲の上で決まっている」というように感じがちなのだけど、実際はかなり身近なところで決まっていて、参加しようと思えば誰でも参加できるということ、さらに「実装ありき」というかなり厳しい条件によってきまるのだという話。これはかなり面白かった。

「実装にはお金が必要」という話に生々しい具体的な金額も。うーん、なるほど雲の上とかいっても、規格を決める人だって霞を食って生きているわけではないのだ。
とりあえずWriting Modesその他の実装のために5千万円ぐらいだしてくれる企業を募集中のようです。
その後居酒屋での雑談のなかで「5千万ぐらいいるらしいです」「そのくらいの額でできるなら安いもんじゃないか」と頼もしい発言もでていたので、ぜひ期待したいところ。

実際CSSのこの辺の仕様は今後電子書籍の規格などに重要な部分なので、今のうちから資金を出して情報を蓄積しておくというのはいいのではないか。


でかい印刷事故一発だせばこのくらいの金額はいっちゃうと思えば、安いもんだよ！