Naganoya指定のRTFから書式スタイル名(フォント名、フォントサイズ)を抽出し、そのスタイルをダイアログ上にポップアップメニューで一覧表示し、指定スタイル該当箇所を抽出したプレビュー表示を行いつつ、選択スタイル関連の情報を取得できるAppleScriptライブラリです。Menuからでも実行できますし、AppleScript用語辞書(sdef)を書いたので、簡潔かつ手軽に呼び出せるようになりました。Scriptを掲載し、さらに本Blog上の画面キャプチャをリンクしてあるため、実行時の画面イメージも把握できるようになっています。Scriptを掲載しています。前バージョンではポップアップメニューにスタイルを適用してWYSIWYGメニューを作成していました。クリックしてメニュー表示を行なっているときにはスタイルが表示されていい感じでしたが、クリックしていない時にはボタンのサイズよりも大きいサイズは欠けて表示されるので、実用性がいまひとつ。そのため、本バージョンではWYSIWYGメニューの機能は省略しました。ポップアップしていない時にはWYSIWYG表示にならないように機能を両立できるとよかったのですが、、、、また、前バージョン同様に、「巨大なRTFを指定された場合でも足切りをしない」ようになっているので、あまり巨大なRTFを指定しないようにしてください。fromコマンド指定のRTFからスタイル{フォント名,フォントサイズ}を抽出し、ダイアログ上のポップアップメニューで選択したスタイル{フォント名,フォントサイズ}を返します。fromコマンド指定のRTFからスタイル{フォント名,フォントサイズ}を抽出し、ダイアログ上のポップアップメニューで選択したスタイルの該当箇所のテキストを返します。styleコマンド指定のRTFファイルから指定のスタイル{フォント名,フォントサイズ}で指定した箇所のテキストを返します。本コマンドはダイアログ表示を行わず、ただRTFからテキスト抽出するだけです。stylesコマンド指定のRTFファイルからすべてのスタイル{フォント名,フォントサイズ}を抽出します。本コマンドもダイアログ表示は行いません。Naganoya指定のRTFファイルから書式情報を取得し、フォント名とフォントサイズのペアをスタイルを反映させたポップアップメニューで選択。RTFの内容を解析したのち、ダイアログが表示されます(ここの所要時間は読ませるRTFのサイズ次第)。ポップアップメニューで書式を選ぶと、すぐさま抽出した箇所をすべてまとめて表示します。dataダイアログ表示前に書式ごとの抽出を完了し、個別のTabViewに抽出後の文字データを展開しておくので、ポップアップメニューから選択すると、展開ずみのデータを入れてあるTabViewに表示を切り替えるだけ。切り替え時に計算は行わないため、すぐに抽出ずみの文字データが表示されるという寸法です。今回は短いサンプルデータを処理してみましたが、サンプル抽出時にあらかじめ範囲指定するなどして、データ処理規模を限定することで処理時間を稼ぐこともできることでしょう。テキストエディットでオープン中のRTF書類のパスを取得して、それを処理対象にしてもいいでしょう。やっつけで作ったのでスクリプトエディタ上でCommand-Control-Rで実行しないと動きません(メインスレッド実行をプログラムで強制しても、途中でクラッシュしてしまいます)。それほど時間もかけずに作ったやっつけプログラムなので、あまり原因追求も行えずそのままです。NaganoyamacOS標準搭載のテキストエディタ「テキストエディット」の最前面のドキュメントから書式情報を取得し、フォント名とフォントサイズのペアをスタイルを反映させたポップアップメニューで選択。選択したスタイルが該当する箇所を抽出したのちにテキスト化してTextViewで結果を表示します。RTF(なんでもOK)▲添付のAppleScriptアプレットは、初回実行時に制御許可のダイアログが表示されます。OKすれば、2回目以降はダイアログ表示されません▲書式情報をRTF書類から読み込んで、スタイルを反映させたポップアップメニューで表示。NaganoyamacOS標準搭載のテキストエディタ、「テキストエディット」(TextEdit)をコントロールして、最前面のウィンドウの書類から、指定のフォント名とサイズに該当するテキストを抽出するAppleScriptです。テキストエディットはApple純正のアプリケーションの割にはAppleScriptサポート機能がよくできていて、選択範囲(selection)を取得できないことをのぞけば、けっこう使えます。16pointを指定Webブラウザなどからコピペしてきたスタイル付きテキストから、特定のフォントや文字サイズの箇所を抽出したい場合に使います。実行すると、リッチテキストで使用されているフォント名とサイズの一覧を生成し、ダイアログでフォント名の選択、そして、文字サイズの選択を実行。すると、該当箇所のみ抽出して返します。改行で区切ったテキストに変換するとかいった処理を行なってもよいでしょう。RTFのファイルを処理するのであれば、テキストエディットを使わなくてもCocoaの機能を用いて同様の処理を行えますが、割と書き捨てレベルの瑣末なScriptなのでテキストエディット経由で書式情報を取得するように組んでみました。Naganoya指定フォルダ以下のすべてのAppleScript書類(通常書類、バンドル書類)をSpotlightで検出して、各書類の冒頭に書いてあるヘッダーコメントをすべて書き換えて保存するAppleScriptです。MacOSの時代からやっていた記憶があります。AppleScriptをAppleScriptで書くとか書き換えるといった処理は、割と重箱の隅をつつくような(メーカー側も想定していないわけではないだろうけれど、そんなに検証してなさそう)ものなので、未知の問題に遭遇することの多いものです。安定して動作させられれば得るものも大きいです。CotEditorの配布用サンプルScriptをまとめる際に、ヘッダーコメント部分を統一する作業がなにげに大変でした。そこで、本Scriptを作成して一括してAppleScript書類のヘッダーコメント統一を行えるようにしました。60ファイル程度あるので、すべて手作業で書き換えるのは非効率的です(サンプルを書くよりも本Scriptを書くほうが時間がかかりました。一度書けば2度目以降は自動で処理できます)。EditorをコントロールしてAppleScript書類の書き換えを行っています。AppleScript書類自体の詳細な書式情報はCocoaの機能を用いて抽出しています。Editorをコントロールするメリットはありません(Cocoa側の機能を用いてScriptの修正と保存ができれば、すぐにでも本ワークフローから外したい)。AppleScriptの構文色分け書式にアクセスして構文要素を文字色で区分けしているため、本Scriptの実行環境で構文色分け書式がデフォルトのままとか、各構文要素の指定色でごくごく似たものがあったような場合には正常に動作しません。v4」になっているのは、コメントを追加するプログラムとコメントを削除するプログラムの2系統のものを別々に作って、最終的に「コメントを削除するプログラム」に機能を統合したためです。メインのScriptの内容のみ掲載していますが、(巨大な)ライブラリ入りのScript掲載は頭が痛いところです。実行して試せるということを重視してみました。NaganoyaフリーでScriptableなmacOS用PDFビューワー「Skim」上でオープン中のPDFで、選択中のテキストの内容を取得するAppleScriptです。フリーかつオープンソースで提供されているアプリケーションのうち、奇跡的に豊富なAppleScript対応機能を備えるPDFビューワー、それがSkimです。Skimに比べればPreview.appなど取るに足らない存在。「PDFビューワー四天王」のうち、その最上位に君臨するアプリケーションこそがSkimです(四天王とかいいつつ、Skim、Preview、Acrobatの3人しかいないのはお約束)。▲SkimでPDFをオープンし、「AppleScriptってなんだろう?」の文字列を選択ただ、そんなグレートな存在のSkimでも、「選択中のテキストを取得する」という処理を書いたことはありませんでした。Skimの「selection」によって取得されるのがテキストではなくRTFなので、AppleScriptの基本的な機能ではこのRTFはひどく扱いが難しいデータ「でした」。Cocoaの機能を利用することで、テキストへの変換は可能です。それでも、Cocoaが期待するRTFのデータとAppleScriptの世界のRTFのデータ同士の変換が難儀でした。食後の腹ごなしに行うには手に余るといったレベル。そこで、お気軽データ変換の最後の砦であるクリップボードを経由してRTFをAppleScriptの世界からCocoaの世界に受け渡してみたところ、大成功。あとは、PDFから取得したテキストデータによくあることですが、日本語のテキストだとUnicodeのNormalize方法の問題によりひらがな/カタカナと濁点や半濁点が分離した状態で返ってきました。これについても、Cocoaの機能を利用してNormalizeを行い、常識的なテキストに変換できました。Stanleyから「もっとシンプルに書けるよー」というサンプルが届いて脱力しました。簡潔に書けたようです(同一サンプルで日本語データに対してチェックずみ)。PDFから文字取り出ししたあとは、Unicodeの再Normalizeは割とやらないといけないケースが多いので、選択部分(selection)からRTFじゃなくてcharacterでデータを取り出せばよかったというあたりが反省点でしょうか。NaganoyaKeynote書類上のテキストアイテムを、内容の文字の実際の幅でリサイズするAppleScriptです。▲テキストアイテム中のテキストをコピー(Command-C)▲リサイズ前のテキストアイテム。文字に対してフレームサイズが大きい▲本Scriptによりリサイズした後のテキストアイテム。文字の内容に対してフレームサイズがフィットしている▲本Scriptにより順次複数のテキストアイテムを文字幅にリサイズしたところ。9.0で「selection」の予約語が追加されましたが、これは一般に期待されるような「表示中のスライド上で選択中のオブジェクトへの参照が取得できる」というものではありません。選択中のオブジェクトへの参照をKeynoteに対して問い合わせることは、(現時点では)不可能です。text)をコピー(Command-C)してクリップボードに格納し、その内容をキーにして現在表示中のスライド内のテキストアイテムを抽出してみたところ、うまくいきました(なんでこんなことさせられてるんだろ?)。早くselectionがKeynote上でもまともに使えるようになってほしいものです(Pages上ではけっこういい感じに使えるのに)。textのサイズに合わせてテキストアイテムをリサイズする処理を書いてみました。クリップボードの内容をNSAttributedStringとして取得し、その画面上の描画サイズを取得するサブルーチンは毎日さんざん使っているので(掲載リストのproperty宣言部をソートするのに使っています)信頼性があります。擬似的に現在選択中のオブジェクトを特定する実験コードにちょっとだけ機能をつけたものですが、操作1に対して結果1というのは普通「自動化」とか言わないので、実用性は皆無です(めんどくさい操作ステップを省けるぐらいしか)。Naganoya英語版の花文字テキストを作成してテキストエディタ(CotEditor)に出力するAppleScriptです。描画用の英単語と、塗りつぶし用の英単語を別々に指定できます。invertFをtrueに設定すると、白黒反転出力を行います。おおもとの元ネタは、大型計算機を大勢のユーザーで共有していた時代(ぱそこん登場前)、計算結果を高速プリンタの帳票に出力するようになっていたころにさかのぼります。どのユーザーの計算結果かを大量のプリンタの出力結果の中から仕分けるため、印刷出力の1ページ目をユーザー名などの情報を印字した「バナー」として使用。そのさい、ドットインパクトプリンターだったので、決められた固定ドット数の文字しか印字できないため、英数字を組み合わせて擬似的に大きな文字でバナーを印刷していたことに端を発します。その時代の「残り香」ともいえるバナーがパソコンの電子メールやBBSの時代にお遊びの「花文字」として引き継がれ、原始的なアスキーアートの一種として楽しまれてきました。commandの「banner」コマンドにその末裔を見ることができます。nativeのデモ時に「祝」という花文字を「呪」の文字で出力するという、定番の持ちネタを披露したところ、たいへんウケておりました。これを海外のScripter向けにそのままデモしても受けません。この、花文字テキストを出力するプログラムの英語版としては、love.scptといういにしえのデータをそのまま使いまわしたものがありますが、描画パターンを数値データで保持しているため、異なるパターンを表示させることはできません。そこで、日本語版の花文字テキスト出力プログラムに若干手をくわえ、英単語の出力が行えるようにしてみました。テキストの出力はCotEditorに対して行なっていますが、新規書類を指定文字で作成する程度なので、AppleScriptに対応しているテキストエディタならどれでも作り変えられます。表示を等幅フォントにしておく必要があります(あとから指定してもOK)。Naganoyaクリップボードにコピーしておいた書式つきテキストを、行ごとに画面上の描画サイズで昇順ソートし、再結合してクリップボードに転送するAppleScriptです。毎日使っているAppleScriptの改良版です。Cocoaの機能を呼び出すと、AppleScript冒頭にproperty宣言文を書くことになりますが(書かなくてもいいんですが)、この宣言文を「プロポーショナルフォントを考慮しつつ実際の画面上の描画サイズを考慮」して短いものから長いものにソートして掲載しています。これを、実際の指定フォントやサイズを考慮した行単位のスタイル付きテキストに分解し、描画幅でソートしたあとにスタイル付きテキストを再合成するようにしました。AppleScriptではスタイル付きテキストの操作は一切できませんでしたが、Cocoaの機能を活用することでこのように自由度の高い処理ができるようになった、という好例です。本ルーチンによって厳密に描画幅でソートしても、Web掲載時にはWebブラウザのレンダリングのルール(&ユーザー側で指定しているWebブラウザのフォント)が適用されるため、macOS上のアプリケーション上での見た目と若干違いが出るという残念な結果も出ています。macOS標準装備のスクリプトメニューに入れて呼び出しています。Naganoyaクリップボードに入っているテキストをAppleScriptとみなして構文確認を行い、AppleScriptの構文要素色分けを反映させたスタイル付きテキストを取得してクリップボードに入れるAppleScriptの改良版です。初版が(フォントサイズもオリジナルのままだったので)あまり(資料作成用には)使い物にならず、機能を追加してみました。クリップボード中の文字のサイズを取得しておき、クリップボード中のテキストをAppleScriptとして構文確認してスタイル付きテキストを取得したあとで、最初に取得した文字サイズに変更して、再度クリップボードに書き戻しています。テキスト(おそらくAppleScriptのプログラムあるいはその一部)をコピーした状態で本Scriptを実行します。スタイル付きテキスト(NSAttributedString/NSMutableAttributedString)のフォントサイズを変更するようなAPIが存在していなかったので、元のスタイル付きテキストを細切れに読み込んで、各種情報に分解。分解した情報をもとに(フォントサイズだけ変更して)同じものを再構成する、というやり方でスタイル付きテキストのフォントサイズ変更を行なっています。AppleScript自体にはもともとスタイル付きテキストを操作する機能は皆無なので、他のアプリケーションの機能を利用するか本ScriptのようにCocoaの機能を利用することになります。他のアプリケーションを操作しなくてもスタイル付きテキストを操作できるようになってきたことは、非常に意義のあることです。Naganoyaクリップボードに入っているデータを書式付きテキストとして評価して取得し、そのうち最大のフォントサイズを取得するAppleScriptです。クリップボードに入っているデータをプレーンテキストとして取得して処理することはよくやっていたのですが、書式付きテキストとして処理することはあまりやっていなかったので、試してみたものです。Naganoyaクリップボードに入っているテキストをAppleScriptとみなして構文確認を行い、AppleScriptの構文要素色分けを反映させたスタイル付きテキストを取得してクリップボードに入れるAppleScriptです。Keynoteの資料などでドキュメント(≒仕様書)を作っている途中で、AppleScriptのソース(の一部)を入れることがあり、間違ってプレーンテキストで載せていると読みにくくなります(個人の感想です)。そこで、プレーンテキストになってしまったAppleScript(の一部のデータ)を実際に構文要素色分けを反映させたスタイル付きテキストに変換してクリップボードに設定します。本Scriptでクリップボード内のテキストを処理し、Keynote上にペーストすると構文要素色分けが反映された状態になっています。Keynote上でダブルクォート(”)が自動で置き換えられてしまうので、その点のみScript内で置換を行なって構文確認を行なっています。macOS標準装備のスクリプトメニューに入れて利用しています。Naganoya指定のAppleScript書類からコントロール対象のアプリケーション名称をピックアップするAppleScriptです。指定のAppleScript書類からソースを書式付きテキスト形式で取得し、AppleScriptで処理しやすいように書式付きテキストをrecord化。一方でユーザー環境のplistファイルから、AppleScriptの構文色分け情報を取得します。application」のパターンを記述パターンを出現位置情報をもとに検出して、操作対象のアプリケーション名をピックアップします。"/Applications/Safari.app"}のような結果が返ってきます。アプリケーション名を変数に入れて操作対象アプリケーションを間接指定するようなケースは除外しています。指定しているものだけです。Signしていても初回は聞かれてしまうので。AppleScriptで操作対象のアプリケーションで、すでにコントロール許可が出ているかどうか「tccutil」コマンドで確認し、きちんと許可されているかを確認するとよさそうです。基本的な動作原理そのものが、スクリプトエディタ上で指定した構文色分けで重複色が存在していないことを前提にしているので、そのようにスクリプトエディタ上で指定してください。スクリプトエディタ上では16bitの色を指定しますが、実際には256色に落として判定するので、各構文要素に対する色は8bitに落としても差異が発生するような値で違いを指定しておく必要があります。Debuggerを終了させておいてください。Naganoyaスティッキーズ(Stickies.app)のデータをまとめて引っこ抜いてListに入れるAppleScriptです。色情報、1行目の内容をタイトルとみなしてタイトル情報も付加して出力するようにしてみました。オープンソースのStickiesViewerをFramework化したstickiesLib.frameworkを経由してデータを読み出します。データベースファイルから情報を直接読み取るので、Stickies.appが起動している必要はありません。colorName:”Yellow”}StickiesDatabaseからまとめて一括で全部抽出するので、個別に何かのIDで指定して抽出するといった動作にはなりません。93個のスティッキーズ書類(93個のウィンドウが表示されている状態、1つのDBを指定)から、全データを取得して本AppleScriptで0.1秒程度です。Naganoyaスティッキーズ(Stickies.app)のデータをまとめて引っこ抜いてListに入れるAppleScriptです。オープンソースのStickiesViewerをFramework化したstickiesLib.frameworkを経由してデータを読み出します。データベースファイルから情報を直接読み取るので、Stickeys.appが起動している必要はありません。~/Library/Frameworks/)昔はいろいろ苦労したような気がするのですが、あっさりデータを取り出せて驚きます。色情報も取り出していますが、色名を取り出すにはややScriptがおおげさになるので、とりあえず作成日、修正日、テキストを取り出してみました。Classのみをリストで取得するAppleScriptです。Classを抽出し、自動でタグ付けするために準備したものです。1記事に対して複数のAppleScriptが掲載されている場合にも対応しています。HTMLReader.frameworkを用いてBlog本文からのリンク抽出、リンクURL抽出を行っています。“NSUnarchiver”}のようになります。Proを有線ネットワーク接続した状態で、3.3〜3.4秒程度かかっています。大量の記事を処理する場合には本AppleScriptの並列処理を行うと処理時間の大幅な短縮が期待できます(MacのCPUがサーマルスロットリングで速度低下しなければ)。Boostが有効な状態で並列処理を実行すると、並列処理を行う意義そのものが低下してしまうため、Turbo-Boost-Switcherのようなツールの併用が必要と思われます。me–AppleScriptのソースをRAM上でコンパイル(構文確認)して、構文色分けしたRTFを取得。Classのproperty宣言が行われている内容をピックアップして、Blogのタグ用にカンマ区切りの文字列を出力するAppleScriptです。ローカルに存在しているAppleScript書類が処理対象なので、OSバージョンなど実行条件を満たしていればどのMacの環境でも実行可能です。Property名称)」の結果をカンマ区切りのテキストに変換するだけなので、そのルーチンを追加して呼び出しただけです。元になっているルーチン同様、AppleScript構文色分けの設定データ中に色の重複があるとエラーになります。一度もスクリプトエディタを起動していない環境では、設定ファイル自体が存在しておらず、エラーになる可能性があります。OSALanguageInstance”という結果が得られます。これをBlogへの投稿時に「タグ」欄にコピペで突っ込みます。すると、WordPressのタグに反映されます。Classの宣言のみ抽出するAppleScriptです。AppleScript書類を処理するAppleScriptです。スクリプトエディタをコントロールせず、plistから構文色分け情報を取得し、OSAScript経由でソースコードを取得し、メモリー上でコンパイル(構文確認)してリッチテキストを取得し、構文色分け情報にもとづいてproperty宣言を抽出します。Editorをコントロールしてもかまわないのですが)。構文色分け情報をもとに構文要素を判定するため、構文色分け色に重複しているものがあるとエラーにしています。RGB値で1でも違えば「別の色」とみなします。Class名を文字列化して取得できるので、早くも役に立っています。Class名のみを抽出すればよいでしょう。