読者です 読者をやめる 読者になる 読者になる

テクデップ(Techdep)

コンピュータ、プログラミング、DTP(InDesign)に関する備忘録

「ガルパンはいいぞ!」な物語論

物語論

劇場版ガールズ&パンツァーBlu-rayが発売されました。自分は立川の爆音上映を何度か観ましたが、あの重低音は素晴らしいものですね。さて、例によって、このガールズ&パンツァー劇場版を物語論の観点から解釈しましょう。

続きを読む

「常用漢字表、表外漢字はいわゆる康熙字典体」を実現するInDesign向けの字形変換スクリプトを公開しました

InDesign 組版 漢字 字体

常用漢字表、表外漢字はいわゆる康熙字典体」を実現するInDesign向けの字形変換スクリプトGlyphconv 2を公開しました*1

f:id:seizo_igawa:20160516162408p:plain

目的

字体整理の標準とされる方針「常用漢字表、表外漢字はいわゆる康熙字典体」ですが、DTPでは拡張新字体というものが問題になります。

これを排除する必要がありますが、この作業を手動で行った日には、時間も掛かる上に作業漏れも多数出てくるでしょう。

このスクリプトは上記の作業を自動化したもので、作業時間の大幅な短縮と整理品質の安定を実現させます。

前バージョンからの変更点

以前にVectorで公開したものと比べて、以下の点を変更しました。

  • 常用漢字表(昭和56年)の字形変換設定 → 削除
  • 外部ソフトウェアが必要 → 不要になりました。InDesignのみで動作します

字形変換について

次の様な字形変換が可能です。常用漢字表内での筆押さえの有無を選択することが可能です。いわゆる康煕字典体へ変換すると標準字形に戻せません。

f:id:seizo_igawa:20160516163146p:plain

使用上の注意点

変換時間

字形変換にはある程度時間がかかります。変換時間は使用するパソコンの性能に依存します。一般に「長文」であればあるほど変換時間は長くなります。また、「いわゆる康煕字典体」の設定で変換すると相当時間がかかります。

数万字を超える長文に対して「いわゆる康煕字典体」変換を行うときは、部分ごとで分割して変換することをお勧めします。

利用条件

スクリプトは商用・非商用に関わらず自由に使用できます。ただし、本スクリプトを使用したことで生じた如何なる結果について、スクリプト製作者は責任を負いかねます。

ダウンロード

下記のリンク先よりダウンロードできます。
https://github.com/igawa-seizo/glyphconv2/releases/download/2.0/glyphconv2.zip

インストール方法

ファイルをまとめて、InDesignスクリプトディレクトリに置くだけで完了です。後はInDesignスクリプトパネルから起動できます。
詳細については附属マニュアルをご参照ください。

*1:Vectorにも同様のスクリプトが公開中ですが古いバージョンです。近日中に公開を停止するかもしれません

日比谷カレッジ「情報化時代に考えたい漢字の話」聴講記録

日比谷図書文化館にて催された「情報化時代に考えたい漢字の話」を聴講したので、文字起こしをします。 内容としては大きく三つに分かれており、 - 常用漢字表とは - 平成22年の改訂はどのようにして決まったのか - 常用漢字表の字体・字形に関する指針 でありました。特に「常用漢字表の字体・字形に関する指針(報告)について|文化庁」については2月29日に文化庁が公開したばかりの指針であり、非常にタイムリーなお話です。

講師は文化庁国語課の武田康宏さんです。常用漢字表や今回の指針の策定にも携っている方で、日本の国語政策に関る官僚のお話を聞けた貴重な機会でした。

この文字起こしは当日のレジュメと講師の発言を概ね時系列順に提示しつつ、私の補足や意見を追記する形で行きます。

講師の発言やレジュメの要約は、文章の前にバレットをつけてリスト形式にしています。

続きを読む

VLAN備忘録:タグ付きフレーム/アクセスポート・VLAN非対応スイッチ

VLAN備忘録

VLAN関係で文献であまり取り上げられて居ない事例について調べないといけない機会があったので、記録しておく。

タグ付きフレームはVLAN非対応スイッチを通過できるか?

トランクポートから送出されたフレームは、VLAN IDが格納されたタグ付きフレームとなって、伝送路を流れる。さて、途中でタグ付きフレームがVLAN非対応スイッチを通る場合、どう処理されるのだろうか?

結論としては、大抵の場合は問題なく転送される。イーサネットフレーム長は規格では1518バイトであるが、VLANタグ付きフレームでは4バイトのヘッダが挿入されて1522バイトとなる。今日は大体がジャンボフレーム対応の機器であるから、問題なく通信できるだろう。ジャンボフレーム非対応の機器であると破棄される。

