ブログトップ 記事一覧 ログイン 無料ブログ開設

ちくちく日記 このページをアンテナに追加 RSSフィード Twitter

2016-06-16

【小ネタ】スクリプトエディタ.appに画像が表示できる


スクリプトエディタ.appの編集の「説明を表示」欄に、画像がドロップ表示できることに気がついた。


f:id:akane_neko:20160616113042p:image

▲「説明」欄に画像をドロップ

f:id:akane_neko:20160616113044p:image:w400

▲表示される

さらに選択して「マークアップ」で編集画面が出てくる。

f:id:akane_neko:20160616113045p:image:w400

▲マークアップ

f:id:akane_neko:20160616113043p:image:w400

▲編集できる

しかし保存して開くと「?」になって消えてしまうし、なんの為の機能なんだかさっぱりわからない。

f:id:akane_neko:20160616113046p:image:w400

▲消えてる




「みなさんこんにちは!ちくわです!ちくわです!ちくわです!」

── こんにちわ!「ちくちく日記」です!…ってちょっと勝手に出張らないでよ。

「すいません、あまりにも久しぶりすぎて!」

── 前回登場してから1年ちょいぶりぐらいか…っていうか、別に今回は呼んでないよ。なんで出てきてんの。

「いやだって、僕のブロマイドが使われてますし!困るなー、ちゃんと事務所通してもらわないと」

── 事務所ってどこだよ。紀文かニッスイか。

「というか、なんですか今回のネタは。こんなのわざわざブログに書かなくてもTwitterでつぶやいときゃいいんじゃないですか」

── まぁそうなんだけどね。でもしばらく更新してないからたまには更新しとこうかなって。

「ああ、あんまり更新してないと『もうちくわ出さないんですか?』ってきかれますもんね」

── ちくわ情報ブログじゃねーよ

「それでとりあえず、どうでもいい小ネタで更新、と」

── 正直、Twitterでつぶやくんなら数分で終わるのに、ブログに起こすとなると、文章打つのも時間かかるし、画像加工も時間かかるし、ちくわが出張ってくるし途中で「なにやってんだかな」って思ったな。

「人生の無駄遣いですね」

── だけど、こういうどうでもいいネタなら炎上もお叱りもないからな!みんな、こんな不真面目なブログみて真面目に怒ってちゃ時間の無駄だぜ!見んなよ!

「そういう言い方するから叱られるんだと思います!」


これからもやる気ない感じで不真面目にやっていきたいと思います!

2016-03-25

TypekitのDTP利用には注意が必要

Adobe CCのTypekitについて、jdashさんのサイトで取り上げられてました

忘れていませんか?Creative Cloudで使える日本語フォントは、なんと80種類!《フォント名のリスト・イメージ付》


Adobe CCのTypekitで日本語がいっぱい使えるから使おうよー!っていう話題です。


…うん、いいんだけど、うん…困る…。


Adobe CCのTypekitについてチョット困ったことになったなーってのは以前、サービス開始のニュースが出た頃にTwitterの方でつぶやいたりしてたんだけど、まぁまだそんなに入稿ないし、今回困るっていうのはかなり内部的な問題だしなぁと放置してた。

モリサワ モリサワグループ書体をAdobe Creative CloudのTypekitに提供開始モリサワおよびタイプバンクの20書体

▲モリサワTypeKit対応のニュースにうろたえる私

でも、こういう風に話題になると「お?使ってみようかな?」って人も増えるかもしれないので、やっぱりちゃんと注意を書いておこうと思う。


TypeKitが(DTP的に)やばい理由

まず、これは印刷会社の内部的な事情ではあるんだけど、印刷会社によってはAdobe CCを外部ネットワークに繋げない形で使ってます。

つまり、Adobe CCをエンタープライズ契約でカスタム契約すると、ネットワークに繋がない状態で使えるAdobe CCというものが手に入るんですね。

そういう状態でAdobe CCを使っている印刷会社がどのぐらいあるのかっていうのは、私にはわからないけど、多分ある程度以上のライセンス契約数がある規模の印刷会社はみんなやってるんじゃないかと想像。(あと、ライセンス契約数の少ない中小規模の印刷会社でも、なんか印刷連合?組合?みたいなのを通して共同購入することでエンタープライズ契約Adobe CCを手に入れてるという話も聞いたことある)

