WordPress に記述できるプロトコル(スキーム)を拡張する

Jabber/XMPP, WordPress, , コメントを残す

WordPress の記事の中などでリンクを記述する場合、特定のスキームしか書くことができません。たとえば http:// や mailto: は書くことができますが、git:// や skype: などと書こうとしても、自動的に削除され、http:// とみなされてしまいます (管理者権限で記事を書いている場合は適用されず、自由に書くことができます。権限が編集者以下の場合です)。

調べてみると、WordPress 3.3 からこの制限は wp-includes/functions.php の wp_allowed_protocols() に書かれています。そこを見てみると、スキーム名を追加するには kses_allowed_protocols というフックを使えばよさそうです。

いま xmpp: というスキームのリンクを記述したいので、テーマの functions.php あたりに

function ext_protocols ($protocols) {
  $protocols[] = 'xmpp';
  return $protocols;
}
add_filter('kses_allowed_protocols', 'ext_protocols');

と書きました。これで記事中にxmpp:mako@pasero.net や xmpp:なんでも談話室@muc.step.im?join などのリンクを記述できるようになりました。

カタカナ表記について—マイクロソフト スタイルガイド

ことば, コメントを残す

参考資料として。マイクロソフトスタイルガイド

手軽に参照しにくいので、ここに要点のみをメモ。

次の場合の「か」はひらがな書きとする。カタカナは使わない。
例:「3 か月」 (「3 ケ月」「3 ヶ月」「3 カ月」「3 ヵ月」としない)
次の場合の「こ」は漢字とする。カタカナは使わない。
例:「5個」 (「5 ケ」「5 コ」としない)

長音符号

まず規準は、平成3年6月28日 内閣告示第2号「外来語の表記」
英語の末尾が -er, -or, -ar のとき、長音符号を付ける
英語の末尾が上記以外(すなわち、-y も)の場合、
カタカナが4字より短い場合(促音「ッ」は1と数える。拗音は数えない)、長音符号を付ける
  • 例:「キー」「メニュー」は付ける。「メモリ」「プロシージャ」は付けない
  • 英語が接頭語+語幹の場合、語幹で考える。例:「プレ+ビュー」「サブ+ツリー」「インター+フェイス」
  • 上記の例外は一覧表を参照

フォントの指定をやめる

WordPress, ソフトウェア, , , 2件のコメント

久々に Windows を使う機会があって、この自分のページを見てみた。見難い。醜い。明朝体の表示がこうも汚いのは何かの陰謀だろうかと思えるほどだ。WordPress のテーマのカスタマイズの記事などで「まずゴシック系を指定して」という記述をよく目にするのはこういう訳だったのかと今更ながら思った。

身の周りにある本らしい本を見てみれば、見出はともかく、本文はたいてい明朝 (serif) 系ではないか、という信念で、この自分のページは明朝 (serif) 系で表示するようにしていたのだが、こんな表示では逆効果なのであった。Windows の設定をいろいろいじればもう少し何とかなるのかもしれないが、普段からしっかり使いこなしている訳でもないから、簡単にできることではなさそうだ。きっと大多数のユーザーもそんなものだろう。

さて、ではなるべく多くの人にきれいに見せるにはページの制作側では CSS での font-family をどう設定したものか、と考え始めた。いろいろ探しまわって考えているうちに、もうそういうのはやめて見る側にまかせてしまえばいいや、という気になってきた。

Vista以降の人は見慣れたメイリオで。
XP以前の人は見慣れたMSPゴシックで。
メイリオが気に入った人は、メイリオで。
Macの人はヒラギノ角ゴで。
明朝が好きな人は、明朝で。
へた字とか好きでたまらない特殊なフォントで。
(流儀　font-familyは指定すべきか)

WordPress 関連のページを見る機会が多くデザインを重視する記事をたくさん見ていたのですっかり忘れていたけれど、そもそも HTML というのは、見る側の環境によって違って当たり前なのだった。

