Backuplist+.app v.8.5.4へのアップデート

066f1Backuplist+.app v.8.5.3(昨年の11月頃リリースされたのですね)を立ち上げたところ、起動時にアップデートの自動チェックがオンになっていたようで、v.8.5.4へのアップデートの通知がありました。
アップデートの内容は、以下のとおりです。

•Backuplist+ 8.5.4 important update for all users of OS 10.8 and higher.

THIS IS MY NEW SOMETHING
Version 8.5.4 fixes several bugs

Go to BackupList+ Help Menu > Help and see what is new with this version

Version 8.5.4 fixes several bugs.

Now Compatible with OS 10.12 Sierra.

Fixed duplicate sets so they are now distinct copies and not references to the same object.

Fixed root access for the backupList+ Helper app.

Fixed bug causing the creation of the Recovery HD for clones to fail.

Includes the latest build of rsync 3.1.1, optimized for OS X.

Fixed errors in UUID checks of disks in OS X 10.11.

Several other changes features and improvements overall.

バインドされている‘rsync’のバージョンは3.1.1で(残念なことに3.1.2ではありませんでした)、予備的に3.0.9もオプションで指定できます。
macOS 10.12 Sierraでも動作可能のようで一安心です。

●補足

上記のようにオンラインでアップデートしましたが、作者のページでは、まだv.8.5.3のままでアップデートされていません。

●追記

今日作者のページを見てみたのですが、漸くver.8.5.4になっていました。(2016/09/16)

macでmp3、AAC(m4a)をノーマライズする

世の中はハイレゾへまっしぐらの感があるのですが、私は今更ながらmp3、AAC(m4a)をBluetooth経由でといったプアオーディオをまっしぐらであります。
最近はアルバム単位でプレイリストを作ることもなくなってきて、殆どシャッフルでかき回しているので、曲間のボリューム(音量)の落差が気になってきました。
iTunesで一元管理され(し)ている時にはiVolumeを使っていたのですが、曲単位でスケールファクターを変更できるものは、波形編集できるタイプのソフトを除けばほぼ‘mp3gain(エンジン)’をバインドしたGUIラッパーが多いようです。
幾つか検索結果に出てくるのですが、Mac版は意外と多くないようです。
候補はこんなものでしょうか。

<http://alternativeto.net/software/mp3gain/?platform=mac>

MP3Gain Express for Mac OS XとMacMP3Gain-2.1

その中で“MP3Gain Express for Mac OS X”というのを試してみました。

mp3gain1

ウィンドウ内に対象ファイルをドロップして指定する操作方法は簡便で使いやすいものです。
ただ、残念なのは対象ファイルがmp3に限定され、AAC(m4a)ファイルを処理できないという点です。
もう少し調べてみると‘aacgain’というコマンドラインツールを使用しているものを見つければ、mp3ファイルだけでなくAAC(m4a)ファイルも処理できそうだということがわかりました。
見つけたのが、“MacMP3Gain-2.1”というものです。

macmp3gain_window

AppleScript Studioで作られたGUIラッパーのようで、ドラッグ&ドロップをサポートしていない点が少し残念ですが、機能的には十分です。
バインドしている‘aacgain’のバージョンを見てみると、1.4.6の‘mp3gain’をベースにした‘aacgain’1.7.0バージョンとなっています。

実は、‘aacgain’1.9.0というバージョンが、”MP3Gain Express for Mac OS X”のページに掲載されているのですが、GUIを持たないコマンドラインツールとしてのみの掲載となっています。
<http://projects.sappharad.com/mp3gain/aacgain_19_mac_cmdline.zip>
コマンドラインツールとしてのマニュアルはこのページにあります。

‘aacgain_19_mac_cmdline’をAutomatorで使ってみる

‘aacgain’1.9.0を上述の”MacMP3Gain-2.1″にバインドされている1.7.0と差し替えるという方法も考えたのですが、これは最後の手段として、Automatorを使ってスクリプトメニューから起動できるワークフローにしてみることにしました。

automator_aacgain

  • コマンドラインツール‘aacgain’をアプリケーションフォルダへ入れる。
    (図ではアプリケーションフォルダですが、パスを指定しておけばどこでもいいわけです。システム管理領域に置くこともないわけですし…)
  • 図の設定でワークフローとして保存し、スクリプトメニューから実行できるようにワークフローファイルを配置する。
    (例えば、‘~/Library/Scripts/Applications/Finder/’)
  • Finder上で、ノーマライズしたいサウンドファイルの入ったフォルダを選択してから、このワークフローを実行する。