で、この外部ネットワークに繋がないAdobe CCだとTypekitは使えません。

そして、TypeKitで使われたフォント、作成側でInDesignのパッケージ機能をつかってもそのフォントは収集されません。

ネットワーク越しに使ったフォントはローカルに落とすことができないわけです。

なので、あなたがTypeKitを使ったデータを入稿する時、そこにフォントは付属しません。(PDFで埋め込みしている場合を除く)

Typekitのフォントはパッケージでの収集がされないので、Typekitのフォントを使って作られたデータが入稿しても、印刷会社側ではTypekitが使えず、そのフォントがない!って状態になります。

もちろん、Typekitが使えなくても、印刷会社のマシンローカル側にそのフォントが入っていればいいのだけど、実はそんなに簡単じゃない。


Typekitのなかでもやばいフォント

Typekitには今回対応したモリサワフォントを始め、たくさんのフォントがあるわけだけど、そのなかでも、DTPで使っていいフォント、使わないほうがいいフォントがある。

これを「使わないほうがいいランキング」的に表示すると

1位 欧文フォント

2位 Adobeの日本語フォント

3位 タイプバンクフォント

4位 モリサワフォント

って感じではなかろうか。


4位 モリサワフォント

Typekitのモリサワフォントに関しては、ほとんどの印刷会社がPASSPORT対応している(つまりローカル側にフォントを持ってる)だろうし、今回対応したフォントもごく一般的な基本書体のみなので、使用してもまず問題にならないと思われます。


3位 タイプバンクフォント

タイプバンクフォントは同じくPASSPORTで提供されているフォントだけど、タイプバンクPASSPORTは別契約になるので、もっていない印刷会社も多そう。


2位 Adobeの日本語フォント

Adobeはりょう、かづらきはPASSPORTなどに入っていないフォントなので別途購入、源の角ゴシックはダウンロードする必要があります。

しれっと混ざっている源ノ角ゴシック、実は一般的なDTPフォントの規格であるAdobe-Japan1との互換がないので、うっかり切り替えて字形が変わったりする可能性があるのも要注意。


1位 欧文フォント

堂々の1位は欧文フォント!

TypeKitでは日本語フォント以上にたくさんの欧文フォントが用意されています。

「すごい!使いたい!」って思う人多いでしょう。

でも、TypeKitに登録されているフォント(多分あえてそうしてあるのだと思うのだけど)市販の欧文フォントパッケージAdobeFontFolioなどには含まれていない新しいフォントが大半なんです。

つまりTypeKitの欧文フォントを全てローカルに持とうと思ったら、一つ一つ欧文フォントを買い集める必要があります…。

これ、日本語フォントなんかよりよっぽどお金かかります!無理!全部買うとか無理!


ネットワークに繋げない理由

「いや、そんなん印刷会社がネットワークにつなげてTypeKit使えばいいやん」

というか、TypeKitはユーザーIDでの利用が前提だから、ユーザーIDのないネットワーク認証しないCCだと使えないって事なんですけど、そもそも何故、外のネットワークに繋いでいないのか。繋ぐとセキュリティ上問題があるからですね。

印刷会社が扱う印刷物の中には超マル秘重要データもありますし、出力現場に繋がっている出力機なんかも下手に外に繋いでウイルスなどにやられたら洒落にならない。そもそも印刷データを作るだけなら外に繋がっている必要ない。だから繋いでいないのです。

TypeKitのためだけにそこに穴をあけるというのはかなり難しい話です。(もちろんTypeKit用にネットワークを別にしたマシンを用意するとかそういう方法はあるでしょうけど…)



TypeKitの使い方

「じゃあせっかくTypeKitあるのに使えないの?」

そんなことはないです。

まず「うちはTypeKit使えないよ、困った!」っていうのは印刷会社の中でも特別な事情があるところだけであるということ。

なのでまず、ご利用の印刷会社に「TypeKit使って大丈夫ですか?」と問い合わせてください。「もちろんOK!」っていう印刷会社だってたくさんあると思います。(むしろ上記理由から大手であればあるほど使えないような気がします…)

「うちでは使えません!」と返答された場合、PDFに埋め込んで入稿するという手があります。

この場合、修正その他印刷会社では一切行わない完全データとして入稿するという条件になります。

