macOSとスクリーンショット
備忘録というかメモ。
基本
基本的なやり方
- 画面全体:
Command
+Shift
+3 - 画面の選択範囲:
Command
+Shift
+4、カーソルの形が変化したらドラッグ - ウィンドウ単体:
Command
+Shift
+4、Spaceキーを押してからウィンドウをクリック - Touch Bar:
Command
+Shift
+6
撮影されたスクリーンショットはデスクトップに保存される(El Capitan以降)。
ウィンドウ単体のスクリーンショットを撮る際、esc
キーでキャンセルできる。
海外のサイトによると、次期macOS Mojaveでは新しいスクリーンショット用のツールが追加されるとのこと(Command
+Shift
+5)。
標準搭載のグラブ.app(Grap.app)というアプリケーション、QuickTimeを使う方法もある。
クリップボードにダイレクトにコピーしたいとき
スクリーンショットの撮影時にcontrl
を同時に押すとクリップボードに画像データが保存される。
- 画面全体:
Command
+Shift
+3+control
- ウィンドウ単体:
Command
+Shift
+4+control
他のキーを指で抑えた状態で最後に数字キーを押すとラクに操作できる。
ダイレクトに画像編集ソフトにペーストできて便利。
ウィンドウの影を消す
ウィンドウ単位でスクリーンショットを撮ると、ウィンドウの影のついた画像が保存される。
クリック時にoption
キーを押せば影のない画像が保存される。
マウスカーソルつきのスクリーンショット
グラブというアプリケーションを使えば可能。
- グラブを起動(面倒ならCommand+Space、grab.appと入力)
- Commad+
,
で設定画面を開く - スクリーンショットに入れたいカーソルの形状を選ぶ
スクリーンショットに関する設定
基本的にTerminal.appなど、コマンドを実行することで設定を変更。
SystemUIServerというバックグラウンドで実行されているプロセスの再起動が必要なケースと、そうでないケースがある。
保存先の変更方法
初期設定ではデスクトップに保存されるので少々不便です。
$ defaults write com.apple.screencapture location <path> $ killall SystemUIServer
defaults
コマンドで設定をを書き込み、killall
コマンドでSystemUIServer
プロセスを再起動。
設定したい保存先に合わせて
Web上の情報では基本的にはピクチャフォルダ(Picture)に保存する人が多い印象。
設定例:
$ defaults write com.apple.screencapture location ${HOME}/Pictures/
念の為、SystemUIServer
を再起動。
$ killall SystemUIServer
※ 環境変数${HOME}
がユーザーのホームディレクトリに展開される。
現在の設定はターミナルで以下のようにdefaults
コマンドにread
オプションを指定して実行すると確認可能。
$ defaults read com.apple.screencapture location
保存形式の変更
保存形式を標準のPNGから変更可能。
$ defaults write com.apple.screencapture type jpg
type
の値として保存形式を指定する。他の形式としては bmp、pdf、tiffなど。
試した限りでは設定の変更は即座に反映された。
ファイル名の接頭辞(文字列)の変更
ファイル名のパターンを完全に独自形式にすることはできない。部分的には変更できる。
$ defaults write com.apple.screencapture name 文字列
文字列の部分を自分で設定したいファイル名の接頭辞に変更。
元に戻したい場合は設定値を削除。
$ defaults delete com.apple.screencapture name
ファイル名に日付と時刻を含むかどうか
$ defaults write com.apple.screencapture include-date -bool false
この状態で連続でスクリーンショットを撮ると、ファイル名が「スクリーンショット.jpg」、「スクリーンショット 1.jpg」、 「スクリーンショット 2.jpg」という形式になる。連番の数字の前にスペースが入っているので注意。
元に戻したい場合は設定値の削除(または-bool true
として上記コマンドを実行)。
$ defaults delete com.apple.screencapture include-date
デフォルトを影なしにする設定
いちいち影なし・影ありをoption
キー切り替える必要がない場合は、設定で常時影なしにできる。
$ defaults write com.apple.screencapture disable-shadow -bool true
もとに戻す場合は値をfalse
にするか、パラメータ自体を削除する。
$ defaults write com.apple.screencapture disable-shadow -bool false $ killall SystemUIServer
または、
$ defaults delete com.apple.screencapture disable-shadow $ killall SystemUIServer
まとめ
mac関連の雑誌でもoptionキー同時押しで影なしのスクリーンショットが撮れるというTipsは紹介されていなかったと思う。
元ネタは海外のサイトからというケースが多いけど、海外のサイトはどうやってマニュアルにも公式サイトにもない情報を得ているのか不思議。 Apple社員がリークしている?
参考リンク
- macOS Sierra: 画面を撮影する
- OS X Lion: 画面を撮影するためのショートカット
- How to Control the Behavior of Screenshot Shortcuts in macOS - Mac Rumors
- Macでスクリーンショットを撮る方法と保存先&形式を変える方法 - Qiita
- macOSの一歩進んだ画面キャプチャテクニック - Qiita
- 作者: 井村克也
- 出版社/メーカー: ソーテック社
- 発売日: 2017/10/21
- メディア: 単行本
- この商品を含むブログを見る
[基礎知識+リファレンス]macOSコマンド入門 ――ターミナルとコマンドライン、基本の力
- 作者: 西村めぐみ,新居雅行
- 出版社/メーカー: 技術評論社
- 発売日: 2017/11/18
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
今週のふりかえり(2018年6月第4週)
雨は売っと惜しいけど、晴れの日に風が吹くといい感じ。
あと一週間で6月もおしまい‥…。
- 今週の学び
- 中国語に関して
- 最近の読めなかった単語など
- その他・ノウハウなど
- ソフトウェア開発関連
- Electron 入門
- apac
- 今週の思いつき
- 今週試したソフトウェア or サービス
- 読んだ本
- 気になった本、サイト、etc.
- 情報源
- 買わなかった本
- Software Design 2018年7月号
- 『Pythonプロフェッショナルプログラミング 第3版』
- 購入したもの
- アウトプット
- 今週の気づき&まとめ
「機械学習で男性エンジニアを女性に」という炎上案件について
いまいちコンテキストが理解できないのだけど。
その場に「いなかった人」がどうも文脈を把握しきれずに騒いでいる感じがする。
これ音声を機械学習で変換しようという技術についての発表ですよね?
女性エンジニアが少ないことと、機械学習は何の関係も無いのに女装写真とか変な前振りをつけているっていう。
悪気はなかったんではないかな。
研究の動機の話
男性の声を女性の声に変換するメリットについて、説得力のある説明ができなかったのではないかと思う。
なにか発表しろと言われて、音声の変換というネタはあるんだけど、イントロダクション部分がイマイチだった。 そこでだれかの入れ知恵か、無理にこじつけで「女性エンジニアが少ない」という話題にこじつけたか、笑いを取りに行ったのか。
学会発表向けのスライドだったら前後のロジックに無理がありすぎて普通にストップがかかるはず。
所属がYahooの中の人らしいのでだれか社内で止める人がいなくても不思議ではないのかも。
前フリと発表の対象技術がちぐはぐなのは確か。
アプローチがまずかっただけでは?
コナンくんの蝶ネクタイ型変声機ネタで攻めればよかったのはでは?
名探偵コナン メガジャンボ寝そべりぬいぐるみ 江戸川コナン 夏服Ver.
- 出版社/メーカー: セガ
- メディア: おもちゃ&ホビー
- この商品を含むブログを見る
女性エンジニアがいないと云々という言い回しが一種のセクハラ加害者的な発想と受け取ららたのかなという理解。
男性が女性の前で格好をつけたがるというのは割とよくある話で、とある企業のリストラの際に、あえて女性秘書を同席させたという話もある*1。
- 作者: 梅森浩一
- 出版社/メーカー: 朝日新聞社
- 発売日: 2003/06
- メディア: 単行本
- この商品を含むブログ (17件) を見る
確かに女性側からしたら不快なんだろうけど、本人は深い考えはなしに、男子校のノリで笑いを取りに行ったんだろうと思う。
技術的にどこまでのレベルか知らないけど、その場のウケを狙うなら、コナンくんネタで行けば良かったのにと思う。
軽度難聴の観点から
聴力低下の副作用で相手の声質によって極端に聞き取りにくい時がある。聴力低下によるダイナミックレンジの低下が原因なんだろうけど、 この声の変換技術、補聴器に組み込むとかそういう応用が期待できるという気がした。
むしろそういう笑いを取るネタではなく、真面目に実用路線でアピールして欲しかった。
お役人様から予算を引っ張るのに有効だよきっと。
職業名に「女性」という修飾語をつけることに関して
特定の職業において、性別に偏りがある、というのは多様性の問題。そもそも、エンジニアって性別に影響されない職業だと思っていたのですが、違うんですかね?
「女性〇〇」という表記がおかしいんではないでしょうか。
まずマスメディアが好んで使うそういう、「女性〇〇」っていう表記、それ自体が暗黙に普通は女性はこの職業には就かない、という偏見を助長していると思います。
男性看護師といえば違和感に気づくはずです。女性社長とか女性起業家とか、そうやって都合のいいときだけ「女性」を強調するし。
日本は言霊の国()らしいのでそこからちゃんとしないと。
まとめ
不適切な表現があったからと言って、技術の可能性をと切り捨てないでいただきたい。声質変換でググると結構ヒットするので技術的には 実績のあるテーマみたいだし。
音声系の技術は耳の悪い人間のQoLの向上とか、笑いを取る以外の応用を目指してほしい。健常者にはありがたみがわからないんだろうけどね。
やっぱりその場にいなかった人が大騒ぎして、拡散させているのは違和感ある。
- 作者: 篠田浩一
- 出版社/メーカー: 講談社
- 発売日: 2017/12/09
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
*1:男性は女性の前でみっともなく泣きわめきづらいという解説が書いてあった
Gimp 2.10.x macOS版について(McGimp 2.10)
本格的にロゴ画像作成にトライしようと思ってGimpをダウンロードしようとしたのですが……。
現時点ではmacOSの最新バイナリパッケージはまだ提供されておらず。
Gimpの最新の安定版はバージョン2.10.x系列。
代替手段
おそらく正解は公式パッケージがリリースされるまで旧バージョンを使う、です。
- MacPorts経由でインストールする
- 自力でビルドする
- 非公式バイナリを使う
- テスト用のパッケージを使う?
公式サイトでの旧バージョンのダウンロードページへのリンクはなくなっているようです。ただ、ファイルはサイト上に残っています。
非公式バイナリとしてMcGimpというものが比較的名前が知られており、安定しているようなので公式パッケージが提供されるまで試験的に使用しています。
なお、Homebrew Caskに旧バージョン及びMcGimp 2.10のパッケージはありますが、Homebrew 本体にgimpという名前のパッケージはありません。
macOS版Gimp 2.10 (McGimp)
公式開発チームによるパッケージではない点に注意。新機能を試したい人向け。自己責任で。
下にスクロールすると右側のサイドバーにダウンロード用のリンクがあるのでそこからダウンロードする。
なお、旧バージョンとはパッケージ名が異なるので共存可能です。
Homebrewを使う場合は、Homebrew Caskにmcgimp-std
というパッケージがあります。
メニューは日本語化できるようですが、日本語の入力はできないようです。
McGimpの日本語化
初期状態では英語メニューなので"Interface"というカテゴリから表示言語を変更してGimpを再起動すると日本語になります。
画面左上のメニューから"Preferences"(または
Cmd+,
)をクリック
左側のメニューから"Interface"というメニューを探してクリック
"Language"を"System Language"から”Japanese”に変更
一度、McGimpを終了して再起動
OSの言語を自動認識されないのはちょっと疑問ですが、以前のInkscapeのようなファイルの書き換えは不要です。
そのほか
旧バージョン
公式ページにリンクがないですが、サイト上にファイル自体はあります。2.8.22の、ファイル名の末尾が.dmg
になっているファイルです。
なお、Homebrew Cask でbrew cask install gimp
とすると2.8.22がインストールされるようです。
テスト版
ファイルは存在するのでテス中?。おすすめしません。
Index of /pub/gimp/v2.10/osx/testing
興味があればバグトラッカーをチェックするといいかも。
Issues · GNOME / GIMP · GitLab
自力でのビルド
試していませんが、必要なファイルとツールは下記にあります。
samm-git/gimp-osx-package: FIles required to build standalone gimp 2.10 package for osx
まとめ
InkscapeよりはGimpのほうがmacOS版の扱いは優遇されている印象でしたが現状を見るとどっこいどっこいな印象。
ただ、InkscapeよりはXQuartz不要のGimpのほうがマシかなとは思います。
そもそも、Gimp関連書籍がバージョン2.8系を対象にしているので、旧バージョンを使うほうが無難かも。
できるクリエイター GIMP 2.8独習ナビ Windows&Mac OS X対応 (できるクリエイターシリーズ)
- 作者: ドルバッキーヨウコ,オブスキュアインク,できるシリーズ編集部
- 出版社/メーカー: インプレス
- 発売日: 2013/02/22
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (4件) を見る
GIMP 2.8 スーパーリファレンス for Windows&Macintosh
- 作者: 野沢直樹
- 出版社/メーカー: ソーテック社
- 発売日: 2012/08/04
- メディア: 単行本
- 購入: 2人 クリック: 4回
- この商品を含むブログを見る
財務省の公開した交渉記録PDFをいじる その3(本件終了)
一応切りの良いところまで作業したのでここで終了。
プログラムは汚いので載せてないです。
フォーマットが微妙に違うなどの数々のトラップによりかなりの部分を手作業で治すハメに。自分で作ったページ範囲データの不備のせいでさらに無駄な苦労があったりと、見事に自業自得。
Google Cloud Vision APIのOCR機能の、認識ミスのパターンについて知見が深まったのでその点はプラスだったかな、と思っています。
自分で後で振り返るためのメモ的側面が強いのであまり役に立たないかな、と思います。
方針
過去記事の方針のまま。
- 目次のPDFから交渉記録(応接記録)を機械可読(Computer Readable)な形式に変換
- マスク無しのPDFを画像化、再度PDFに変換して過去記事で紹介したAPIでOCR
- 目次のページ番号から必要なページを割り出して、OCR結果を分割、どうにして添付資料のページを除去
- どうにかしてMarkdown化
- 静的ページジェネレーターでWebページ化
成果物
Netlifyで公開しています。
OGPとか検索機能とかそのへんは気が向けばどうにかするかも。
備忘録
あまり再現性のない情報ですが載せておきます。
方式検討
- まず交渉記録の個別の文書のタイトルを特定
- タイトルより上にある機密文書指定などの補足情報は捨てる
- 応接方法として記録されている情報はカテゴリ情報に使う
- 極力、インデントなどの情報は残す
- ある程度は妥協してエディタで修正する
- 80点主義で行く
JSONのパースに関しては過去記事参照。
プログラムそのものは微妙な上にバグっていたので自粛。一部の処理のみ。
Markdownの生成
公式ページを参考にして、front matterと呼ばれるメタデータをYAML形式でファイル冒頭に記述する。
具体例は下記のとおり。
--- title: 利用要望照会中財産について date: 2013-06-28 14:15:00 categories: ["応接記録", "来訪"] tags: ["園長", "籠池", "土壌汚染", "地下埋設物", "大阪航空局", "ティーズレボ", "森友学園", "塚本幼稚園", "大阪府", ""] ---
JSONをパースして値を取り出して、string.Templateで値を埋め込む。Markdwonで書式を再現できない部分はHTMLタグを使う。
HexoのMarkdownは「はてなブログ」のそれとはちがって空白行を保存するタイプなので無駄な空白行は除去する必要あり*1。
参考:Pythonで、string.Templateを使う - naritoブログ
各記事のタグに関してははかなり偏ってしまっているのは反省点。要するに途中で力尽きた……。
正規表現関連メモ
なぜかあまり言及されないことが多いが、Python 3.6から正規表現のマッチした結果の文字列に配列のインデックスでアクセスできる。
import re m = re.match(r"(\w+) (\w+)", "Isaac Newton, physicist") m[0] # The entire match # 'Isaac Newton' m[1] # The first parenthesized subgroup. # 'Isaac' m[2] # The second parenthesized subgroup. # 'Newton'
Pythonで正規表現のパターンとして漢字何文字とかひらがな、かたかなという文字の種類でマッチさせたいときはregex
を使う必要がある。
標準の正規表現モジュールではRuby 2.x系のようにユニコード文字プロパティを使えないです。
Rubyとは(残念ながら)違うのですよ‥…。
正規表現での漢字マッチをUnicodeプロパティーを使って綺麗に書く方法 in Python
正規表現まわりはRubyのほうが優位性はあるかなと思います。
Hexoカスタマイズなど
テーマはデフォルトのまま。細々と修正しています。
設定ファイルの修正箇所
タイトルなど基本的な部分は省略。
index_generator: path: '' per_page: 10 order_by: dat default_category: uncategorized category_map: 応接記録: reception 来訪: came 訪問: visit 架電: call 受電: receive その他: other 情報: note archive_generator: per_page: 10 yearly: true monthly: true daily: false order_by: date theme_config: google_analytics: UA-120720274-1 show_count: true widgets: - category - tagcloud - archive - tag menu: Home: / Archives: /archives About: /about
ページの表示順を通常と逆順にするため、index_generator
とarchive_generator
の両方にorder_by
オプションを指定しています。
テーマのカスタマイズ
- themes/landscape/source/css/_partial/custom.styl
- themes/landscape/source/css/style.styl
- themes/landscape/source/css/_variables.styl
- themes/landscape/layout/_partial/article.ejs
CSSについてはcustom.styl
というファイルを新規作成してそこに記述。style.styl
から読み込む。末尾の#more
の除去。バナー画像の変更など。
参考にしたサイト:Hexoでトップページに記事の概要を出す方法 | Katsunori Nippo
リスト要素のスクロール
div
で囲む必要あり。
横並びにした時に、改行せずにスクロールさせる方法 - Qiita
OCR APIの認識ミスの傾向
頑なに丸囲み数字を認識しないGoogle。①とか④を「の」と認識されても困るんですが……。「〃」も認識してくれないね……。
- 段落の頭の字下げによる空白を"「"と認識するミスが多数。
- 行末に不要な"」"や”)"が追加される
- 単語辞書による補正のせいで変な認識をする時がある -「□(四角)」を「口(くち)」と認識したり、「■」の認識に失敗していた地味に面倒。
- 「数量等」の「等」が認識されない
- 「架電」が「書架」+「電」のように認識されるケースあり(辞書補正の弊害か?)
- 「藪」というを認識できず
- 「㎡(平方メートル)」は「m」と認識*2
- 「以 上」の間のスペースが何故か改行(\n)になるケースがある(JSONの
"detectedBreak"
の値がおかしい)
「のの」など「の」が連続している場合、正しい認識結果として「①の」とか「②の」だった可能性を考慮すべし。
目視でチェックして認識されない可能性のある文字、記号類は事前に当たりをつけておく必要がある。ただし、全く認識されないわけでもなく、②や③をそれぞれ、2、3と認識するケースもある。
また、水平方向の罫線があっても、間にスペースが空いていると行の一部とはみなされず、独立した文字の塊という扱いになる。 水平方向より縦方向に隣接した文字の領域があればそちらを優先してブロック扱いする。
交渉記録文書のフォーマットに関して
先方/相手方といった書式の違いだけでなく順序が違ったりとか。「以上」だったり「(以上)」だったり地味にトラップ多し。
特に時刻の表記はかなり厄介で途中で諦めた。
お役所なのに内部文書のフォーマットは意外とフリーダム。ただ、議事録としては外部の人の名前を先(ページの上部)に書く、と教わったのでその辺は大丈夫か、という感じ。
何はともあれ書式は統一していただきたい。
反省点と今後の課題
兎にも角にも前処理重要。それと仕事が遅すぎ > 自分。
ちょっとめんどうではあるけど、JSONの時点で認識ミスをピンポイントで補正してもよかったかも。
JSONビューワー件エディタのような治具?というかユーティリティが必要。
結論:横着はダメ
今後の課題
傾き補正、ノイズ除去、領域分割。あとはに印刷文書に手書きでメモが入っているパターンをどうするか。
所感など
もうやだこの連中。不当要求ですよ不当要求。
すぐに思い出すだけでも昼休みに押しかけたり、仕事に愛がない?とか仕事に命をかけろとかと罵詈雑言とか。
もし自分が近畿地方局の人間だったら余裕で退職届書いて精神的苦痛を理由に訴訟ですよ。
売却金額をはじめから公表したりとか、そもそも大阪府が認可しなければ……とか、寄付金の水増しを見抜いていれば、とか まあ思うところはたくさんあります。
公務員だって人間。教育勅語は罵詈雑言を奨励していなかったはずです。
次は陸自のイラク日報のような、救いのある公文書にトライしたいところ。
まとめ
ちまちまと作業しているうちに一ヶ月経過していたり、追加で文書が開示されていたりと微妙な展開。
まあPythonに対する習熟度の向上という点ではギリギリ有益だったかと。GoogleのOCRエンジンについては画質が悪いので多少の認識ミスは仕方がないのかという印象。
交渉記録に関してはせっかくなので感想文のようなものを書こうかなと思います。