VLAN非対応の機器はフレーム内部に挿入されたVLAN情報を一切見ずに、宛先のMACアドレスに基づいて通常通りに処理をするだけだ。

アクセスポート(アンタグポート)がタグ付きフレームを受信したときどうなるか?

VLAN対応スイッチでは、アクセスポートとトランクポートとを設定できる。アクセスポートは端末をつなぐためのもので、トランクポートはスイッチ間をつなぐためのものだ。トランクポートから送信されるフレームはVLANタグが挿入される。それでは、アクセスポートがタグ付きフレームを受信したとき、そのフレームはどの様に処理されるのか?

調べた限り、タグ付きフレームのVLAN IDとポートのVLAN IDとが一致している場合に限って受信する様だ。

If an access port receives a packet with an 802.1Q tag in the header other than the access VLAN value, that port drops the packet without learning its MAC source address.

Cisco Nexus 5000 Series NX-OS Software Configuration Guide - Configuring Access and Trunk Interfaces [Cisco Nexus 5000 Series Switches] - Cisco

以下のアライドテレシス機器の説明書でも、似た様な説明があった。
AT-DC2552XS コマンドリファレンス 2.5.3.1: L2スイッチング / バーチャルLAN

また、以下のフォーラムでは、QoSフィールドも絡んだ状況下でアクセスポートがタグ付きフレームを受け入れることもあるという発言がある。
https://supportforums.cisco.com/discussion/11899466/vlandoes-access-port-drop-frame-when-it-received-frame-tag

InDesignでのダブルミニュートと全角ダーシの禁則処理

InDesign 組版

本記事を要約すると、縦書き用の引用符であるダブルミニュート(U+301D、U+301F)と全角ダーシ(U+2015)を禁則対象文字に登録しておくべし。

禁則処理と表示グリフ

InDesignでは実際に表示されるグリフ(CIDに基づいた)は、組方向、字形タグなどによって決定される。場合によっては、異なるUnicodeでありながら、表示されるグリフは同一になることもある。このような文字として引用符や全角ダーシがある。

さて、InDesignはある文字が禁則対象であるかどうかはUnicodeのほうで判定する。ここで問題なるのがそれのデフォルト設定である。InDesignの「弱い禁則」には“”(U+201C、U+201D)は登録されているが、〝〟(U+301D、U+301F)が登録されていない。また、強弱どちらの禁則にもダーシ(U+2014)があるが、全角ダーシ(U+2015)はない。

つまるところ、同じグリフなのに異なるUnicodeであるため、禁則処理が異なる結果がありうる。引用符の混在あるいは全角ダーシが混在している原稿であると、下記の様に禁則処理結果が不適当なものになる。一方で禁則処理が全くなされていないのは、この文字が禁則文字として登録されていないためだ。

f:id:seizo_igawa:20160213211122p:plain

引用符の場合

横書き用の引用符(“”)とはInDesign上で等幅全角字形を適用すると、縦書き用の引用符(〝〟)に置換される。表示上では同じグリフなので、“”(U+201C、U+201D)か〝〟(U+301D、U+301F)であるかの区別はつかない。情報パネルからは異なるUnicodeポイントであることはわかる。

Unicode CID 備考
U+201C 108 -
U+201C 7956 等幅全角字形の適用時
U+301D 7956 -
U+201D 122 -
U+201D 7957 等幅全角字形の適用時
U+301F 7957 -

全角ダーシの場合

似た様なことが全角ダーシ(―、U+2015)にも言える。U+2015であると縦組みか横組みかで呼び出されるCIDが異なる。

Unicode CID 備考
U+2014 138 -
U+2014 661 等幅全角字形の適用時
U+2015 661 横組み
U+2015 7892 縦組み、字形パネルで見るとU+FE31のグリフが呼び出される模様

対応方法

記号類が混在した原稿もありうるし、Windows環境で作成された原稿は基本的には〝〟(U+301D、U+301F)や―(U+2014)で入力されることが多い。そうなると引用符や全角ダーシの禁則処理が不適切な組版が世に出ることになる。何らかの対応をしないといけない。

対応方法としては色々あるけれども、禁則処理テーブルに引用符(U+301D、U+301F)と全角ダーシ(U+2015)とを登録しておこう。全角ダーシ(U+2015)は「強い禁則」、「弱い禁則」ともに登録されていないので登録しておく。引用符は「弱い禁則」に登録しておく。

Python向けのヘッドレステスト環境の構築

Django Python JavaScript プログラミング