この例では、Finder項目としてフォルダを選択してから実行するようにしていますが、直接ファイルを選択して実行したい場合は、“フォルダの内容を取得”アクションを外せば、選択されたファイルを対象とすることができます。
コマンドオプションとして‘-p’を使っていないので、元ファイルの修正日が変更されます。日付を変えたくない場合は‘-p’オプションを使ってください。その他のオプションについては、上記のマンページを参照してください。

ついでにMacMP3Gain 2.1に‘aacgain’1.9.0をバインドしてみる

Automatorのワークフローで機能的には十分かとも思いますが、思い立った以上、MacMP3Gain 2.1に‘aacgain’1.9.0をバインドして、MacMP3Gain 2.1のGUIをそのまま使えるようにしてみました。

macmp3gain_bind

‘aacgain’1.7.0バージョンが「aacgain.i386」という名前でバインドされていますので、これを念のため「aacgain.i386_org」と名称変更し、同じ“Resources”フォルダ内に‘aacgain’1.9.0バージョンをコピーして、「aacgain.i386」と名称変更します。
これだけです。

OS X 10.11 El Capitanで、SIP(System Integrity Protection)を無効にしないで、ら行(ラ行)を「L」キーで入力できるように変更する

OS X 10.11 El CapitanでSIP(System Integrity Protection)が導入され、‘/System/Library/Input Methods/’以下にアクセスするためにはrootlessモードに切り替えないと、‘sudo’を使ってもアクセスできないという状況になりました。

(SIP(System System Integrity Protection)は、以下のサイトが参考になります。)

rootlessモードで作業するためには、リカバリーモードでマシンを起動してから‘csrutil’コマンドをターミナル上で使って設定するという方法以外に手段がないため、かなり面倒です。
また、わざわざ‘nvram’の‘rootless=0 & “kext-dev-mode=1’というブートフラグを捨ててきた方向性から考え、Appleのポリシーを尊重するのであれば、常にrootlessモードで作業するというのもできれば避けたいところではあります。
また、考えるに、ユーザレベルでインプットメソッドのモードを切り替えられないというのもどうなのでしょう。‘/System/Library/Input Methods/’以下の設定ファイルを書き換えるということは、ユーザごとに設定モードを簡単に切り替える手段がないということで、不便すぎる仕様ではないでしょうか。
どこかに何か設定フラグがあるはずだよね、と思いながら、なかなか手掛かりがつかめなかったのですが、不図した拍子に見つけました。
要は、‘default’コマンドを使って、ユーザドメインのPreferencesフォルダ内の‘~/Library/Preferences/com.apple.inputmethod.Kotoeri.plist’に‘UseKotoeriRomajiRule’キーを設定するだけです。

ターミナルから‘defaults’コマンドを使って、

defaults write com.apple.inputmethod.Kotoeri UseKotoeriRomajiRule -boolean YES

この後に、日本語入力プログラム(JapaneseIM.app)を再起動します。

killall JapaneseIM

 

plist_key

図は、Xcode上で該当キーが設定されている状態です。

設定のリセットは、

defaults delete com.apple.inputmethod.Kotoeri UseKotoeriRomajiRule

要は、「システム環境設定」の「キーボード」の「入力ソース」のGUIから設定項目が外されただけということのようですが、“外されただけ”というには何とも、むむむ…であります。

CotEditorの文字種変換などやってみる

CotEditor知人から強く勧められたので、CotEditorを試用してみることにしました。

CotEditorのホームページからおもな特長を拾ってみると、次のように記載されています。

 

 

主な機能

・シンタックスハイライト
HTMLやPHP, Python, Ruby, Markdownなど、40以上のメジャーな言語にあらかじめ対応。自分で新たな定義を作成することもできます。

・瞬時に起動
あっという間に立ち上がるので、思い立ったそのときにすぐに書き始めることができます。

・パワフルな検索と置換
定評のあるOniGmo正規表現エンジンによる強力な検索/置換パネルを備えています。

・クリックで設定
マニアックな知識を必要とする複雑な設定ファイルはありません。テーマやシンタックス定義も含め、設定はすべて一般的な環境設定ウインドウから行えます。

・自動バックアップ
CotEditorが編集を逐次自動でバックアップするので、もう強制終了で未保存分の編集を失う心配は無用です。

・アウトラインメニュー
書類から定められたルールに適合した行を抽出しメニューとして表示します。メニューを選択すれば、該当箇所に移動します。

・文字情報表示
選択された文字のUnicode文字情報をポップオーバーで簡単に表示できます。

・エディタの分割
エディタを分割し、文書の異なる部分を一度に表示できます。

・スクリプト
AppleScriptにPython, Ruby, Perl, PHP, UNIX shell、あなたの好きな言語でマクロを書くことができます (YosemiteならJavaScriptでも!)。