もしPDF入稿もできないとなったら最終手段は「アウトラインとる」ですね。

図形にしちゃえば無問題!TypeKitも使い放題です。


いつか解消するのか?

せっかくのTypeKitサービス、使えない状態なのはもったいない…いつかこの状況が解消することはあるのでしょうか?

解決方法の一つとしてはAdobeがTypeKitフォントのパッケージ収集を許可してくれることですが、どうやらTypeKitのフォントがローカルにコピーできないのはTypeKitにフォントを提供しているメーカーとのライセンス契約の縛りによるものらしくこの状況が解消されるのは難しそうです。

では印刷会社側がAdobe CCを外部ネットワークに繋いだ環境を用意するか?

今後Adobe CCでTypeKitを使った入稿がすっごく増えたら可能性はある…かもしれません。が、現状AdobeCCの入稿ってまだまだ少ないので印刷会社が対策するには時間がかかりそうな気がします。

スマートな解決としてはPDFの完全データ入稿(フォント埋め込み)に移行するっていうのが一番なんですが、何年も前からこうなってほしいと願っている、この解決策が上二つの解決策よりはるかに難しい気がするのはなんでなんだろうな!


まぁ今回の話は自分でもどうかなと思うぐらい「そんなん印刷会社の都合やろ」って話なんで「こんな事情なんっすよねー…そのへん汲んでもらえませんかねー(へこへこ)」って低姿勢でお願いするよ!

でも「わしが金払うたシステム全部つこうて何が悪いんや!金ならあるんや!出してみせんかい!」ってお客様に札束で顔はたかれたらもうすぐにでも環境整えて対応すると思いますんで、

札束でぶってくれるようなお客様、お待ちしております!

2015-08-07

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

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


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

f:id:akane_neko:20150807173642p:image:w500

f:id:akane_neko:20150807173641p:image:w500

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

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

別に引用して紹介してあるだけなら腹は立たなかったのだけど、このまとめ「出典」とかかいてあるけど、該当のURLははっておらず、こちらのサイト名もかいてない。

画像も勝手につかってるし、私の趣旨とは違う使い方してある。

私はこのブログの画像はすべて「表示-非営利-改変禁止:原著作者の氏名を表示し、非営利で、改変をしない場合に限り、誰でも自由に使用できます。頒布することもできます。」という設定にしてある。なので「原著作者の氏名を表示」していないこのまとめはライセンス違反。

f:id:akane_neko:20150807173640p:image


ということで、とれる限りの対処法をとってみました!

同じようにNAVERまとめにパクられてしまった人の参考に手順をまとめておきます


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

まずは該当サービスであるNAVERまとめに「私の著作権が侵害されてます!」と申告しましょう。

権利侵害申告はNAVERの「お問い合わせ窓口」から行います


NAVER お問い合わせ窓口 

f:id:akane_neko:20150807174058p:image

申告手順

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

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

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

まとめ内で、私のブログの記事と画像が勝手に使われています。

出典とかいてありますが、引用先のURLはなく、引用先名も正確なものではありません。

私の記事の趣旨と違う形で画像やテキストをつかわれており、私の著作権を侵害しています。

勝手に利用された画像

<勝手に利用された画像のURL>

勝手に利用されたテキスト

<勝手に利用されたテキスト>

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

これで送信。

NAVERからの返信はすぐに来ました

以下返信メールから抜粋。

NAVERをご利用いただき、誠にありがとうございます。

NAVERヘルプセンターです。

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

このたびは、弊社ユーザーがご迷惑をお掛けすることとなり、

申し訳ございません。

大変恐縮ではございますが、お客さまがブログ権利者様であることの

確認をいたしたく、下記内容についてご対応、

ご連絡いただけますようお願い申し上げます。

1.対象まとめ内の画像が掲載されているお客さまブログ記事内

 http://d.hatena.ne.jp/akane_neko/20130828/1377642076

 こちらにNAVERまとめへの転載を禁止する以下の文面の

 記載を追加お願いいたします。

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

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

すぐに対応し、返信したところ

ご連絡いただいた内容につきまして調査させていただき

該当の投稿に対し、公開制限措置を行いましたので、

お手数ではございますがご確認いただけますよう、お願い申し上げます。


おお、対応早いぞNAVER!

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

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