「本文は明朝系」という信念の人 (私だ) はブラウザのデフォルトを serif に設定しているだろうし、Windows でも自分の好みの表示になるようにがっちり設定している人には、そのフォントで読めるようにしてあげればいいではないか。

という訳で、このページの本文の font-family の指定はやめることにした[1]。フォントに限らず横幅も何も、本来は見る側の自由なのだという気にだんだんなってきた。

  1. このページは coraline というテーマの子テーマで表示している【注:記事執筆時】。親テーマで font-family が指定されているので、子テーマでこれを消去はできず、そこで存在しないであろうフォント名を指定して上書きしている。
    body, input, textarea {
        font-family: undefined;
}
    ↑

どうしよう日本語入力システム (その2)

Debian, ソフトウェア, , , 1件のコメント

昔の話をするようになったら歳をとった証拠だ。が、いきがかり上、しばらく昔の話を書いてみよう。

日本語入力システム自分史

UNIX 期

Wnn を使い始めたのは学生だった 1991年頃だ。その前には NEC の PC98 で少しのあいだ ATOK を使っていた。確か「一太郎 Ver.3」だったから、いま調べてみると ATOK6 か ATOK7 だったことになる。

そこに Sun SPARCstation 2 というワークステーションが研究室にやってきて、X Window system で日本語を入力するのに Wnn を使い始めた。確か X11R4 や R5 だったので、これもいま調べてみると、それらに標準添付されていた Wnn 4.1 や Wnn 4.2 を使っていたことになる。その頃にあった別の日本語入力システムの Canna や Sj3 は使ったというより試してみた程度だった。

その後使った HP のワークステーションの HP-UX に VJE だか ATOK だかが付属していたと思うが、このワークステーションはほとんどリモートで使っていたので、日本語入力システムに触れることは滅多になかった (もう当時のバージョンがいくつだかも忘れてしまった)。

Wnn 4.2 の頃はいろいろと情報が出回っていて、辞書を追加したりパラメータを調整することで、標準の状態よりかなり変換精度を上げることができた。

世間で Windows 3.1 や Windows 95 が大流行している頃、私は Sun SPARCclassic を独占してデスクトップで使えるという環境にあったため、その時期を Windows と無縁で過ごした。その後ノート型を含め、いわゆる PC/AT 互換機も使うようになった頃には既に Linux が入手できたため、そこでも Windows を使わずにすんだ。そんな職場を離れたあとも今日に至るまで、トータルで 20 年以上もコンピュータを毎日使っていながら Windows も Mac も常用したことがないという、たぶんかなり珍しい部類の人となった。

Linux-Wnn 期

1997 年、Wnn 6 for Linux/BSD が発売されるとすぐに購入した。UNIX 版はその前に出ていたが普通に買える価格ではなかったし、その頃には Sun SPARCclassic は既にサーバーとして裏にまわり、Debian をインストールした PC をデスクトップで使っていた。

Wnn 6 は、それまでのバージョンがフリーソフトだったのに対し、商用ソフトであった。「Ｗｎｎについての基礎知識」のページの中ほど、「＊Wnn6 で強化された機能とは」の項にあるように、20万語のシステム辞書、「フレキシブル・インテリジェンス(Flexible Intelligence)機能」により、変換精度は格段によくなった。

2001年、Wnn 7 for Linux/BSD が発売になり、これもすぐに購入した。

ATOK 期

2005年に Wnn 8 が発売になった際には、Wnn 7 で十分満足していたので購入を見送った。UTF-8 への対応というのが大きな変化だったが、その頃はまだ EUC-JP で使い続けていたので、その必要性も感じなかったのだ。その後 2009年に、別の会社から、その時点の ubuntu に対応したという Wnn8 for ubuntu というものが発売されたが、ほぼ1年で販売を止めてしまったようだ。