・非互換文字の検出
エンコーディングを変換する際には変換できない文字をリストアップします。

“あっという間に立ち上がる”というのは魅力です。

起動してみると、豊富な「シンタックススタイル」によるカラーリング機能、入力補完機能、正規表現が使える検索置換機能など、コードエディタとしての面を見ると評価が高いことが納得できます。
一方、通常のテキストエディタとして使う場合はどうでしょうか?

気になる文字種変換

DTP屋としては、文字種変換が一番きになるところで、組込みの機能は「テキストメニュー」→「変換」にありました。

mojishu

“全角半角変換”機能について試してみました。

aAbBcCDdEeFfGghHIiJjkKlLmMnNOopPqQRrSsTtuUvVWwXxYyzZ。,.:;?!`^_/〜'()[]{}+−=<>$%#&*@0123456789 —

aAbBcCDdEeFfGghHIiJjkKlLmMnNOopPqQRrSsTtuUvVWwXxYyzZ。,.:;?!`^_/〜’“”()[]{}+−=$%#&*@0123456789

上の全角キャラクタを変換したところ、下のようになります。
つまり、“全角半角変換”では、英数だけでなくパーレン他の記号も変換されてしまいます。
DTP屋としては、英字、数字、パーレン類、句読点、記号などは別種として扱いたいところです。
そこで、幾つかスクリプトを書くことにしました。
数字の“全角半角変換”では、

set Zenkaku to "0123456789"
set Hankaku to "0123456789"

tell application "CotEditor"
	if not (exists front document) then return
	tell front document
		set {loc, len} to range of selection
		if (len = 0) then 
			display dialog "文字列を選択してから実行しましょう。" buttons {"OK"} default button "OK" with icon note giving up after 1
			return
		else if (len > 0) then
			set preString to contents of selection
			display dialog "全角<->半角変換できます。" buttons {"キャンセル", "半角", "全角"} default button 2 with icon note returning {button returned:theVarb}
			if theVarb = "全角" then
				set a to my Sed_y(preString, Hankaku, Zenkaku)
				set contents of selection to a
			else if theVarb = "半角" then
				set a to my Sed_y(preString, Zenkaku, Hankaku)
				set contents of selection to a
			end if
		end if
	end tell
end tell

to Sed_y(TheString, SString1, SString2)
	do shell script "export LANG=ja_JP.UTF-8; " & "echo " & quoted form of TheString & " | sed -e 'y/" & SString1 & "/" & SString2 & "/'"
end Sed_y

大文字小文字変換は、

tell application "CotEditor"
	if not (exists front document) then return
	
	tell front document
		set {loc, len} to range of selection
		if (len = 0) then 
			display dialog "文字列を選択してから実行しましょう。" buttons {"OK"} default button "OK" with icon note giving up after 1
			return
		else if (len > 0) then
			display dialog "小文字 <-> 大文字変換できます。" buttons {"ワードキャップ", "小文字", "大文字"} default button 2 with icon note returning {button returned:theVarb}
			if theVarb = "ワードキャップ" then
				tell selection to change case to capitalized
			else if theVarb = "小文字" then
				tell selection to change case to lower
			else if theVarb = "大文字" then
				tell selection to change case to upper
			end if
		end if
	end tell
end tell

その他、“半角カナ”“全角カナ”変換は、アーカイブページの中にサンプルスクリプトが用意されていて、その中にphpのスクリプトがあります。

‘SampleScripts-master/ShellScript/Extras/J-Text-Utility/Full-width Katakana to half-width.php’
‘SampleScripts-master/ShellScript/Extras/J-Text-Utility/Half-width Katakana to full-width.php’

余計なテスト

もっとも単純なバイナリーplistファイルのサンプルとして、‘.webloc’ファイルをCotEditor、Mi、BBEditで開いた場合の表示が次の図です。CotEditor、Miでは扱いが同じで、xml形式の‘plist’ファイルとして扱えるのはBBEditのアドバンテージでしょうか。
因みに、ドキュメントウィンドウ内に‘.webloc’ファイルをドロップすると、CotEditor、Mi、BBEdit共にURLが挿入されます。

plist

OS X 10.11 El CapitanでYosemiteのDisk Utility ver.13を使えるようにする

OS X 10.11 El CapitanではDisk Utilityが書き換えられ、「RAID」タブやアクセス権の検証/修復機能が消えたことは知っていましたが、パーティション機能も制限されていたとは知りませんでした。

du15