f:id:akane_neko:20150807180507p:image

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

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



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

そもそも私がこのまとめに気がついたのは、あるキーワードでGoogle検索したときに、私のページが表示されたすぐ下にこのまとめサイトがきていたから。

まだかろうじて私の方が検索上位にいるが、こんなのに並ばれるのは腹が立つ。

ということで、Googleさんにも「検索結果からこのまとめを取り除いて頂戴」と削除申し立てをしました。


Google 著作権侵害による削除 

f:id:akane_neko:20150807174411p:image

申し立て手順

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

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

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

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

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

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

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

これで送信!

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


相手を呪う

こういう風に自分の書いたものがぱくられたのを見つけてしまったのは初めてだけど、実に嫌なものですね。

特に腹が立ったのは、引用先のURLもなく、サイト名もまともに表示してないかった事。あれがちゃんと引用先としてこちらのURLが記載されているものだったら、むしろ紹介してくれたことをうれしく感じたかもしれません。

NAVERやGoogleに削除申請はしましたが、NAVERでは自分のコンテンツ部分のみの削除で該当まとめ自体は削除されませんし、Googleもいつ削除されるかわかりません。

勝手にコンテンツを使われた自分としてはどうにも腹の虫が治まらないものがあります。

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




う ん こ も れ ろ!!!!!




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

2015-08-05

LETS FontACE3.2.0がコレジャナイ

「LETS POWER UP TOOL KIT 2015→2016」が届きましたよ!

今年のPUTKではフォント管理ツール「LETS FontACE」がv3.2.0にバージョンアップって情報を聞いていたので楽しみにしてたのだ。

とくに楽しみにしてたのはここ。

f:id:akane_neko:20150804164054p:image

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

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

さらに。

f:id:akane_neko:20150804164055p:image

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


おおーーーーー!これこれ!欲しかった機能だよーーー!

これ、Linotype FontExplorerとかだと当然のようにできるんだよねー。

外部フォルダでフォント管理してると、フォルダ分けしたフォントをいちいち選択して登録するなんてめんどくさいから、一括登録できるのはすごくありがたい。



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

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

f:id:akane_neko:20150804164056p:image:w400

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

f:id:akane_neko:20150804164058p:image

f:id:akane_neko:20150804164057p:image

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


…あれっ…?


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

f:id:akane_neko:20150804164100p:image

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


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

f:id:akane_neko:20150804164101p:image

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


…えっ…?


f:id:akane_neko:20150804164059p:image





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

でもさ、でもさ!どうして別々のフォルダをドロップしたのに一緒くたにまとめて「ユーザー管理:外部」に入れちゃうの!!!!

これだと、せっかくフォルダ分けしてたのがごちゃ混ぜじゃんか!

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


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


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

今の仕様じゃ、わざわざフォルダ分けしたフォントをドロップして、そのあと全部一緒に突っ込まれてしまったフォントをもう一度フォントグループで分類する、ってことになるんだよ!

前にFontACEについて書いたときにも言ったけど(LETS FontACE その2)、登録されたフォントから一個一個選んでフォントグループを作るの、すごくめんどくさいんだよ!そんなめんどくさいことやってられっか!!!!!

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

f:id:akane_neko:20150804164103p:image

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


3.2.0の他の機能

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

3.2.0では外部フォント管理以外に、重複フォントの検知ができるようになってます。

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

f:id:akane_neko:20150804170501p:image

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

でも、でもさぁ。

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

f:id:akane_neko:20150804170502p:image

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


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

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

f:id:akane_neko:20150804173141p:image

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

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

f:id:akane_neko:20150804173248p:image

▲どっちをイキにするか聞いて欲しい…

そもそも登録したら同時にオンにするのも余計なお世話な気がする…。




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

久しぶりにLETS FontACEを使ってみた。外部フォルダのフォントを管理できるようになったり、ドラッグ&ドロップで登録できたり、いい方向に進化はしてるんだけど、使い勝手を考えるとあと一歩足りない!

結局今の機能じゃ、おまけツールという位置付けから抜け出せず、ガチでフォント管理したい人には向いてない。

とりあえず感想は

f:id:akane_neko:20150804173420p:image:w200

って感じかな。

がんばれFontACE!

2015-08-03

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/)を見た方がわかるので概要だけまとめ。