これらを購入しなかったことを後悔する時がやってきた。2010年頃には、(1) OS のライブラリが新しくなり、依存関係を改変しないとインストールもできなくなってきた。いつか本当に起動しなくなるかもしれない。(2) 最近は UTF-8 でしか動かないアプリケーションがいくつか出てきたが、Wnn 7 (xwnmo) は locale を EUC-JP にしなければならないため、日本語を入力できない。(3) 開発元の情報を見ても、この先、新しいバージョンが出る気配がない。という状況になってしまった。

OSS の Anthy を試してみたものの、あまりの使い勝手の悪さに 1週間ほどで嫌になってしまった。

そこで思い切って ATOK X3 を購入することにした。ATOK X3 は 2007年の製品で、既に時代遅れぎみだが、こちらも次がいつ出るのか(そもそも次はあるのか)見えないので、思い切ることにした。

ATOK X3 が悪いとは言わないが、何しろこちらが Wnn に慣れきっているため、不満に思ってしまう点はいくつかあった。

変換精度が思ったほど高くないと感じるのは、長いあいだ学習させてきた Wnn7 と比較しているからだろうか。それを割り引いても 2001年の製品である Wnn7 のほうが「賢い」ように感じられた。

それに、異体字(いわゆる旧字)を簡単に出せない。Windows 用の新しい ATOK には異体字変換があるようだが、Linux 版 の ATOK X3 にはその機能がない。Wnn7 には標準で「異形字変換辞書」を持っており、いったん仮名から漢字に変換したあと(たとえば「けいざい」→「経済」)、漢字から異形字(「経」→「經」、「済」→「濟」)に変換する、単漢字変換の一種ともいえる機能があった。とりあえず「正字正假名辭書」を追加してしのぐことにしたが、これは単語レベルの辞書なので、登録されていない単語(人名など)で旧字を出したいときにはやはり苦労する。

発売直後から指摘されている不具合が未だ放置されているなど、開発元のやる気のなさも心配だったのだが、前の記事にも書いたように、たった1年ほどで終わりの時が近づいてきたようだ。


結局、20年ほどの日本語入力システム自分史を振り返ってみると、最近1年の ATOK X3 を除いて、なんと19年が Wnn (そのうち10年ほどが Wnn7) というものであった。

この項さらに続く(たぶん)。

WordPress で Google マップを使う (再挑戦)

WordPress, , コメントを残す

以前に「Google マップを使う」を書きましたが、その後 WordPress も Google マップもずいぶん進化して、時代遅れになってしまいました。

意図してる使い方は次のようなものです。

  • 固定ページに位置情報を持たせる。その固定ページにマップが表示される
  • それらのインデックスとなるような、上記の各ページにリンクされたマークが表示された全体図が、別の固定ページがある

たとえば、会社案内のサイトで各支店ごとに固定ページを作り、それぞれに案内地図を掲載し、「支店一覧」の全体図が別にもうひとつある、というイメージです。Lightweight Google Maps はほぼ条件を満たしていますが、その便利な機能がこちらの思惑には合いませんでした。

ざっと探してみましたが、「固定ページに位置情報」というものはなかなかありません。そこで、固定ページではなく投稿に、というプラグイン RomeLuv Google Maps for WordPress を見つけたので、それを改変することにしました。

RomeLuv Google Maps for WordPress を改変

--- romeluv-maps.php.orig
+++ romeluv-maps.php
@@ -51,6 +51,12 @@
         'romeluv_maps_inner_custom_box',
         'post'
     );
+    add_meta_box(
+        'romeluv_maps_sectionid',
+        __( 'Maps', 'romeluv_maps_textdomain' ),
+        'romeluv_maps_inner_custom_box',
+        'page'
+    );
    
 }
  
@@ -361,6 +367,7 @@
 }
  
 add_action('save_post', 'romeluv_maps_handle_savepost');
+add_action('save_page', 'romeluv_maps_handle_savepost');
  
  
  