図は、2GBのUSBメモリを2分割にして、片方をFAT(MS-DOS)片方をhfs+でフォーマットしたものですが、サイズを変更しないでデータの消去/フォーマットの変換は可能ですが、パーティションのサイズ変更もパーティション数の変更もできません。
OS X 10.11 El CapitanのDisk Utility ver.15以外の手段を考えるしかなく、探したところOS X 10.10 YosemiteのDisk Utility ver.13をEl Capitanで使用可能とする方法があるようです。

vcheck

(Disk Utility ver.13を単にコピーしただけでは、図のようにベージョンチェックに引っかかって起動できません)

しかし、見つけたinsanelymacのパッチファイルはログインしないとダウンロードできない面倒な仕様のようなので、別なページで見つけたパッチ情報を参照して自力でやってみることにしました。

補足情報として、insanelymacのページも参考にします。

(思った以上に情報が少ないので、ここにメモする次第です)

・先ずは、Disk Utility ver.13を確保

Justus Beyer氏の記事ではハッシュ値の確認をしていて、YosemiteのDisk Utility ver.13以外の、例えばMavericksのDisk Utility ver.13ではパッチが効かないようなため、ハッシュ値の一致するYosemiteのDisk Utility ver.13を用意する必要があるようです。
Time MachineでYosemiteのバックアップがあればいいのですが、生憎、Time Machineそのものをイマイチ信用していないので使ったことがないため、都合よくユーティリティフォルダのバックアップなど持っていません。Yosemite稼働マシンも身近にないので、ダウンロード済みのOS X Yosemite インストール.app(英語名ではInstall OS X Yosemite.app)を開いて、Disk Utility ver.13を探します。
OS X Yosemite インストール.appのパッケージを開いて、‘InstallESD.dmg’を探します。パスは、次のようになります。

‘/Applications/Install OS X Yosemite.app/Contents/SharedSupport/InstallESD.dmg’

このInstallESD.dmgファイルをダブルクリックして‘OS X Install ESD’ボリュームをマウントすると、不可視ファイルで‘BaseSystem.dmg’というイメージファイルが第1階層にあります。

‘/Volumes/OS X Install ESD/BaseSystem.dmg’

(ファインダ上で不可視ファイルを見えるようにするためにはいろいろな方法がありますが、拙作の‘CatInvisible.app’を使うと簡単に可視化できます)
‘BaseSystem.dmg’をマウントすると、Applicationsフォルダ内の‘Utilities’フォルダの中に‘ディスクユーティリティ.app’があります。これをデスクトップにでもコピーします。これでDisk Utility ver.13が確保できました。

・ハッシュ値の確認

念のため、‘ディスクユーティリティ.app’のハッシュ値を確認してみます。
‘ディスクユーティリティ.app’の実行ファイルのパスは、
‘~/Desktop/Disk Utility.app/Contents/MacOS/Disk\ Utility’
なので、ターミナルで

$ openssl dgst -sha256 ~/Desktop/Disk\ Utility.app/Contents/MacOS/Disk\ Utility

を実行すると、

SHA256(/Users/demo/Desktop/Disk Utility.app/Contents/MacOS/Disk Utility)= 48529e0206d5f238b96f59bd0a4be7817ebe5d63cf4abee0d8c1529c54bf2d78

という値が戻ってきました。
合っています。

hash

・パッチを当てる

Justus Beyer氏の記事ではHexエディターとして、フリーの‘Hex Fiend.app’’http://ridiculousfish.com/hexfiend/‘を使用していますが、私は使い慣れた‘HexEdit.app’’http://www.ideasfromthedeep.com/product_info.php?products_id=87‘を使うことにしました。
‘Hex Fiend.app’を使う場合は、’sudo’で‘Hex Fiend.app’の実行バイナリを使って、‘ディスクユーティリティ.app’の実行バイナリファイルを開かないと、アクセス権の制限で変更を保存できないのですが、‘HexEdit.app’はユーザ権限のままで変更を保存できます。その場合、オリジナルはファイル名の末尾に‘~’を付加して同じ場所に保存されますので、作業的にはこちらの方が楽で安全でしょう。
さて、置き換えデータは次の通りです。検索/置換で16進数を置き換えるか、そのまま上書きで変更します。

–Justus Beyer氏のデータ
変更前:D584C00F 85440100
変更後:D584C00F 84440100
(オフセットは、10進数で‘25056’です)

–insanelymacのデータでは
変更前:D584C00F 85440100
変更後:D584C0E9 45010000

Hexeditjump

試してみましたが、どちらでシステムバージョンチェックを回避して、10.11 El Capitanでも起動できるようになります。

パーティションの操作はこちらを使うことになりそうです。

DU13-2

・アクセス権の修復はどうなる