Django等でheadless test(GUIブラウザを利用しないウェブアプリケーションのテスト)を実行するための環境構築の覚書。尚、筆者の環境は以下の様になって居る。

準備

seleniumの導入

pip install selenium

PhantomJSの導入

このサイト(http://phantomjs.org/)から導入する。導入後、パスを通しておく。

動作確認

seleniumの動作確認

下記の様なコードを書いて、適当な名前で保存しよう。このコードではFirefoxを起動させて、Python公式ページで検索して、Firefoxを終了させるまでを記述して居る。

from selenium import webdriver
from selenium.webdriver.common.keys import Keys

# ブラウザの指定
driver = webdriver.Firefox()
driver.get("http://www.python.org")
assert "Python" in driver.title

# テキスト欄への入力
elem = driver.find_element_by_name("q")
elem.send_keys("pycon")
elem.send_keys(Keys.RETURN)
assert "No results found." not in driver.page_source

# ブラウザの終了
driver.close()

実行方法は次の通り。Firefoxが勝手に起動して、自動で検索をしてくれるはず。

python selenium-test.py

PhantomJSの動作確認

下の様なJavaScriptコードを書いて、“test.js”として保存しよう。

console.log("2 + 2 = ?");
phantom.exit();

コマンドライン上で動作確認する。“2 + 2 = ?”と表示されれば問題ない。

phantomjs test.js

テストコード化

動作確認が済んだらそれぞれを組合せて、テストコードを記述していく。今回はPythonのunittestを使用する。

import unittest
from selenium import webdriver
from selenium.webdriver.common.keys import Keys

class TestPage(unittest.TestCase):
    def setUp(self):
        self.driver = webdriver.PhantomJS()     

    def test_search_in_python_org(self):
        self.driver.get("http://www.python.org")
        assert "Python" in driver.title

        # テキスト欄への入力
        elem = self.driver.find_element_by_name("q")
        elem.send_keys("pycon")
        elem.send_keys(Keys.RETURN)
        assert "No results found." not in driver.page_source

    def tearDown(self):
        self.driver.close()

Django等のウェブフレームワークでの利用

  • 接続先を“localhost”にして試験内容を記述する。
  • Djangoのローカルサーバを立ち上げて、テストコードを実行する

【失敗事例】恐竜テーマパークにおけるインドミナス・レックスの脱走

映画ジュラシック・ワールドを観て、失敗事例報告書を思いつきました。感想代りに書いておきます(内容はちゃんと面白かったのでご安心ください)。

失敗事例:インドミナス・レックスの脱走

事例名称

インドミナス・レックスの脱走

代表図

省略

事例発生日付

2015年8月5日

事例発生地

コスタリカ イスラ・ヌブラル島

事例発生場所

ジュラシックワールド インドミナス・レックス飼育エリア

事例概要

飼育中の新種恐竜インドミナス・レックスが脱走し、飼育員2名を殺害した。また、捕獲のための部隊も全滅させられた。

事象

飼育中のインドミナス・レックスが防壁(コンクリート製)をよじ登って脱走したのではないかと勘違いした職員が、調査のために防壁内に入った。しかし、恐竜は熱カモフラージュができる性質を備えており、そのために熱源カメラに映っていないだけであり、実際にはまだ防壁内部に居た。管理センターは恐竜が防壁内部に居ることを現場に連絡したが、その直後に恐竜が職員3名に襲い掛かった。この段階で1人が死亡し、2人は防壁からの脱出を果たした。ただ、その脱出には恐竜用ゲートを利用したため、ゲートが完全に閉まりきる前に恐竜がゲートを破壊して脱走。その後、恐竜は職員1人を殺害し、島内の密林へと逃げ込んだ。

経過

事故当日、飼育エリアの防壁の安全性を確認するために調教員が訪れた。彼は本来ヴェロキラプトルの調教員であるが、その経験と知識を買われて運営責任者から直々に当該施設の安全性の確認を命ぜられて、ここを訪れたのであった。

そこで調教師はインドミナス・レックスの姿が見えないことを疑問に思い、普段インドミナス・レックスを監視している飼育員に熱源カメラでの確認を依頼した。

しかし、熱源カメラにはその姿が映らなかった。また、ここで調教師はインドミナス・レックスが内部の壁をよじ登ったと思しき真新しい爪痕を発見した。ここで居合わせた全員がインドミンス・レックスは壁をよじ登って飼育エリアから脱走したと勘違いした。そして、調教師と2人の飼育員は調査のために、無断で防壁内部に立ち入った。また、護衛用の武器を所持せずの立ち入りであった。

現場から連絡を受けた管理センターはGPSによる追跡をしたところ、恐竜は防壁内部に居ることが判明。恐竜には熱カモフラージュの性質があり、単にそれを利用して、熱カメラに映って居ないだけであった。

内部にまだ恐竜が居るとの連絡を受けた三人であるが、それと同時に姿を現した恐竜と遭遇。このときに飼育員一人が恐竜によって殺害された。

生き残った調教師と飼育員は脱出を開始。しかし、このとき脱出に使ったのは恐竜用の巨大ゲートであった。二人は脱出には成功したが、巨大ゲートであるため閉鎖に時間が掛かる仕様であり、完全に閉まりきる前に恐竜の突撃を受け、ゲートは破壊された。こうして凶暴な肉食恐竜が脱走するという事態が発生したのであった。

飼育員は車の陰、調教師は車の下にそれぞれ隠れたが、恐竜は飼育員を殺害した。調教師はガソリンを被って体臭を消すという方法で恐竜に発見されず難を逃れた。そして、恐竜は森の中へと逃げ込んだ。

その後、当テーマパークの捕獲隊が直ちに出動したが、その捕獲隊も全滅した。

原因

重大情報の横展開の欠如

飼育中のインドミナス・レックスは遺伝子組み換えによる全く新種の恐竜である。この恐竜は、熱カモフラージュするという恐るべき特性を持ち合わせており、熱源カメラに姿が必ずしも映らない。開発部門はその性質を把握していた可能性があったが、その情報は飼育部門に展開されていなかった。このことが現場での誤判断や対処の誤りを招いた一因となった。

確認手段の不備

上述の恐竜は熱源カメラに探知されない性質を持っているが、当該恐竜に対して所在を確認するために従前通りの熱源カメラを用いていたのは不適当である。これも上記の横展開不備により、飼育部門が飼育対象の性質をよく把握しないままに従来通りの監視手段を採用させてしまった。

情報確認の不徹底

恐竜の監視は熱源カメラ(現場からも確認可能)とGPSの二通りで行えたが、GPS情報は管理センターに問合せねばならなかった。しかし、現場の職員は熱源カメラの情報のみで恐竜が脱走したと判断。管理センターへのGPS情報の問合せを怠って、最終確認のために防壁内部に独断で入ってしまった。

恐竜が脱走したかもしれないという状況下において、素早い対処と判断をしたいがために、手間暇が掛かる情報の確認が省略されたことが、結果として今回の事態を招いた。

脱走防止対策の不備

ゲートは多重化がされていなかった。このため、一度の突破が被害の際限なき拡大を招いてしまった。これを防止するためにもゲートを二重化するべきであった。

防壁の強化工事は行っていたが、同時にゲートの多重化や強化はできたはずである。

対処

その後も捕獲部隊が波状的に出動し、事態の収拾に当たった。

対策

  • 飼育対象の性質は関係部門で共有する。特に開発部門と飼育部門は意思疎通に齟齬が生じやすいので、管理部門はその齟齬が発生しない様に尽力すべきである。特に新種の恐竜はそれを徹底すること。現場レベルでは、飼育する恐竜ごとに管理に関る性質のマニュアルを常備しておくこと。
  • 恐竜の所在情報は飼育員にとっては大変重要な情報である。タブレットなどで容易に確認できるようにすることが望ましい。
  • 情報の確認手順は明文化する。
  • 飼育対象の性質に応じた監視手段を用意する。
  • 肉食恐竜の防壁内部には無断で入らないようにする。また、立ち入るときは武器の携行を義務付ける。

知識化

  • 安全に関る全ての情報(今回の場合は恐竜の所在)は現場からも容易かつ即座に確認できるようにする。
  • 情報の確認手順はマニュアル化する。
  • 飼育対象の重大な性質は全ての関係部門に展開させること。
  • 危険な場所へは無防備かつ無断で入ってはならない。
  • 安全機構は多重化すること。

背景

当テーマパークはマンネリ化を防ぐために、新規アトラクションや新種の恐竜の導入を定期的に実施しており、今回のインドミナス・レックスもその一つである。この対策が功を奏して収益も右肩上がりであったが、経費も比例して増大することも経営側には頭痛の種であった。このため安全管理に対する資金投下が抑制的になりつつあり、抜本的な安全対策を取って居なかったことが、今回の事故を引き起こす土壌になっていたことは否めない。

後日談

この脱走がきっかけとなって、当テーマパークが崩壊することになったが、詳細は劇場にて確認されたい。

シナリオ

主シナリオ

組織運営不良、不注意、手順の不遵守、誤判断、調査・検討の不足

死傷者

死者数 2名(飼育員)
10名以上(第一次捕獲部隊)
負傷者数 不明