@@ -385,7 +392,7 @@
         if ($romeluv_single_map_done) return $post_content_html; else $romeluv_single_map_done=TRUE;
      
      
-       if (!is_single()) return $post_content_html;
+       if (!is_single() && !is_page()) return $post_content_html;
         //return "".$post_content_html;
        global $wpdb,$post,$mapheight;
        $savepost=$post;
@@ -552,13 +559,25 @@
      
     global $wpdb,$post;
     $savepost=$post;
+
      
+    extract( shortcode_atts( array(
+          'cat' => '', // category ID
+       ), $atts ) );
+       if (esc_attr($cat) == '') {
+         if (isset($_GET[cat])) $get_cat = $_GET[cat];
+       } else {
+         $get_cat = esc_attr($cat);
+       };
+
+
+
     ////query all the posts to display on the global map
      $querystr = "
        SELECT wposts.*
        FROM $wpdb->posts wposts
        WHERE  wposts.post_status = 'publish'
-       AND wposts.post_type = 'post' ". $whereadditional ."
+       AND (wposts.post_type = 'post' OR wposts.post_type = 'page') ". $whereadditional ."
        ORDER BY wposts.post_date DESC
     ";
     //echo $querystr; //useful for debugging your custom query
@@ -571,9 +590,7 @@
      
     if ($result_posts):
      
-    if (isset($_GET[cat]))  echo '<h3 id="map-category-heading">'.get_cat_name($_GET[cat]).'</h3>';
-   
-   
+    if (isset($get_cat))  echo '<h3 id="map-category-heading">'.get_cat_name($get_cat).'</h3>';
      
     $mapwidth=get_option('global_romeluv_mapwidth');
     $mapheight=get_option('global_romeluv_mapheight');
@@ -614,7 +631,7 @@
                             
                              $count++; 
                             
-                           if (isset($_GET[cat])) if (!in_category($_GET[cat],$post->ID)) continue; //this allows category filtering adding the $_GET parameter ?cat=xx
+                           if (isset($get_cat)) if (!in_category($get_cat,$post->ID)) continue; //this allows category filtering adding the $_GET parameter ?cat=xx
                             
                            if (is_category()) { if (!in_category($cat_ID,$post->ID)) continue;  }   //skip posts if viewing a category page, if those do not match the current category
                            

改変の内容は、

  • 固定ページの作成画面にも「Maps」の入力欄を表示する
  • 全体図の出力の際に固定ページも対象にする
  • 全体図を出力するショートコード [GLOBALMAP] に、オプションcat を追加する

です。この最後の項目は次のような事情です。

このプラグインのオリジナル版では、全体図を表示させるには、固定ページでショートコード [GLOBALMAP] を用います。特定のカテゴリーに属する投稿だけを全体図に表示するという絞り込みができます。その方法は、カテゴリーの ID をパラメータで付加して、http://www.example.com/map?cat=6 のような形で、全体図のページを呼ぶようにします。

しかし、WordPress 標準のメニュー機能でこのような形式のリンクを作る方法が思い浮かびません。そこで、むしろ複数の全体図のページを用意することにして(たとえば http://www.example.com/map1 と http://www.example.com/map6)、それぞれのページでのショートコードにオプションでカテゴリー ID を付けるようにしました(たとえば [GLOBALMAP cat="1"] と [GLOBALMAP cat="6"])

さて、ここでは固定ページに位置情報を付加して、全体図を作ることを想定しています。すると固定ページにもカテゴリーが設定されていないと、上記の絞り込みができません。テーマの functions.php か何かで

function add_category_to_page() {
    register_taxonomy_for_object_type('category', 'page');
}
add_action('init', 'add_category_to_page');

とやって、固定ページにもカテゴリーを設定できるようにしておく必要があります。

twentyeleven で Google マップが壊れる

実際に使用してみると、表示される地図が微妙に壊れていました。タイルの継ぎ目が合わずに道や川がずれているような感じになります。はじめ、自分が使っているブラウザか何かの環境のせいかと思って、いろいろ調べましたがわかりません。ようやく、テーマ twentyeleven にすると壊れて、twentyten にすると正常に表示されることに気がつきました。それから今度は twentyeleven のスタイルシートのどの記述が影響しているのか順に見ていき、ついに img に max-width が付いているとこの現象が起こることがわかりました。これだけで随分と時間を費やしました。

このプラグインの影響下の img のみ max-width を解除するため、

div#romeluv-global-map img,
div#single-post-map img {
        max-width: none;
}