10.11 El Capitan上で起動したDisk Utility v.13は、Rootレスモード、つまりSIP(System Integrity Protection)でシステム領域が保護されたことで、「書き換え不能」となったわけで、アクセス権の検証/修復機能は利用できなくなっています。念の入ったことに、GUIから外されただけでなく、’diskutil’コマンドからも’verifyPermissions’と’repairPermissions’というアクセス権の検証/修復機能は取り除かれてしまっています。
調べてみると、’repair_packages’コマンドとしてコマンド自体は残されているのですが、Rootレスモードによってシステム領域である/binや/sbin、/usr/binなどが対象外となっています。
‘repair_packages’コマンドは、次の要領で使用します。

○アクセス権を検証する(管理者権限要)

$ sudo /usr/libexec/repair_packages –verify –standard-pkgs /

○アクセス権を修復する(管理者権限要)

$ sudo /usr/libexec/repair_packages –repair –standard-pkgs /

Macbook Proにテンキーを

Macbook Proのキーボードからの数字入力も慣れてくればそれほどの苦痛ではなくなってきたのですが、エクセルなどで大量のデータ入力などの際には、さすがに音を上げてしまいます。
あれこれとUSBだとかワイヤレスだとかのテンキーを探してみたりもしたのですが、いまいち納得ができません。commandキーやoptionキーなどとの組み合わせで機能するのかなど、不安要素は幾つかあります。
そんな時、5〜6年前くらいでしたか、iPod Touchでテンキー入力ができていた記憶が蘇ってきました。結局、iPod Touchの置き場所というか配置がマウスの位置とかぶるので定着はしなかったのですが、今回はなんとか工夫のしようもありそうです。
で、発掘した(?)のがiPod Touchの第1世代でした。iTunesで見るとプロダクトタイプが「iPod1,1」となっていますので、間違いなく第1世代ですね。となると、春頃に買った記憶があるので2008年春のことですね。すっかり第1世代はパスして第2世代を買ったと思っていたのですが、記憶っていい加減なものです。

■掘り起こしたはいいが、果たして使えるのか?

完全にバッテリーも上がっていましたが接続するとも問題なく通電でき、充電もできたので、iTunesでリストアしました。できるんですねこんな古い機種でも。リストアできる最新OSが3.1.3で、現役だった頃のアプリケーション類はほとんど消えています。現行のiOSのバージョンが8.3ですからこのギャップがどうなるのか?
先ずは、現役のアプリケーションの中から、テンキー機能のものを探してみることにしました。

・iNumKeyPadFree – WiFi numeric keypad
<https://itunes.apple.com/jp/app/inumkeypadfree-wifi-numeric/id358638852?mt=8>
<http://www.mbpowertools.net/iDevices/Home.html>
<http://www.mbpowertools.net/iDevices/Download.html>

screen480x480_programView1_273431.png

先ずはフリーバージョンがあるというので試しにインストールしてみました。Num Lockが付いていて、オフィス系では便利かもしれないなと思いつつ繋いでみました。iOS 3.1.3で動作すること自体が驚きなのですが、それなりに起動して、Macbook Proと接続できました。
ところが、入力をMacbook Pro側に反映させるタイムラグがものすごいことになります。
適当に10桁入力すると最初の1桁目が反映されるのに数秒、残りは取りこぼしも発生し、軽く30秒は無反応の後に歩くくらいの感覚で反映されます。う〜ん、実に、使えません。多分、iOS 3.1.3でハードウェアが2007年のものだというころに原因があるのでしょう。現行のiOS搭載マシンではきちんと動作するんだと思います。

・NumPad Remote<http://mediaware.sk/ware/?page_id=487>

iNumKeyPadFreeで若干くじけてしまったので、試用もできないまま、360円を支払う気になれません。他に手立てが亡くなった時にもう一回考えます。

・NumberKey Connect.app – NumberKey Free<http://www.forest.impress.co.jp/docs/review/20091215_335847.html>

写真

2009年に使っていたのは「NumberKey Free」という名前でした。あのバルミューダがリリースしていたんですね。バルミューダのサポートページ<http://www.balmuda.com/jp/support/category/numberkey>は見つけて、NumberKey Connect.appはダウンロードしたのですが、「.ipa」ファイルがどうしても見つけられません。
2009年当時のバックアップディスクを掘り出すことにしました。
無事ゴミの山からのサルベージに成功して、「NumberKey Free.ipa」ファイルをインストールしてみると、案の定というか予想通りというか無事動作しました。2009年作のNumberKey Connect.appがOS X 10.10 Yosemiteで動作するのも嬉しいところです。
こちらはタイムラグもなく、command、option、shiftキーとのコンビネーションも機能します。

■iNumKeyPadFreeの名誉回復のために再インストール

