「ブログから」って、どう訳せばいいのか?
とりあえず、前置詞EXを使って、BLOGの語尾を奪格風にしてみた。もちろん似非羅甸語に違いない。
20:15 追記:logos -i に倣って語尾を修正しました。
2011年10月23日
Lionのテキスト読み上げ:そこの君、ちょっと読んでくれない?
Lionのテキスト読み上げは多国語対応になったんだけど、読み上げさせる言語を自動的に切り替えてはくれません。
環境設定の「スピーチ」でそれぞれの言語をしゃべってくれる「声」を切り替えないといけないんだけど、いちいち環境設定を起動するのはけっこう面倒。
そこで、Automatorでこんなサービスをつくって、「声を指定して読み上げる」とでも名前を付けて保存しておくといいかも。
「実行時にこのアクションを表示」にチェックをいれておくのがミソ。
これで、テキストを扱えるアプリケーションで読み上げさせたい部分を選択して、アプリメニューからこのサービスを呼び出せばよし。
でも、Lionの「声」は言語によって出来不出来の差がけっこうありますね。日本語担当のkyokoさんは、なんだか懐かしい感じがしますよ^^
環境設定の「スピーチ」でそれぞれの言語をしゃべってくれる「声」を切り替えないといけないんだけど、いちいち環境設定を起動するのはけっこう面倒。
そこで、Automatorでこんなサービスをつくって、「声を指定して読み上げる」とでも名前を付けて保存しておくといいかも。
「実行時にこのアクションを表示」にチェックをいれておくのがミソ。
これで、テキストを扱えるアプリケーションで読み上げさせたい部分を選択して、アプリメニューからこのサービスを呼び出せばよし。
でも、Lionの「声」は言語によって出来不出来の差がけっこうありますね。日本語担当のkyokoさんは、なんだか懐かしい感じがしますよ^^
2011年10月20日
不可視旗:母さん、僕のあのファイルどうしたでせうね
他のOSでつくったZipなどアーカイブファイルをMacで展開すると、展開は成功しているらしいのに、Finderではファイルが見つけられないことが、ままあります(「一太郎Ark」のパッケージでそんなことがありました)。
Terminalでls を実行すると目当てのファイルが見つかる場合、そのファイルにhiddenフラグがついているのです(もとのOSでは別の役割を果たしていたんでしょうけど)。
そのhiddenフラグを取るには、
Terminalでls を実行すると目当てのファイルが見つかる場合、そのファイルにhiddenフラグがついているのです(もとのOSでは別の役割を果たしていたんでしょうけど)。
そのhiddenフラグを取るには、
chflags nohidden ファイル名とすればOKです。直ちにFinderにそのファイルが現れますよ。
2011年9月27日
2011年9月21日
モールス符号
つまらないsedスクリプトをふたつ…
k2m.sed
m2k.sed
GNU Sedで動きます。
k2m.sed
#!/usr/local/bin/sed -f y/いろはにほへとちりぬるをわかよたれそつねならむうゐのおくやまけふこえてあさきゆめみしゑひもせすん/イロハニホヘトチリヌルヲワカヨタレソツネナラムウヰノオクヤマケフコエテアサキユメミシヱヒモセスン/ y/ぁぃぅぇぉっゃゅょ/アイウエオツヤユヨ/ y/ァィゥェォッャュョ/アイウエオツヤユヨ/ y/がぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ/ガギグゲゴザジズゼゾダヂヅデドバビブベボパピプペポ/ s/ガ/カ゛/g s/ギ/キ゛/g s/グ/ク゛/g s/ゲ/ケ゛/g s/ゴ/コ゛/g s/ザ/サ゛/g s/ジ/シ゛/g s/ズ/ス゛/g s/ゼ/セ゛/g s/ゾ/ソ゛/g s/ダ/タ゛/g s/ヂ/チ゛/g s/ヅ/ツ゛/g s/デ/テ゛/g s/ド/ト゛/g s/バ/ハ゛/g s/ビ/ヒ゛/g s/ブ/フ゛/g s/ベ/ヘ゛/g s/ボ/ホ゛/g s/パ/ハ゜/g s/ピ/ヒ゜/g s/プ/フ゜/g s/ペ/ヘ゜/g s/ポ/ホ゜/g s/イ/・- /g s/ロ/・-・- /g s/ハ/-・・・ /g s/ニ/-・-・ /g s/ホ/-・・ /g s/ヘ/・ /g s/ト/・・-・・ /g s/チ/・・-・ /g s/リ/--・ /g s/ヌ/・・・・ /g s/ル/-・--・ /g s/ヲ/・--- /g s/ワ/-・- /g s/カ/・-・・ /g s/ヨ/-- /g s/タ/-・ /g s/レ/--- /g s/ソ/---・ /g s/ツ/・--・ /g s/ネ/--・- /g s/ナ/・-・ /g s/ラ/・・・ /g s/ム/- /g s/ウ/・・- /g s/ヰ/・-・・- /g s/ノ/・・-- /g s/オ/・-・・・ /g s/ク/・・・- /g s/ヤ/・-- /g s/マ/-・・- /g s/ケ/-・-- /g s/フ/--・・ /g s/コ/---- /g s/エ/-・--- /g s/テ/・-・-- /g s/ア/--・-- /g s/サ/-・-・- /g s/キ/-・-・・ /g s/ユ/-・・-- /g s/メ/-・・・- /g s/ミ/・・-・- /g s/シ/--・-・ /g s/ヱ/・--・・ /g s/ヒ/--・・- /g s/モ/-・・-・ /g s/セ/・---・ /g s/ス/---・- /g s/ン/・-・-・ /g s/゛/・・ /g s/濁点/・・ /g s/゜/・・--・ /g s/半濁点/・・--・ /g s/ー/・--・- /g s/、/・-・-・- /g s/」/・-・-・・ /g s/(/-・--・- /g s/)/・-・・-・ /g s/本文/-・・--- /g s/訂正/・・・-・ /g s/終了/・・・-・ /g
m2k.sed
#!/usr/local/bin/sed -f s/ / /g s/-・--・- /(/g s/・-・-・- /、/g s/・-・-・・ /」/g s/・-・・-・ /)/g s/---・- /ス/g s/--・-- /ア/g s/--・-・ /シ/g s/--・・- /ヒ/g s/-・--- /エ/g s/-・--・ /ル/g s/-・-・- /サ/g s/-・-・・ /キ/g s/-・・-- /ユ/g s/-・・-・ /モ/g s/-・・・- /メ/g s/・---・ /セ/g s/・--・- /ー/g s/・--・・ /ヱ/g s/・-・-- /テ/g s/・-・-・ /ン/g s/・-・・- /ヰ/g s/・-・・・ /オ/g s/・・--・ /゜/g s/・・-・- /ミ/g s/・・-・・ /ト/g s/---- /コ/g s/---・ /ソ/g s/--・- /ネ/g s/--・・ /フ/g s/-・-- /ケ/g s/-・-・ /ニ/g s/-・・- /マ/g s/-・・・ /ハ/g s/・--- /ヲ/g s/・--・ /ツ/g s/・-・- /ロ/g s/・-・・ /カ/g s/・・-- /ノ/g s/・・-・ /チ/g s/・・・- /ク/g s/・・・・ /ヌ/g s/--- /レ/g s/--・ /リ/g s/-・- /ワ/g s/-・・ /ホ/g s/・-- /ヤ/g s/・-・ /ナ/g s/・・- /ウ/g s/・・・ /ラ/g s/-- /ヨ/g s/-・ /タ/g s/・- /イ/g s/・・ /゛/g s/- /ム/g s/・ /ヘ/g s/カ゛/ガ/g s/キ゛/ギ/g s/ク゛/グ/g s/ケ゛/ゲ/g s/コ゛/ゴ/g s/サ゛/ザ/g s/シ゛/ジ/g s/ス゛/ズ/g s/セ゛/ゼ/g s/ソ゛/ゾ/g s/タ゛/ダ/g s/チ゛/ヂ/g s/ツ゛/ヅ/g s/テ゛/デ/g s/ト゛/ド/g s/ハ゛/バ/g s/ヒ゛/ビ/g s/フ゛/ブ/g s/ヘ゛/ベ/g s/ホ゛/ボ/g s/ハ゜/パ/g s/ヒ゜/ピ/g s/フ゜/プ/g s/ヘ゜/ペ/g s/ホ゜/ポ/g y/イロハニホヘトチリヌルヲワカヨタレソツネナラムウヰノオクヤマケフコエテアサキユメミシヱヒモセスン/いろはにほへとちりぬるをわかよたれそつねならむうゐのおくやまけふこえてあさきゆめみしゑひもせすん/ y/ガギグゲゴザジズゼゾダヂヅデドバビブベボパピプペポ/がぎぐげござじずぜぞだぢづでどばびぶべぼぱぴぷぺぽ/
GNU Sedで動きます。
2011年6月23日
OpenTypeフォントって組版情報てんこ盛り
大阪DTPの勉強部屋主催の「InDesign組版教室」を受講しはじめました。
大石十三夫さんのよい組版への蘊蓄とこだわりがたっぷりの講義がとても面白いのです。(http://www.osakadtp.com/)
その第1回(6/17)はAdobe Illustratorの文字組版の不自由さが検討されたのですが、その中に、サイズが異なる文字を1行に混植する場合などで、個々のフォントの欧文ベースラインが分からないと、文字の並び具合や行間をきれいに揃えられないという話がでてきました。
大石さんのblog『なんでやねんDTP』だとこのあたりの話:
http://d.hatena.ne.jp/works014/20110623
そこで、欧文ベースライン位置を調べる方法をちょいと調べてみました。
フォントの仕様書を読む
まずは、OpenTypeフォントの仕様を勉強。仕様書の在処はもちろん、開発元Microsoft社です;
『OpenType specification』
http://www.microsoft.com/typography/otspec/
うわっ、といいたいぐらい、OpenTypeフォントには組版のための情報が盛り込まれてますね。
他の情報はおいおい勉強することにして、まずは、ベースラインについての項目は?と探してみると、「BASE表」あたりのようです。
「BASE - Baseline Table」
http://www.microsoft.com/typography/otspec/BASE.htm
「Baseline tags」
http://www.microsoft.com/typography/otspec/baselinetags.htm
これらをフォントファイルから読み出せばいい訳です。実際、InDesignにしてもIllustratorにしてもこうした組版情報をフォントから読み出して文字を並べているのです。人間にできない訳はありません。
たしかに、フォントファイルをxxdやhexdumpで16進ダンプして、仕様書と首っ引きで、読んでいけば読めます。
AFDKOTのインストール
でも、もっと楽な方法はないのか? いろいろ試してみたところ、Adobe提供のフォント開発ツールに含まれているものが使い易そうです。Mac・Windows両版が用意されています。
「Adobe Font Development Kit for OpenType」
http://www.adobe.com/devnet/opentype/afdko.html
インストールは、配布物をunzipして出てきた「FDK」フォルダを適当な場所(恒常的に置いておける場所:私は自分のホームディレクトリ下のライブラリフォルダに置きました)に移動して、フォルダ中のシェルスクリプトFinishInstallOSXをTerminalにドロップして実行するだけ。FDKフォルダへのリンクが~/bin/内に作られ、シェルの設定ファイルに必要な環境変数設定が追加記入されます。詳しくは、Read_Me_First.htmlに書いてあります。
spotコマンドをつかってBASE表を読み出し
AFDKOはフォントをつくるためのキットなので、こちらにも沢山の機能・コマンドが入ってます。
組版のための情報はその中の「spot」コマンドで読み出せます。Terminal上での操作になります。
使用法は「-h」オプションで表示されます。
BASE表を表示するには、オプションを「-tBASE=5」とすると見やすい表になります。(実行結果は左の図の前半)
ところが、OpenTypeフォントでもBASE表をもたないものがあります。例えばダイナフォントの平成明朝など。
そういうフォントの場合、ベースライン位置についてはHHEAD表に記載されています。それを表示するにはオプションを「-thhea」とします。
descenderとascenderが分かります。
なお、縦組みの場合のベースライン位置などもBASE表に記載されています。しかし、縦組みの場合、たいていは「仮想ボディの中央揃え」でしょうから欧文ベースライン位置は欧文混植の場合以外は問題になることは少ないと思います。spotコマンドの出力には縦組の場合も出ていますがご参考まで。
大石十三夫さんのよい組版への蘊蓄とこだわりがたっぷりの講義がとても面白いのです。(http://www.osakadtp.com/)
その第1回(6/17)はAdobe Illustratorの文字組版の不自由さが検討されたのですが、その中に、サイズが異なる文字を1行に混植する場合などで、個々のフォントの欧文ベースラインが分からないと、文字の並び具合や行間をきれいに揃えられないという話がでてきました。
大石さんのblog『なんでやねんDTP』だとこのあたりの話:
http://d.hatena.ne.jp/works014/20110623
そこで、欧文ベースライン位置を調べる方法をちょいと調べてみました。
フォントの仕様書を読む
まずは、OpenTypeフォントの仕様を勉強。仕様書の在処はもちろん、開発元Microsoft社です;
『OpenType specification』
http://www.microsoft.com/typography/otspec/
うわっ、といいたいぐらい、OpenTypeフォントには組版のための情報が盛り込まれてますね。
他の情報はおいおい勉強することにして、まずは、ベースラインについての項目は?と探してみると、「BASE表」あたりのようです。
「BASE - Baseline Table」
http://www.microsoft.com/typography/otspec/BASE.htm
「Baseline tags」
http://www.microsoft.com/typography/otspec/baselinetags.htm
- ideo:
- これが欧文ベースライン位置を示すもの。ベースラインから仮想ボディの地(下辺)までの距離で示してあります(単位は1/1000)。
- icfb:
- 平均字面の地の位置。
- icft:
- 平均字面の天の位置。
これらをフォントファイルから読み出せばいい訳です。実際、InDesignにしてもIllustratorにしてもこうした組版情報をフォントから読み出して文字を並べているのです。人間にできない訳はありません。
たしかに、フォントファイルをxxdやhexdumpで16進ダンプして、仕様書と首っ引きで、読んでいけば読めます。
AFDKOTのインストール
でも、もっと楽な方法はないのか? いろいろ試してみたところ、Adobe提供のフォント開発ツールに含まれているものが使い易そうです。Mac・Windows両版が用意されています。
「Adobe Font Development Kit for OpenType」
http://www.adobe.com/devnet/opentype/afdko.html
インストールは、配布物をunzipして出てきた「FDK」フォルダを適当な場所(恒常的に置いておける場所:私は自分のホームディレクトリ下のライブラリフォルダに置きました)に移動して、フォルダ中のシェルスクリプトFinishInstallOSXをTerminalにドロップして実行するだけ。FDKフォルダへのリンクが~/bin/内に作られ、シェルの設定ファイルに必要な環境変数設定が追加記入されます。詳しくは、Read_Me_First.htmlに書いてあります。
spotコマンドをつかってBASE表を読み出し
AFDKOはフォントをつくるためのキットなので、こちらにも沢山の機能・コマンドが入ってます。
組版のための情報はその中の「spot」コマンドで読み出せます。Terminal上での操作になります。
使用法は「-h」オプションで表示されます。
moria: tac$ spot -h Usage: spot [-u|-h|-ht|-r] [-n|-nc|-G|-T|-F] [-f] [-V] [-m] [-d][-i] [-o ] [-t |-P ] [-p ] [-@ ] + OR: spot -X Options: -u print usage information -h print usage and help information -ht print table-specific usage information -r dump Macintosh resource map -n dump glyph id/name mapping (also see '-m' below) -nc dump glyph id/name mapping, one per line (also see '-m' below) -T list table-directory in sfnt table -F list features in GPOS,GSUB tables -G proof glyph synopsis -f proof GPOS features in font order instead of GID order -V proof glyphs in Vertical writing mode (same as -p6 below) -m map glyph names into Adobe 'friendly' names, not AGL/Unicode names -d suppress header info from proof -br proof glyph synopsis one per page -i sfnt resource id list (see help) -o TTC directory offsets list (see help) -t table dump list (see help) -P , e.g 'P cswh,frac,kern' (use '-Proof' for all) -p set proofing policies: 1=No glyph name labels 2=No glyph numeric labels 4=Show KanjiStandardEMbox on glyph 5=Show GlyphBBox on glyph 6=Show Kanji in Vertical writing mode 7=Don't show Kanji 'kern','vkrn' with 'palt','vpal' values applied -@ set proofing glyph point-size (does not apply to certain synopses) -X execute a series of complete command-lines from
[default: OTFproof.scr ]
BASE表を表示するには、オプションを「-tBASE=5」とすると見やすい表になります。(実行結果は左の図の前半)
moria: tac$ spot -tBASE=5 KozMinPro-Regular.otf
BASE表を持たないフォントところが、OpenTypeフォントでもBASE表をもたないものがあります。例えばダイナフォントの平成明朝など。
そういうフォントの場合、ベースライン位置についてはHHEAD表に記載されています。それを表示するにはオプションを「-thhea」とします。
moria: tac$ spot -thhea DFHSMinchoStd-W3.otf
descenderとascenderが分かります。
なお、縦組みの場合のベースライン位置などもBASE表に記載されています。しかし、縦組みの場合、たいていは「仮想ボディの中央揃え」でしょうから欧文ベースライン位置は欧文混植の場合以外は問題になることは少ないと思います。spotコマンドの出力には縦組の場合も出ていますがご参考まで。
2011年6月14日
複数のテキストフレームをひとつずつ別文書にコピー
わたしがつくっている新聞では「新年あいさつ」と「暑中見舞い」、年2回の名刺広告を掲載してます。
1枠の料金は年間購読料よりも高く、全体でけっこうな収入になるのですが、募集事務の手間がたいへんなのです。かつては編集部に4人もいて、財政部門も手伝ってくれていたのですが、ここ10年ぐらいはわたしひとりで作業をしています。
CS2なので複数文書の取り扱いに不便なところがあります。CS2ではcopy()とpaste()でしか文書間のコピー&ペーストができないようなのです。しかも、copy()とpaste()は前面のlayoutWindowにしか作用しない。
そこでlayoutWindowを切り替えてやらねばならないのですが、その際、documents[0]とdocuments[1]とが指し示す文書まで入れ替わってしまいます(そのためオブジェクト名の表記を変数をもちいて簡略化できません)。
CS4だとduplicateでコピー元やペースト先が明確に指示できるし、layaoutWindowを切り替える必要もないので、もっと楽にできそうです。
とりあえず動くようになったスクリプトはこんな具合です(エラー処理その他は未実装)。
1枠の料金は年間購読料よりも高く、全体でけっこうな収入になるのですが、募集事務の手間がたいへんなのです。かつては編集部に4人もいて、財政部門も手伝ってくれていたのですが、ここ10年ぐらいはわたしひとりで作業をしています。
- 前回の降版データから、個々の名刺広告(ひとつひとつがテキストフレームに入っています)をコピーし、
- 1枚の募集要綱にひとつずつペースト(内容の確認や今回の掲載に向けての変更を広告主にしてもらうためです)、
- 広告主を照合しながら、募集要綱を宛名ラベルを貼った封筒に詰めて発送しています。
CS2なので複数文書の取り扱いに不便なところがあります。CS2ではcopy()とpaste()でしか文書間のコピー&ペーストができないようなのです。しかも、copy()とpaste()は前面のlayoutWindowにしか作用しない。
そこでlayoutWindowを切り替えてやらねばならないのですが、その際、documents[0]とdocuments[1]とが指し示す文書まで入れ替わってしまいます(そのためオブジェクト名の表記を変数をもちいて簡略化できません)。
CS4だとduplicateでコピー元やペースト先が明確に指示できるし、layaoutWindowを切り替える必要もないので、もっと楽にできそうです。
とりあえず動くようになったスクリプトはこんな具合です(エラー処理その他は未実装)。
var ohgumi = File.openDialog ("大組ゲラを開く");
app.open(ohgumi);
var kogumi = File.openDialog ("小組ゲラを開く");
app.open(kogumi);
/*document[1]は大組ゲラ*/
var numTF = app.documents[1].textFrames.length;
for (i=0; i<numTF; i++){
/*前面を大組ゲラに切り替え*/
app.layoutWindows[1].bringToFront();
app.select(NothingEnum.nothing);
/*documents[0]は大組ゲラ*/
app.documents[0].textFrames[i].select();
app.copy();
/*前面を小組ゲラに切り替え*/
app.layoutWindows[1].bringToFront();
app.paste();
app.select(NothingEnum.nothing);
/*documents[0]は小組ゲラ*/
app.documents[0].pages[i].textFrames[0].move(["0mm","0mm"]);
if (i<numTF-1){
/*documents[0]は小組ゲラ*/
app.documents[0].pages.add(1701733408);
}
}
2011年5月16日
こんにちわ、でいいのじゃ
「こんにちわ」という表記は“間違い”とまでは言えぬのではありませぬか。
1986年内閣告示の「現代仮名遣い」には、「こんにちは」が助詞「は」の表記例としてあげられていますが、46年の「現代かなづかい」は「こんにちは」の例をあげておりませぬ。
それどころか、86年に文部省が都道府県教育委員長などに通知した「学校教育における『現代仮名遣い』の取扱いについて」では、助詞「は」「へ」について、「現代かなづかい」では“「わ」「え」と書くことも許容すると解釈されてい”たことを(参考)にあげております。(同通知全文はこちら)
つまり、「現代仮名遣い」告示以前には、「コンニチワ」を一語ととらえる(「は」を助詞ととらえない)ならば、「現代かなづかい」の細則第四「ワに発音されるはは、わと書く」にしたがって「こんにちわ」と表記することもできたわけです。
戦後すぐに読み書きを習った少し年配の方が「こんにちわ」と書かれるのは自然なことかもしれませぬ。
もっとも、規定云々の前提として、「現代仮名遣い」は「個々人の表記にまで及ぼそうとするものではない」と適用範囲を限定しています(「常用漢字」も同様です)から、twitterやblogのように個人的な書き物について、“「こんにちわ」と書くのは間違いだ”と言うのは行き過ぎだと思うのであります。
1986年内閣告示の「現代仮名遣い」には、「こんにちは」が助詞「は」の表記例としてあげられていますが、46年の「現代かなづかい」は「こんにちは」の例をあげておりませぬ。
それどころか、86年に文部省が都道府県教育委員長などに通知した「学校教育における『現代仮名遣い』の取扱いについて」では、助詞「は」「へ」について、「現代かなづかい」では“「わ」「え」と書くことも許容すると解釈されてい”たことを(参考)にあげております。(同通知全文はこちら)
つまり、「現代仮名遣い」告示以前には、「コンニチワ」を一語ととらえる(「は」を助詞ととらえない)ならば、「現代かなづかい」の細則第四「ワに発音されるはは、わと書く」にしたがって「こんにちわ」と表記することもできたわけです。
戦後すぐに読み書きを習った少し年配の方が「こんにちわ」と書かれるのは自然なことかもしれませぬ。
もっとも、規定云々の前提として、「現代仮名遣い」は「個々人の表記にまで及ぼそうとするものではない」と適用範囲を限定しています(「常用漢字」も同様です)から、twitterやblogのように個人的な書き物について、“「こんにちわ」と書くのは間違いだ”と言うのは行き過ぎだと思うのであります。
2011年5月14日
EPUB ZIP コンテナの作り方
EPUBのファイル(コンテナ)は「.epub」という拡張子がついていますが、ファイルの構造としてはZIPアーカイブです。ですから、拡張子を「.zip」に書き換えれば、MacでもWindowsでも解凍(展開)して、本文などを普段使い慣れているテキストエディタで編集できます。
しかし、編集後、ZIPで圧縮(アーカイブ)して、拡張子を「.epub」に戻せばいいかというと、そうではないのです。mimetypeファイルの扱いが少し特別なのです。
要件1を満たすには
要件2を満たすには
→ zipコマンドに「-0」(ゼロです。圧縮率0という意味)をつければOK。
要件3を満たすには
→ zipコマンドに「-X」(大文字です)をつければOK。
たとえば、「De_Suse」というフォルダにmimetypeもふくめ必要なデータを入れておいて、
これで「De_Suse.epub」というEPUBファイルができます。なお、2行目の「-X」は大文字、3行目の「-x」(引数ファイルを除外するという意味のオプション)は小文字です。
なお、mimetypeの扱いについての詳細は「EPUB Open Container Format (OCF)」に規定されています。
EPUB 2.0.1
→http://idpf.org/epub/20/spec/OCF_2.0.1_draft.doc
EPUB 3
→http://idpf.org/epub/30/spec/epub30-ocf.htm
ほんとうに3要件を満たしているかは、hexdumpしてみれば分かります。
いったん、unzipしたものをMacの普通の“圧縮”でZIPして、拡張子を付け替えたもの(De_Suseフォルダの中身だけをZIPしたもの)だと、
ところが、場合によっては、Macの右クリックによる“圧縮”でつくったZIPファイルの拡張子を「.epub」に書き換えたものでも、Adobe Digital EditionsやSigilはEPUBとして読み出せますし、それをkindlegenで変換したMOBIファイルもKindleで普通に表示できます。
これは上のOCFによる3要件を一つも満たしていないのですが、なぜか大丈夫なのです。
しかし、編集後、ZIPで圧縮(アーカイブ)して、拡張子を「.epub」に戻せばいいかというと、そうではないのです。mimetypeファイルの扱いが少し特別なのです。
- 要件1: ZIPコンテナの先頭に置く
- 要件2: 圧縮も暗号化もしない
- 要件3: ヘッダにはextra fieldをつけない
要件1を満たすには
→ 最初にmimetypeファイルを単独でZIPアーカイブし、次に残りのディレクトリ・ファイルをそのZIPコンテナに追加すればOK。なんか、簡単^^
要件2を満たすには
→ zipコマンドに「-0」(ゼロです。圧縮率0という意味)をつければOK。
要件3を満たすには
→ zipコマンドに「-X」(大文字です)をつければOK。
たとえば、「De_Suse」というフォルダにmimetypeもふくめ必要なデータを入れておいて、
$ cd De_Suse
$ zip -0 -X ../De_Suse.epub mimetype
$ zip -r ../De_Suse.epub * -x mimetype
$ cd ..これで「De_Suse.epub」というEPUBファイルができます。なお、2行目の「-X」は大文字、3行目の「-x」(引数ファイルを除外するという意味のオプション)は小文字です。
なお、mimetypeの扱いについての詳細は「EPUB Open Container Format (OCF)」に規定されています。
EPUB 2.0.1
→http://idpf.org/epub/20/spec/OCF_2.0.1_draft.doc
「4 ZIP Container」節の末尾
The first file in the ZIP Container MUST be a file by the ASCII name of ‘mimetype’ which holds the MIME type for the ZIP Container (i.e., “application/epub+zip” as an ASCII string; no padding, white-space or case change). The file MUST be neither compressed nor encrypted and there MUST NOT be an extra field in its ZIP header. If this is done, then the ZIP Container offers convenient “magic number” support as described in RFC 2048 and the following will hold true:
The bytes “PK” will be at the beginning of the file
The bytes “mimetype” will be at position 30
The actual MIME type (i.e., the ASCII string “application/epub+zip”) will begin at position 38
EPUB 3
→http://idpf.org/epub/30/spec/epub30-ocf.htm
3.3 OCF ZIP Container Media Type Identification
OCF ZIP Containers must include a mimetype file as the first file in the Container, and the contents of this file must be the MIME type string application/epub+zip.
The contents of the mimetype file must not contain any leading padding or whitespace, must not begin with the Unicode signature (or Byte Order Mark), and the case of the MIME type string must be exactly as presented above. The mimetype file additionally must be neither compressed nor encrypted, and there must not be an extra field in its ZIP header.
ほんとうに3要件を満たしているかは、hexdumpしてみれば分かります。
moria:Desktop tac$ hexdump -C De_Suse.epub |head00000000 50 4b 03 04 0a 00 00 00 00 00 52 bb ac 3e 6f 61 |PK........R..>oa|
00000010 ab 2c 14 00 00 00 14 00 00 00 08 00 00 00 6d 69 |.,............mi|
00000020 6d 65 74 79 70 65 61 70 70 6c 69 63 61 74 69 6f |metypeapplicatio|
00000030 6e 2f 65 70 75 62 2b 7a 69 70 50 4b 03 04 0a 00 |n/epub+zipPK....|
00000040 00 00 00 00 7d bb ac 3e 00 00 00 00 00 00 00 00 |....}..>........|
00000050 00 00 00 00 09 00 00 00 4d 45 54 41 2d 49 4e 46 |........META-INF|
00000060 2f 50 4b 03 04 14 00 00 00 08 00 52 bb ac 3e c5 |/PK........R..>.|
00000070 06 1a 6f a3 00 00 00 f2 00 00 00 16 00 00 00 4d |..o............M|
00000080 45 54 41 2d 49 4e 46 2f 63 6f 6e 74 61 69 6e 65 |ETA-INF/containe|
00000090 72 2e 78 6d 6c 55 8e c1 0e c2 20 10 44 ef fd 0a |r.xmlU.... .D...|いったん、unzipしたものをMacの普通の“圧縮”でZIPして、拡張子を付け替えたもの(De_Suseフォルダの中身だけをZIPしたもの)だと、
moria:Desktop tac$ hexdump -C De_Suse_MacZIP.epub |head
00000000 50 4b 03 04 0a 00 00 00 00 00 7d bb ac 3e 00 00 |PK........}..>..|
00000010 00 00 00 00 00 00 00 00 00 00 09 00 10 00 4d 45 |..............ME|
00000020 54 41 2d 49 4e 46 2f 55 58 0c 00 cd ef cb 4d 6e |TA-INF/UX.....Mn|
00000030 ee cb 4d f6 01 f6 01 50 4b 03 04 14 00 08 00 08 |..M....PK.......|
00000040 00 52 bb ac 3e 00 00 00 00 00 00 00 00 00 00 00 |.R..>...........|
00000050 00 16 00 10 00 4d 45 54 41 2d 49 4e 46 2f 63 6f |.....META-INF/co|
00000060 6e 74 61 69 6e 65 72 2e 78 6d 6c 55 58 0c 00 5e |ntainer.xmlUX..^|
00000070 05 cc 4d 1c ee cb 4d f6 01 f6 01 55 8e c1 0e c2 |..M...M....U....|
00000080 20 10 44 ef fd 0a c2 d5 b4 e8 95 40 4d 4c 3c 6b | .D........@ML<k|
00000090 e2 17 ac 74 ab 44 60 09 50 a3 7f 2f d6 a4 b1 7b |...t.D`.P../...{|
ところが、場合によっては、Macの右クリックによる“圧縮”でつくったZIPファイルの拡張子を「.epub」に書き換えたものでも、Adobe Digital EditionsやSigilはEPUBとして読み出せますし、それをkindlegenで変換したMOBIファイルもKindleで普通に表示できます。
これは上のOCFによる3要件を一つも満たしていないのですが、なぜか大丈夫なのです。
2011年4月28日
今を抱くように生きている人
河津聖恵さんから新詩集『ハッキョへの坂』をいただきました。
この間、朝鮮学校が高校授業料無償化の対象から外されたことの理不尽さに抗い『朝鮮学校無償化除外反対アンソロジー』をまとめるなど、「カナリア」として奮闘してきた河津さんです。
この新しい詩集には朝鮮学校にかかわる詩ももちろん載っているのですが、「ひとは一つの詩とともに生まれてくる」の末尾;
この間、朝鮮学校が高校授業料無償化の対象から外されたことの理不尽さに抗い『朝鮮学校無償化除外反対アンソロジー』をまとめるなど、「カナリア」として奮闘してきた河津さんです。
この新しい詩集には朝鮮学校にかかわる詩ももちろん載っているのですが、「ひとは一つの詩とともに生まれてくる」の末尾;
ただ証すための一篇にいとおしく焼き尽くされるためそんな河津さんの生き方ってすてきだと思うのです。
この今を抱くように生きている
登録:
投稿 (Atom)