をスタイルシートに書いて、解決しました。

Firefox での印刷時の背景色

ソフトウェア, , コメントを残す

Firefox (Iceweasel) で、背景色を白以外(薄い灰色)に指定して使用している。プリンタへの印刷の際には「背景色を印刷しない」設定ができる。そのはずなのだが、しばらく前からこれが印刷されるようになってしまっていた。

検索してみて、もじら組フォーラムから Bug 652914 という情報にたどり着いた。いまだ解決されていないようだ。背景色を白以外に設定していて、かつ、プリンタに印刷することのある人というのはかなり少数なのだろうか。

自分の userContent.css に

@media print {
        * {background-color: white;}
}

と書いたら、とりあえず背景色は印刷されなくなった。この程度で回避できるくらいなら、すぐにも修正されそうな気もするのだが。

どうしよう日本語入力システム (その1)

Debian, ソフトウェア, , , 1件のコメント

Debian sid (i386) で、libgtk2.0-0 を 2.24.5-4 にアップデートしたら日本語入力システム ATOK X3 が使えなくなってしまった。2.24.4-3 に戻せば使える。そのあいだのバージョンではどうだかわからないが、いずれにせよ、ほかのアプリケーションとの兼ね合いで libgtk をそのままにしておくわけにもいかないだろうから、ごまかしておけるのも時間の問題だ。

そもそも、それまでずっと使っていた日本語入力システム Wnn7 が、やはりライブラリ (や、日本語文字コード) の問題でうまく動かせなくなり、その代わりにしかたなく ATOK X3 を使い始めたのだった。今度もまた本質的ではないと思われるライブラリの問題で使えなくなるとは非常に残念である。このへんが頻繁にバージョンアップのあるオープンソースと、どうしても対応が緩慢 (この場合、緩慢どころかもう停止してるのだろう) になる商用ソフトの相性の悪いところだ。

選択肢がない

日本語を使う者にとって日本語入力システムは必要不可欠だ。ハードウェアがどうとか OS が何であるかよりもっと人間よりのところにあると言ってもいい。キーボードのHappy Hacking Keyboard のページに、

アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースだからだ。

いまやパソコンは消耗品であり、キーボードは大切な、生涯使えるインタフェースであることを忘れてはいけない。

［東京大学 和田英一 名誉教授の談話］

という言葉が掲げられているが、この「キーボード」を「日本語入力システム」に置き換えても何ら違和感はない。

それにもかかわらず、Windows 環境下ですら現在では選択の幅がほとんどない。その原因は Windows にバンドルされている MS-IME の寡占につきると思う。しばらく前の Web ブラウザ Internet Explorer 寡占問題と同じだ。このときヨーロッパは 「WindowsとIEの抱き合わせは競争法違反」と異議声明を出した。日本でも MS-IME に対して異議を申し立てるべきだったのだ。それまで多くの日本語入力システムがあって切磋琢磨していたものが、ほとんど姿を消してしまった。

OS のシェアから考えて、Linux 版のみの商用日本語入力システムが開発されるわけもなく、Windows 市場で稼げなければ Linux 版は存在し得ない(もちろん MS-IME の Linux 版が出るわけもないし)。こうして Wnn も Linux 版の ATOK も消えていきつつあるのが現状だ。


長くなってきたので、この項つづく。