iPad2であれば動くのではないかと思い、一旦捨てたiNumKeyPadFreeを接続用のアプリケーション「iReceiver.app」と併せて再度ダウンロードしてインストールしてみました。
iPad2では問題なく動作しました。
いま一度と思い、iPod Touch 1st gen.にも入れてみたところ、今度は正常に動作し、タイムラグもなく動きました。
前回のギクシャクはなんだったんだろうという結果です。
「Num lock」を使えば、カーソルキーとしても機能しますので、その辺がメリットであればこれもありでしょう。
1点残念なことは「*」キーが「(」に変わってしまうことで、現時点で解決策が見当たりません。

結論として、多分(?)「NumberKey Free」を使うことになるでしょう。
「NumKeyPadFree」は、iPod Touch 1st gen.の画面ではキーサイズが小さく感じます。
iPhone5, 6では問題ないのでしょうね。

TextWrangler.app / BBEdit.appで日本語の文字種変換をやってみる

長い間TextWrangler.appを使い続けていて、機能面で不足を感じていた訳ではないのですが、つい出来心(?)でBBEdit.appにアップデートしてしまいました(次のメジャーアップデートの際に、有料でアップデートするかどうか悩ましいところです…)。
有難いことに、スクリプトは(ほぼ?)完全互換のようで、TextWranglerr.app用に書いたものは全てBBEdit.appで動作します。逆も然り。
AppleScriptではScript内の‘Tell application …’以下の名称をTextWranglerからBBEditに変更するだけです。

現在、mi.appでやれることはほぼBBEdit.appでもやれるようにしていますが、日本語の文字種変換だけ手付かずのままでした。

BB

日本語の文字種変換は、対応していないアプリケーションでも「サービス」に対応していれば、‘CharConvX.app’<http://www5.wind.ne.jp/miko/>を使えば実現できてしまうので、それはそれでいいかな、と放置していたわけです。

で、結局‘sed’を使ってみることにしました。

set vString1 to "アイウエオカキクケコサシスセソタチツテトナニヌネノハヒフヘホマミムメモヤユヨラリルレロワヲンァィゥェォャュョッー・「」。、゚゙"
set vString2 to "アイウエオカキクケコサシスセソタチツテトナニヌネノハヒフヘホマミムメモヤユヨラリルレロワヲンァィゥェォャュョッー・「」。、゜゛"

tell application "BBEdit" --BBEditをTextWranglerに置き換えればTextWrangler.appで動作します
	activate
	if (selection of text window 1 as string) is not "" then
		replace "ヴ" using "ヴ" searching in selection of project window 1
		replace "ガ" using "ガ" searching in selection of project window 1
		replace "ギ" using "ギ" searching in selection of project window 1
		replace "グ" using "グ" searching in selection of project window 1
		replace "ゲ" using "ゲ" searching in selection of project window 1
		replace "ゴ" using "ゴ" searching in selection of project window 1
		replace "ザ" using "ザ" searching in selection of project window 1
		replace "ジ" using "ジ" searching in selection of project window 1
		replace "ズ" using "ズ" searching in selection of project window 1
		replace "ゼ" using "ゼ" searching in selection of project window 1
		replace "ゾ" using "ゾ" searching in selection of project window 1
		replace "ダ" using "ダ" searching in selection of project window 1
		replace "ヂ" using "ヂ" searching in selection of project window 1
		replace "ヅ" using "ヅ" searching in selection of project window 1
		replace "デ" using "デ" searching in selection of project window 1
		replace "ド" using "ド" searching in selection of project window 1
		replace "バ" using "バ" searching in selection of project window 1
		replace "ビ" using "ビ" searching in selection of project window 1
		replace "ブ" using "ブ" searching in selection of project window 1
		replace "ベ" using "ベ" searching in selection of project window 1
		replace "ボ" using "ボ" searching in selection of project window 1
		replace "パ" using "パ" searching in selection of project window 1
		replace "ピ" using "ピ" searching in selection of project window 1
		replace "プ" using "プ" searching in selection of project window 1
		replace "ペ" using "ペ" searching in selection of project window 1
		replace "ポ" using "ポ" searching in selection of project window 1
		set PreString to (selection of text window 1 as string)
		set the clipboard to my Sed_y(PreString, vString1, vString2)
		delay 0.1
		paste
	else
		display notification "文字列を選択してから実行しましょう。" with title "Notification" subtitle ""
	end if
end tell

to Sed_y(TheString, SString1, SString2)
	do shell script "export LANG=ja_JP.UTF-8; " & "echo " & quoted form of TheString & " | sed -e 'y/" & SString1 & "/" & SString2 & "/'"
end Sed_y

半角カタカナの濁音・半濁音については、半角カタカナが2文字に換算されるので‘sed’のルーチン枠内では変換できないので、無骨に1文字ずつ置換をしています。逆方向の変換は変数を逆にすればOKです。
このやり方をベースにすれば、全角英数字⇄半角英数字の変換も容易です。

言語環境を’en’にしてみると、都合のいいことも悪いことも…

OS Xは最初のバージョンが出てきたときから、マルチランゲージと言われていました。
確かにそれぞれの言語ごとのパッケージではなく1パッケージに複数の言語環境がパッケージされていましたから、各言語ごとに異なるパッケージを購入する必要がないということは素晴らしいことでした。
しかし、実際に、例えば‘en’環境の下で‘日本語’アプリケーションを使おうとすると、メニューなどのUIが追随しなくて正常に動作しないものや、インストール時に‘日本語’を選べないアプリケーションが多くありました。
まがりなりにも‘マルチランゲージ’と言えるのはFinderとInputMethodくらいしかないじゃないかと悪態をつきたくなるような状態が結構長く続いたので、OS X 10.6, 7くらいまではそれなりに試してがっかりを繰り返したのですが、その後、諦めきってしまったのでわざわざ‘en’環境にしてみることもなかったのです。
ところが、ついうっかりOS X 10.10 Yosemiteに切り替えてしまって、余りのメモリ使用に関して”富豪主義”というか”大喰らい”というか、あればあるほど喰らうんだねえおまえはと言いたくなる有様にうんざりしてしまったので、ものは試しで‘en’環境にしてみました。

en1

うん、ちゃんとマルチランゲージだわ。Finderだけじゃないですね。
Adobe系のアプリケーションがきちんと動作することにはびっくりしました。(なんと、CS3がまともに動作します)

そもそも、Photoshop、Illustratorなどは英語マニュアルで覚えましたので、変なローカライズメニューの方が辛かったりします。

設定した言語と地域の情報は、‘~/Library/Preferences/.GlobalPreferences.plist’にそれぞれ‘AppleLanguages’、‘AppleLocale’キーとして保存されます。
それぞれのアプリケーションは、‘AppleLanguages’キーを読んでUIエレメンツを差し替える仕組みのようです。

■言語環境を’en’にしてみて、都合が良かったこと
数値データとして裏打ちできないのですが、確実に起動時と運転時のメモリ使用量が減ってきます。
日本語リソースがどの程度キャッシュされるのか、比較データを示せないのが残念ですが、クールブートしたときのメモリ使用量が明らかに減って来るのと、その後の変化を見てみても‘ja’環境よりはメモリ使用量が減っています。

■出てきた不具合
幾つかのアプリケーションで、‘en’環境では不具合が出るものが見つかりました。

  • Safariの不具合

Firefoxなどと異なって、Safariはアプリケーションサイドでの言語設定ができません。

en2

図は、確認くんのページですが、赤線の部分のように‘en-us’と表示されます。
従って、ブラウザの言語設定を読んで、ログイン制限をかけているサイトではアクセスできない所が出てきます。
私の場合も、プロバイダのログイン画面から先に進めなくなってしまいました。
対処としては、言語設定を変更できるFirefoxなどのブラウザに切り替えるという手があります。
もう一つは、Safariの言語設定を強引に切り替えるという方法もありでしょう。
探してみたところ、‘default write…’でSafariの言語設定を書き換える方法がみつかりました。

$ defaults write com.apple.Safari AppleLanguages -array ‘ja’

‘~/Library/Preferences/com.apple.Safari.plist’ファイルに‘AppleLanguages’を書き加えるという手法です。

設定を元に戻すのは、

$ defaults delete com.apple.Safari AppleLanguages -array ‘ja’

で、システム側の言語設定に切り替わります(アプリケーションの再起動は必要です)。

  • mi.appの「ツール」コマンドの不具合

‘<<<TRANSLITERATE-REGEXP-SELECTED()’が正常動作しなくなりました。()の中に文字種変換のフィルタ名を挿入して使うのですが、英語名で入れても動作しません。(ver. 3.0.0b8)
ここは諦めて(素直に)mi.appの言語設定を書き換えることにしました。
方法はSafariと同じようなことです。

$ defaults write net.mimikaki.mi AppleLanguages -array ‘ja’

‘~/Library/Preferences/net.mimikaki.mi.plist’ファイルが対象です。

これは、‘defaults write…’ではなく‘plutil’コマンドを使うこともできます。
例えば、こんな風になります。

$ plutil -insert ‘AppleLanguages’ -xml ‘ja’ ~/Library/Preferences/net.mimikaki.mi.plist

通常使用時には、システムの言語設定を読んでいますので、‘AppleLanguages’キーを‘~/Library/Preferences/net.mimikaki.mi.plist’ファイルは持っていないので、オプションは‘-insert’でOKです(書き換えの場合は‘-replace’でないとエラーとなります。‘defaults write…’の方が間違いがないでしょうね)。

設定を元に戻すのは、

$ defaults delete net.mimikaki.mi AppleLanguages -array ‘ja’

で、システム側の言語設定に切り替わります(アプリケーションの再起動は必要です)。

テンキーのないMacbook ProでInDesignのテキストスタイルのショートカットを登録してみる

面白いことに、InDesignでは、テンキーの数字キーは[文字スタイル][段落スタイル]に割り当てるショートカット用として予約されています。
そのため、通常のショートカットでは使用できません。
逆に言えば、[文字スタイル][段落スタイル]のショートカットには、テンキー+command、option、shiftキーの組み合わせしか登録できないようで、テンキーのないマシンでは困ったことになります。

ScreenShot 2015-04-13 at 12.53.52

追加でテンキーを導入するというのも作業スペースの関係で採用したくないので、なんとか方法はないものかと思ってはいたのですが、漸く少し時間が空いたので、AppleScriptとKeyboard Maestro 4でやってみました。
(Keyboard Maestro 4のTypeアクションだけでやれると思っていたのですが、commandとoptionキーの同時押し下げの方法が分かりませんでした…)

取り敢えず、「command+shift+数字」と「command+option+数字」のパターンを設定してみました。

1KM

・InDesignがフロントアプリケーションの時だけ動作するように、最初にマクログループを作って、そのグループフォルダ内にAppleScriptを実行するアクションを設定してます。
・テンキーの数字に対応するキーコードは、このページを参照してください。

「command+shift+数字」パターンでは、スクリプト内ではshiftを設定していないのですが、Keyboard Maestro 4のホットキーの「shift」を拾っているのかもしれません。

■補遺

サンプルとしての上の図のKeyboard Maestro 4のホットキー設定は、InDesignの既定のショートカットとのコンフリクトを一切考慮していません。あくまで、テンキーのkey codeを使えば、[文字スタイル][段落スタイル]にショートカットをテンキーのないマシンでも設定できることを試したものです。

もし、既定のショートカットとのコンフリクトがある場合は、ホットキー設定を変えるか、InDesign側の既定値を書き換えるなどで対処してください。

2ディスプレー環境でそれぞれのデスクトップピクチャを切り替えるAutomatorワークフロー

セカンドディスプレー側のデスクトップピクチャの取得方法が中々つかめないまま放置していたのですが、重い腰(?)を上げて調べてみました。
「デスクトップピクチャ 2ディスプレイ mac」などのキーワードで検索したのですが、Automator、AppleScript関連の情報があまり出てこないなと彷徨ったところ、ここを見つけました。

メインディスプレーのピクチャをランダムに変更するAutomatorワークフローについてはこちらで記しましたが、もう一つのディスプレーのピクチャをどうやればいいのか…というのが、これでなんとかなりそうです。(System Events.appとはねえ…)

1

Automatorワークフローは図のAppleScriptの部分を書き換えることにします。画像ファイルの取得とフィルタリングはそのままです。
AppleScriptの部分は次の通りです。

on run {input, parameters}
	tell application "System Events"
		set DispNamae to name of every desktop as list
		set DispNamae1 to (item 1 of DispNamae as string)
		set DispNamae2 to (item 2 of DispNamae as string)
		display dialog "どちらのデスクトップのピクチャを変更しますか?" & return & "=-=-=-=-=-=-=-=-" & DispNamae1 & return & DispNamae2 & return & "=-=-=-=-=-=-=-=-" buttons {"Cancel", DispNamae1, DispNamae2} default button 2 with icon note returning {button returned:theVarb}
		if theVarb is DispNamae1 then
			tell (every desktop whose display name is DispNamae1)
				set previousItem to picture
				set targetItem to (some item in input) as alias
				if targetItem is previousItem then
					set targetItem to (some item in input) as alias
				end if
				try
					set picture to targetItem
				end try
			end tell
		else if theVarb is DispNamae2 then
			tell (every desktop whose display name is DispNamae2)
				set previousItem to picture
				set targetItem to (some item in input) as alias
				if targetItem is previousItem then
					set targetItem to (some item in input) as alias
				end if
				try
					set picture to targetItem
				end try
			end tell
		end if
	end tell
end run

2

ディスプレーの名前を入力するのも面倒なので、先ず名前を取得して、ダイアログボタンでどちらを変更するか選択するようにしています。