Linuxのデスクトップとサーバーについて扱います。昨日はabenoriさん、明日はaminophenさんです。わたしとTeXTeX未経験でした。実は現在もTeXが書けません。必要な機能をWebから拾ってきて、スクリプトにしたあとはすべて忘れてしまったからです。この記事は備忘録ですらなく、TeXコミュニティの皆様に、TeXが使えないTeX無関係者はこのようにTeXを"使う"んですよ、多分。ご報告させて頂ければと思った次第です。TeXを何に使ったかRuneAMNというフォント製品で、書体見本誌の生成に使いました。説明しますと、RuneAMNはイラスト・デザイン向けのルーン文字フォントです。bellがリリースしており、フリー版と製品版があります。TeXを使ったのは、RuneAMNフォントの書体見本誌の作成作業です。RuneAMN_Freeリリース後、諸事情により作ったRuneAMN_Proを販売開始するにあたって、書体見本誌が存在することは重要でした。重要な点は、RuneAMN_Proフォントは計画当時から2015年現在までPixiv/BOOTHおよびGumroadて有償で販売されているデザイン製品であることです。公開・添付される書体見本誌も、本物のデザイナ・イラストレータが1600円を払う価値を認めてくれる、本物の書体見本誌でなければいけません。トレッキーなギークがプログラマ向けに作るAPIドキュメントのようなものでは駄目なのです。無地か灰色を背景に使い、コードが読みやすいという理由で等幅なConsolas書体を選び、小さな黒文字で書かれたドキュメントをKISSにつき良し、とするわけにはいきませんでした。(私はそちらのほうが好みなので、少しそういう要素を残してありますが)計画は単純です。・完全版にだけ挿入されているページなどが有る・書体見本誌はPDFで配布するが、印刷にも耐えるものでなければならないデザイン統一は見た目もありますが、労力を省くためでもあります。TeXをどう使ったかタイトルに反して、TeXをどう使わなかったかという話になりますが、結局、版組にはTeXを使いませんでした。実は、印刷可能なドキュメントの自動生成ということで、真っ先にTeXを検討しました。諦めることになりました。・欲しいようなデザインテンプレート的機能が見つからない(正直、拾ってきて適当にイジれば行けると思っていた)以上、生TeXが使えない状態では、ScribasなどのWYSIWYGエディタにも頼れませんでした。TeXが読めない私には、TeXエディタに背中を預ける勇気が持てませんでした。(特にプログラマとして"抽象化には漏れが有る"ことを知っている身としては余計に。アレの信頼性ってどの程度か教えて頂けませんか?)機械生成されたコメントも可読性も無い"生TeX"を読まされる未来がありありと想像できました。初心者がいきなりTeXで"デザイン"は敷居が高かったようです。『TeX初心者がいきなり製品デザインに突貫するなよ』という話でもありますが。結局、使い慣れたIllustratorで1ページ1ファイルとして作りました。AIで作ったPDFを、Webサービスで連結して見本誌を製本していました。コピー本を1冊ずつステイプラでとめるような微笑ましい作業工程ですが、プロフェッショナル製品の製造方法としては情けない限りです。最初のリリースはそれで済ませました。修正がある度に、23枚のPDFをアップロードし直すのはとても手間。次のリリースではPDFの合成をスクリプトで一発にしたかったので、TeXスクリプトの作成が最初から計画に入っていました。TeXにはPDFを操作する機能が一応ある。AIで作ったPDFはTeX生データほど構造化されていないわけですが。PDFファイルをページとして扱って、繋げるくらいのことはできます。作ったTeXスクリプトスクリプトと生成物が公開状態で置いてあると、説明が"読めば分かります"で済むので助かります。ドキュメントよりサンプル派です。Clause-2で公開しています。基本構成は、ベースTeXスクリプトからbash差分を生成して叩く仕組みです。bashスクリプトRuneAMN_Pro_Series_Fonts/scripts/books_build.shを起動すると、TeXスクリプトRuneAMN_Pro_Series_Fonts/scripts/mods/book_of_RuneAMN_Pro_Fonts.texを『製品版』『プレビュー版』書き換えて、書き換えたTeXスクリプトを上記bashスクリプトが叩く仕組みになっています。TeXはページ生成どころか加工すらせず、PDFの連結にしか使われていません。連結するファイルをスクリプトに直書きしているので、書体見本ページが増えると書き直しです。TeXスクリプト自体の書き換えも、TeXのモジュールを引数で変更するなどの知的な仕組みではなく、bashから正規表現でテキストファイルを操作する、いい加減なハックです。ゴーストスクリプトなどを使う予定はないので、PDFを生成した後は、中間生成物は不要ファイルとして削除しています。そのあたりの処理は、失敗した際にゴミが残ってしまう、いい加減なやっつけ仕事になっているので、いずれ修正したいと思っています。TeXをほとんど使っていませんね。エレガントに、同じことをする方法があると思いますが。して書体見本誌は完成し、RuneAMNは無事リリースされました。bell)におけるTeXの利用計画について。丸パクリ踏襲して『私たちの.NET戦略について』をいい加減に引き写しています。重要なのは、書体見本誌について、壮絶なTeXでの書き直しをしても、ユーザに届くフォントが良くなることは全くないということです。(ここまで来ると、本当にTeXアドベントカレンダーの記事なのかよ、という感じですが。)・なので、TeXに注力してしまわないよう気をつける。・既存のドキュメントには手を加えない・新書体にはファイルコピー&追加で対応する(気の利いたTeXスクリプトを書こうとしてはいけない)・デザインが更新されるまで、現状の連結スクリプトを使い続ける・新規フォント見本ページおよびドキュメントは(可能であれば)TeXで作る正直プログラマとしての自分が「Makefileでドキュメントが生成される」とか始めたら本筋忘れて傾倒すること必須な最大のリリース障害要因なので、次回バージョンのリリースまでは絶対に現在の構成で行きます。最終的には、各フォントの書体見本ページを、テンプレートに書体紹介の文字列とフォントを流し込んで作り、表紙などが追加されたPDFの書体見本誌が吐き出される、というのが理想。以下、アップデート案。・システムにインストールされていないフォントファイルを読みこませるこんな機能あるんですかね・ダウンロードでユーザが離れないよう、ファイルサイズが軽いPDFを吐く、あるいは変換して作る(もちろんダウンロード版と印刷版を別で管理するつもりは無い。教えて頂ければ嬉しく思います。以上、『TeXが使えないTeX無関係者によるTeXの利用例』でした。プログラミングGtk3でメニューバーを作成するGtk3アプリケーションを作るにあたって、メニューバー(Menu)を作った際のまとめです。Menu(写真はUbuntu/Unity環境であるためMenuが画面上部に付く)用語GtkではこれらのMenuの機能・要素を、以下のように呼びます。(Q)uit"),Alt+キーでMenu階層をたどることができる。Windowsの場合アクセスキー。これを指してアクセラレーションキーと呼ぶこともある。"Ctrl+Q")他に、MenuBarMenuItemSubMenuなどがあります。)しかし、gtk3-demoのmenusサンプルには、以下の問題があります。軒先の洗濯物と同じでただ垂れ下がっているものであるらしい。)・サンプルにはプレーンなMenuItemが含まれていない。keyが実装されていない・サンプル集の1要素なので、単体コードそのままでは動かない(小さなコードを追加する必要がある。)・Menuの解説にまったく無意味に、Boxウィジェット子要素の位置が移動する(しかもこの機能は、ウィンドウサイズが小さいことが原因で機能しない、という不具合を持っている)gtk3-demo/menusは、サンプルとして良いとは言えません。Gtk+にもサンプルコードが含まれていますが、古いGtkで書かれており参考になりません。)仕方がないので、menusサンプルやGtk3ドキュメントを読み解いて、自分用のサンプルを作りました。gtk3-demoが持っている上記の問題は解決させました。方法についてGtkにはMenuを実現する方法が複数あるようです。そのいくつかは既に非推奨であり、廃止予定の古い方法です。duplicatedhttps://developer.gnome.org/gtk3/stable/GtkUIManager.htmlhttps://developer.gnome.org/gtk3/stable/GtkActionGroup.htmlの方法は、廃止予定のようで非推奨になっています。代わりに、以下の組み合わせを使うようです。gtk_accel_grouphttps://developer.gnome.org/gtk3/stable/GtkMenuItem.htmlhttps://developer.gnome.org/gtk3/stable/gtk3-Keyboard-Accelerators.htmlGtkMenu機能のデータ構造Gtk3アプリケーションにおいて、Menuは以下の階層構造が構築されるようです。MenuBarはWindowではなくその中のBoxに配置されます。環境にて動作確認しました。導入しておく必要があります。-yただし、Ubutnu15.10環境では、サブメニュー以下のMnemonicsが動作しませんでした。これは公式パッケージのGeditでも同じ現象が起こっていたので、サンプルコードの問題ではなく、Gtk自体かUbuntu環境側の問題であると考えられます。Accelキーは例として、Help>AboutにCtrl+Aを割り当ててあります。radio_menu_itemは今のところ使う予定が無いので、下記サンプルコードに入れていません。国際化対応(日本語UI)も同じです。それらが欲しい方は、自分で調べてブログに公開して頂けると、私が喜びます。プログラミングGtk3でWindowに背景色を設定する現在、Gtk3を使ってウィンドウアプリケーションを作成しています。ところで、Gtk3ではWindow背景色の指定方法が面白いことになっていました。(Gtk3を使う側からすれば、あまり笑ってもいられなかったですが。)Gtk2までは、背景色の変更は以下の一行で済んでいました。deprecated)上の関数は非推奨(deprecated=将来廃止)になっており、代わりに使うよう紹介されている新しい関数が、こちらです。deprecated)名前だけでなく、引数のcolorがDdkColorからGdkRGBAに変えられています。面白いのはここからです。ドキュメントを見ればわかるように、Gtk3ではこの関数も非推奨になっています。代わりに『GtkStyleProviderを使って上手いことやれるようになりました!』とのこと。これまで一行呼びだせば済んでいた関数に対して、GtkStyleProviderは、そもそもどの関数を呼べばよいのかわかりませんでした。(多分setと名前に付いているやつだろう。何を引数に渡せば背景色が変わるんだ?)gtk3-demoを探しても、シンプルでコード量の短い背景色変更のサンプルが見つかりません。仕方なくGtkのMailingListに質問を投げたところ、Q:『もっと簡単な方法とか、CSSな方法のサンプルコードとかありませんか?』A:『現在のGtk3で背景色を指定するにはCSSを使う以外の方法はない。あと過去ログ読め』との返事が帰ってきました。(こちらがそのやり取り)実は、質問とは別に親切な方からメールが来て、その返答によれば「私が書いたサンプルがここにあるから参考にしてね」とのことでした。(多分過去ログとの重複でMLが汚れるのに配慮しつつ、気を回してくださったのだと思います。)そのURLはこちら:http://www.gtkforums.com/viewtopic.php?f=3&t=988&p=72088=GTK3+with+CSS#p72088つまり、Gtk3でWindow背景色を変更しようとしたとき、モダンな方法では一行のコードでは済まなくなったとのことでした。ライバルであるQtがHTML的なUIツールキットに舵を切る流れを追って、CSSライクな記法を採用するのはまあわかりますし、同じことができる古い関数を保守したくないのも良くわかります。これまで一行で簡単に出来ていたことが面倒になったのは事実で、少しばかり納得いかない気持ちになったりはしました。サンプルコード以下が、私が今のところ使っている、Gtk3のWindowで背景色を変更するコードです。プログラミングgtk3によるマウスカーソルの変更(落とし穴と解決策)gtk3を導入してアプリケーションを書いています。アプリケーション上で表示するマウスカーソルのアイコンを変更しようとして、落とし穴にはまったので、原因と解決策を紹介します。(原因、というほど大げさなものではありませんが)(画像にアイコンが無いのは単にgnome-screenshotの仕様)現象としては、gdk_window_set_cursor()関数を呼んでも、マウスカーソルのアイコンが変更されず、機能しません。出現するエラーメッセージは以下。コマンドライン実行すると確認できます。引数に必要なGdkWindowを正常に取得できていないため、変更に失敗する』ということのようです。Source以下がサンプルソースです。マウスカーソルのアイコン変更が機能することを確認できます。落とし穴である不具合は、下のマウスカーソル指定をコメントアウトして、上のコメントアウトを解除すると再現を確認できるはずです。任意の画像ファイル(透過png矢印画像)によるアイコン環境はUbuntu15.10-amd64です。ライブラリ導入はこちら。gtk+-3.0を絡めることになるかと。良いかんじに作ってください。サンプルソースの動作が確認できれば、あとは任意のGdkCursorを生成することで、マウスカーソルを思い通りの画像に変更することができるはずです。0;}===実際のアプリケーションでは以下のような感じで使っています。SHM-100U写真は加湿器を裏側から撮ったものです。以前から冬場は体調を崩しやすく、今年も冬が近づくにつれて、足の一部で肌荒れが出て痒くてたまりませんでした。薬を塗っても効果が薄かったため、今年は加湿器を購入することにしました。SHM-100U」を選びました。自室は、小さな鉄筋マンションの一室です。箱を開けると加湿器は紙製の支持材に入っています。取り出して確認すると、電源スイッチは裏側にあることがわかります。表にあるLEDで光っているボタンは「リセットスイッチ」であるようです。Web上のレビューによると「周辺が濡れる」という話があり、100均で適当な受け皿を買おうかとも思ったのですが、調度良いものが加湿器と一緒に入っていることに思い至りました。(※火災の危険などあると思います。)購入当初、裏側のリセットスイッチを使う頻度がわからなかったので、裏側の電源スイッチを表に置いて運用したら良いのではないかと思いました。今はまだそうしています。一晩運用するなら翌朝には自動停止しており、電源スイッチではなくリセットが必要になるので、正面に置いて電源は付けっぱなしにするのが良さそうです。推奨する使い方ではないのだと思いますが、動作させながらタンクを外して水を足すこともできます。私は慎重にやらないと周囲に水を撒いてしまいますが。タンクタンクは金属バネとゴム蓋による単純な仕組みです。台座の出っ張りからタンクの蓋を押し上げて開け、そこから重力で自然に給水する仕組みです。本体(蒸気の誘導ほか外した状態)実際の使用時間ですが、私の環境では公称の8時間よりすこし短い時間で水タンクを使いきっているように思います。一晩使うには、寝る前にセットしておけば、朝起きた時にはタンクの水をを使いきって止まっているので、それはそれで便利です。空気が乾いているかどうかは、私には体感ではわからないので、なんとも言えません。8時間弱動いていれば、9時間睡眠でもほとんどをカバーできるので、加湿器が常に動いていないと困る体質の方ということでなければ、この加湿器は良いと思います。複数画像の一括リサイズをコマンドラインで行う最小コマンド(ImageMagickのみ)複数の写真画像をリサイズする作業はたまに発生します。Linux環境だと特に、コマンド一発での処理を考えます。その度にGoogle検索でImageMagickの使い方を調べて、上位サイトの紹介するオプションを継ぎ接ぎしてい使っていたのですが。毎回調べるのは面倒なので、覚えられるよう最低限の長さにまとめました。*.JPGそれなりに必要性のあるオプションを追加して、以下を覚えると良いです。明度調整などのマトモな画像加工は諦めましょう。その都度調べましょう。パイプを使いこなしているなら良いのですが、find,grepをパイプしてxargsで流しこむ、なんて流れを画像変換のためだけに覚えるのは面倒かと思います。Gimpがコマンドラインからシェルスクリプトで使えたりすればよかったのですが、あちらは魔窟なので。mogrifyどう考えても同じImageMagickで"convert"のほうが覚えやすいですし、mogrifyでは通常は元ファイルが上書きされてしまいます。convertでは出力ファイル名が元ファイルを紐付けられない変なものになるので、すっきり諦めてmogrifyを覚えましょう。上書きには対象画像ファイルをまとたフォルダごとコピーして元画像をバックアップすることで対応します。下手に追加のコマンドを覚えるよりはるかに楽です。-stripEXIF情報を切り落とすオプション。ファイルサイズへの影響はともかく、当然付けておきます。jpg元ファイルが何JPGなのかわからないので標準的なjpg形式に。format指定で拡張子が変更になる場合、元ファイルが保持されるという嬉しい副作用もあります。96デフォルト92だという話ですが。デフォルト値があるならそれを使ったほうが良い派なのですが。これに関しては、写真によっては激しく劣化することがあったので。800x縦横比を保持するために横サイズのみ指定。*.JPG対象ファイルを一括指定する記法。ワイルドカードを使ったありきたりな指定で覚えやすい。ImageMagickで完結するし。Bootサーバを立てることができるpxe-pdhcpというソフトウェアがあります。今回はpxe-pdhcpで、Ubuntu14.04をディスクレスで起動させるまでの備忘録です。Bootによるネットワークブート環境を持っておくと、HDDを乗せないディスクレスクライアントを用意したり、ディスクドライブ無しでUbuntuなどのインストールができて便利です。ネットワークブート環境を構築したのは、10インチノートPCであるN10Jcを、Ubuntu14.04-32bitで動作確認するためです。(N10Jcは、EeePC的ノートPCでありながら、nVidiaのGPUを搭載している珍しい機体です。N270であり、32bit版OSしか動作しないため、他PCを64bit環境で統一していると、現在では運用が少しめんどうな機体でもあります。)こちらが、PXEでディスクレス起動するゲストPCになります。PXEサーバとなるホストPCは、普通の64bitシステムです。Furuhashi氏が書いたpxe-pdhcpを使用します。http://frsyuki.hatenablog.com/entry/20070926/p1基本の手順は、11.04での設定・手順を紹介しているこちらから。http://kimamahitori.blog.shinobi.jp/Entry/317/UbuntuディスクISOのマウントなどはこちらを参考にしました。http://blog.akagi.jp/archives/3391.htmlなお、こちらで紹介されているのはサーバUbuntu版で、今回ネットワークブートさせたデスクトップ版とはディスク内の構成が違う模様です。今回はデスクトップ版(LiveCD)の設定・起動方法を扱います。ネットワークブートの設定手順tftp最初にpxeのディレクトリを作成します。書き込み権限を付けておいたほうが、あとの作業が楽です。/pxeftpサーバを導入します。-y設定ファイルを編集します。/etc/default/tftpd-hpa以下の内容に書き換え。-vvv"RUN_DAEMON="yes"再起動して設定を反映します。restartnfsnfsサーバを導入します。-y設定ファイルを書き換えます。/etc/exports以下の内容を追記(設定はひとつにつき一行に書いて折り返さない)。ディスクイメージを、nfs上に展開します。下記の空ディレクトリを作成します。/pxe/images/ubuntu-14.04-i386ディレクトリにマウントします。(bootmenu)クライアントPCがPXE機能で読み込む、ブートメニューや必要なバイナリを、ftp上に展開します。ネットワークブート・メニュー表示に必要なバイナリを、以下から取得・配置します。http://www.kernel.org/pub/linux/utils/boot/syslinux/syslinux-4.04.tar.gz解凍し、中のファイルを以下のパスに配置します。/pxe/menu.c32/pxe/pxelinux.0ネットワークブートのブートメニューを以下に設定ファイルとして配置します。(IPアドレスは環境により適切に読み替えます。Furuhashi氏が作成したpxe-pdhcpをソースで取得し、ビルドして使用します。今回はroot直下に/pxe-pdhcpディレクトリとしてソースとバイナリを展開しました。https://github.com/frsyuki/pxe-pdhcpなお、いくつかのブログでバッファオーバーフロー警告に対するコード修正が紹介されていますが、今回はしなくても動作したので、とりあえずコードを書き換えていません。