はやわかり レスポンシブルCSS

まえがき

リクエストがあったので、レスポンシブルウェブサイトを構築するCSSの基本的な考え方を簡単にまとめよう。

これは、CSSやHTML自体を書けない人を対象にしたものでは ない

ケース分けの仕方

CSSのメディアクエリを使用する。 メディアクエリの詳細についてはMDNに記事がある

ほとんどの場合メディア特性にはwidthまたはheightを使用する。 広く使われてはいないが、aspect-ratio, orientationは基本的なメディア特性であり、非常に有用である。 この両者を組み合わせることで(ゲーム画面のように)スクリーンサイズに合致するレイアウトが可能になる。

典型的なケースでは、レイアウトボックスが1000px幅だとして、ビューポートに1000pxがなければ画面いっぱいにfallbackする。

ただし、このようなケースでは次のように書くべきだ。 そして、実際にこのように書くべきケースは非常に多く、メディアクエリを必要とするケースは表示切り替えくらいのものである。

この場合、#MainBoxは幅1000pxをまず確保しようとする。 しかし、min-widthによって制約されているため、1000pxの幅が包括ブロックの100%を越える場合は包括ブロックの100%に留められる。 これによってビューポート幅を突き破ることがないようにできる。

widthによって判定するのは「コンテナの中央寄せ」という、2003年以来の文法に従っているためだ。 だから、しっかりとデザインするのであればまた異なった設定になるだろう。

HTML構造

基本的なレイアウトでは全体を収めるためのボックスを用意する。

この中にレイアウトしていくのだが、基本的には「左であり、上である」「右であり、下である」という順序で書く。 これを入れ替えるのはCSSでは少し難しい。 ただ、良いCSSを書くには「可能な限りJavaScriptに頼らない」という気持ちは必須である。

「本文コンテナとサイドバー」という構成であれば、サイドバーの内容を上にしたいのであれば左サイドバーになるし、サイドバーの内容を下にしたいのであれば右サイドバーになる。

横並びレイアウトで最も基本的なのは「コンテナをテーブルに、コンテンツをセルに」である。 この場合、例え縮小しても横並びは維持されるし、min-widthなどではみ出す場合、そのままoverflowする。

コンテナ側のサイズが決まっていて、サイドバーのサイズを指定しないことでサイドバーをある程度縮小させることを許すことができる。 これは、最低限必要な幅を確保した上で、それよりも幅があるのであればもう少しスペースをとって表示することができる。

次のCSSでは、1000pxを下回るのであればtableによる表示を諦めるが、ボックス自体は最大1200pxまで伸張する。 1200pxの場合、その割合としてはサイドバーが200pxから300pxの間で、残りがメインになる。

十分なスペースがないときに右のボックスを下に送るのであれば、メディアクエリは必要ない。 inline-blockとして配置することで、overflow時はボックスを並べないようにすることができる。

この場合、サイズ指定は並んだときに確保すべきボックスと、単独になったときに伸張すべきボックスの大きさを意識する必要がある。 また、内包されているボックスの位置と大きさはいずれも#MainBoxにbindされていることを忘れてはいけない。

表示ボックスそのものの変更

ボックスのレイアウトではなく、内容そのものをレスポンシブルに変更したい場合はdisplayを上手に使うといい。 例えば次の場合、#TOCは十分な幅がないとき省略される。

メニューは十分な幅があれば横に配列しようとするが、ないのであればそのまま縦に配列する。

同一の内容に対して異なる表示を提供したい場合は、予め複数書いておくようにして、メディアクエリでdisplay: block;display: noneを入れ替えるのが良い。 この場合、同内容はジェネレータによって生成されるべきである。PureBuilder Simplyの場合、Pandocテンプレートを使うことにより内容の反復を避けることができる。 より一般的にはテンプレートそのものをeRubyなどで生成し、値を置き換えるのが良いだろう。

順序の変更も、「複数書いておいて、表示を切り替える」のが最も無難である。

がんばるのであれば、position: absoluteあるいはposition: fixedを使うことで「見かけ上の順序」をごまかすことができる。 これらはビューポートをそのまま使うブロックに対して指定することが多いためあまり意識しないだろうが、座標起点は包括ブロックであり、また包括ブロックとしても機能する。 以下の例では十分な幅があればサイドバーは左に表示されるが、十分な幅がないとき、サイドバーは下に表示される。

表示コンテンツの変更

レスポンシブルに異なるバナーをコンテンツ中に表示したいような場合は、JavaScriptを利用するほうが良い。 ただし、メディアクエリと背景画像を使うことでCSSで処理できないこともない。

各ページ共通のものであればテンプレートに組み込んで表示ボックスの切り替えが良い。

表示コンテンツの表示の仕方でいえば、max-width, min-width, そしてmarginの値をコントロールするようにするといいだろう。

おまけ。ビューポートを全部使う

文字主体のコンテンツの場合、文字サイズをビューポートに基づくようにすれば問答無用でビューポートいっぱい使うデザインが可能。

5vwは一応、1行に20文字入る計算になる。 この場合、横幅が小さい場合は文字数が、縦幅が小さい場合は行数がある程度確保されるようにするという基準になっている。 その上でなるべく大きい文字にする。画面いっぱい使って大きく文字を表示するのでお年寄りにもやさしい。

標準的に1920pxに対して16pxの文字とすると120文字入るので0.85vhとなるのだが、これをすると非常に小さくなってしまう。

これをやると拡大縮小がかなり制限されてしまうことから、「大きく文字を表示する」前提で考えたほうが良い。 2vhくらいあればちょっと大きめに表示されるが、拡大できないので2.5vhくらいをスタートに考えたほうが良いかもしれない。 特にウィンドウをタイルしたときなどで縦長になるとすごく小さい、などということもありえるのだ。

縦書きウェブ

「悠のおはなしのおはなし」というサイトを始めた。

これは、私が作家として物語について、あるいは物語をつくることについて述べている新しいサイトである。

主たる話題が美少女ゲーム(=アダルトゲーム=エロゲー)であるため、苦手な人も多かろうし決して閲覧を推奨するものではないのだが(PVを欲しているわけでもないし)、このデザインに関してはかなりがんばったので、その話をChienomiでしたいと思う。

縦書き

縦書きプロパティ

CSS3に縦書き関係のプロパティがあることは知っていたのだが、実際試すと随分印象が違った。

縦書き、あるいは段組というのは昔からあった。

段組のほうが古く、段組用のタグはHTML4で廃止されてしまった。 「見た目に関わるタグである」ということが理由だったが、その時点でCSSで代替する方法がなく、そもそも段組というのがHTMLにふさわしくないという判断が働いたようであった。 実際、誰も使っていなかったし。

また、単純に縦書きにすると非常にスクロールが長くなること、そして基点が左上であるため一旦全部右にもっていかなければならならいことからあまり快適性もなかった。

しかし、CSS3の縦書き+段組であれば、「画面サイズにちょうどよいように段組してくれる」という使いやすさだった。 画面に3段収まるのであれば3段、収まらなければ2段といった感じだ。 これは段の高さだけで、段数自体は無限になる。

もちろん、段組などしなければ縦書きは横にスクロールする形になる。 これは単純に縦書きか横書きかの違いになるため、考え方としては横書きとまるで変わらない。 しかし、PCの場合マウススクロールの方向がYだけ、タッチパッドでもX方向スクロールは無効であることが多いので、X方向にスクロールするUIというのは大変嫌われる。

そのため、「縦書きの無限段組」というのは非常に良い挙動だと思う。

ただ、「ePubみたいにフリックでめくりたい」という要望が出たので、後述するページめくりを入れた。

不安定な挙動

理屈上では理想的なのだが、現実としてはやはり「縦書き段組」なんてものをけんしょぅする人が少ないからか、なかなかbuggyである。

なんといっても、ボックスのサイズ計算、位置計算が全ておかしくなる。そして、段組の計算もおかしい。

さらに、リサイズ時の段数が読めない。同じサイズにリサイズされても条件によって結果が変わる。

結局、その抑制のため、幅を取るエレメントを横に並べず、HTML全体を幅90%に制限するという方法をとった。

なお、FirefoxよりはChromiumのほうが安定して描画してくれる。

レスポンシブルと4kスケーラブル

4kの大きいディスプレイを買って感じるのが、「大きな画面を想定していないサイトが多い、ということだ。」 幅が極端にあると、コンテンツは真ん中にちょこんとあるだけ、という状況になりやすい。

トヨタのウェブサイトは現在は真ん中コンテンツ型で、TGRに関しては写真だけ幅いっぱい、という仕様になっている。

幅が小さいモバイル系デバイスの設定はしても、幅が大きいデバイスに対する対応というのはちゃんとしていない、という感じだ。

そこでこれに対する対応として、私は珍しい指定を入れた。

フォントサイズが画面幅によって決まる、ということである。 このため、大きい画面であればピクセル数によらず文字は大きくなる。 段組の文字数を決める上でも扱いやすい。

この考え方、今の「振れ幅の大きすぎるディスプレイサイズ」問題に対応できる気がする。

幅は原則画面いっぱいにしており、幅広ディスプレイにも対応する。 しかし、あまりにも行数が多くなるととても読みづらいため、34行までに制限している。 そのため、さすがに上下タイルとかされると真ん中に置かれてしまうのだが、大画面の最大化ではそうはならない。

ちなみに、今回行数をどうしようかと思って文庫本を色々数えてみたのだが、16から18行が多く、一部19行というものがあった。 さらに合わせたかったのだが、さすがに幅が少なく、見開き分ということで34行としている。もちろん、これはフォントによって結果が変わるが。

UI

ボックスレイアウトが縦書きすると狂うこと、本好きの感覚としては余計な表示は欲しくないことから、トグルボタンを2つ置く、という方法で対応することにした。 ちなみに、いつも通り、CSSのみの対応である。

操作できるものが他になければ操作してくれるものなので、割とイケると思っている。 微妙に表示としては邪魔なのだが、それはご愛敬。HTMLを90%にしたおかげで右側が少しあきやすく、この問題は少し軽減されている。

ハンバーガーメニューはともかく、純粋なトグルというのはあまり見ない設計だが、simplifyという観点から言えば悪くないと思う。

ハンバーガーメニューですらないUIに気づくかどうかについては… トップページにでも書いておいてなんとかしよう。

ページめくり

前述の通りePubのようにページをめくりたいという要望に応じて、swipeとflick両方に対応する簡単なスクリプトを書いてみた。 jQuery Mobileどころか、jQuery自体使っていない、PureJSによるものである。

考え方は単純で、タッチ開始時に座標を保持し、タッチ終了時の座標と比較する。 Y軸は普通にスクロールだから、問題にするのはX軸だけ。 差が閾値以上にあればスワイプ、またはフリックしたものとみなす。

今回、閾値は「画面の1/3以上」とした。意外としっかりとやらないとめくれない。 感触としていまいちなので、今後もっと小さい操作でもめくれるように調整するだろう。

話をすごく単純化しているが、意外とこれで問題なく動作する。

1段の高さははっきりしない上に取得もできないので、単純に画面半分をスクロールすることにした。 おまけのようなものなので実用性は状況によってはあまりないが、ないよりはよかろうということでアクセシビリティツールである。

デザイン

やや黄色がかった背景とグレーの文字は目に優しく、「本っぽい感触」を求めてみた。 本であればもっと黒いのだが、印刷物よりも画面のほうがはるかにコントラスト比が高いことから、よりグレーにした。

タイトルロゴは珍しく実用的にfloatが使われている。 最近はfloatは思い込みで横に並べるのに使われがちなので、多分珍しい。 ロゴの配色は「白枠、色付き背景」というライトノベルの背表紙のスタイルに合わせてみた。

左上に入るページタイトルは、小説の上部に章タイトルが入るスタイルを意識している。

「本なんて特に有益ではない」「本で勉強する必要はない」「本がありがたく高尚なわけではない」という発言を繰り返しているので誤解されがちなのだけど、私はそもそも本好きで、めちゃくちゃ読むほうだ。 最近は「本が入り切らなくなったので動画を見るようになり、動画に飽きたのでエロゲーをやるようになった」という感じで、割と物語ジャンキーみたいな感じで何かしら物語に触れていたいタイプだったりする。

本屋にいけば際限なくに時間を消費してしまうからあまりいかないように心がけているし、横浜に図書館がないことは大変嘆いてもいる。

電子書籍も(普通にPDFなどプレーンな形式で配布してくれるならば)好きだし、紙の本も好きだ。 ただ、どちらかというと私の場合、紙の本なら本棚に入れておけば何の気なしに読んだりするが、電子書籍は明確な動機がないと読まないので、それを理由にどちらかといえば紙の本が好きで、家に無限の広さがあり、引っ越しの手間も考えなくてよいのなら書庫を作って本いっぱい買いたいくらいである。

本を読むタイプの人間としては、「本っぽさ」というのは長文を読むときには結構欲しい。 流し読み、というか斜め読みするときは横書きが圧倒的に早いけど、物語への没入なら縦書きがいい。

紙っぽさ。縦書き。本っぽい文字数。本明朝。 これは私のこだわりであり、これをきっかけに「物語を読む」ことが好きな人が増えてくれたらいいなぁ、という気持ちも込められている。

また、このデザインは、webページのデザインとして上がってきたものを見たときに、「ウェブはかくあらん」みたいな感覚をぶち壊したい、というのもあった。 そもそもそのサイトでは「従来にないデザインの方向性を目指したい」というのがあったのだけど、なぜか「デザイナーから上がってくるwebデザイン」ってすごくありきたりというか、みんな同じようなものを出してくる。(ちなみに、違う感じのを出してくる人は実用性の欠片もないとんでもないものを出してくることが多い。)

それが常識としてこびりついているのなら、「ウェブはこんなことしたっていいんだよ」というのを声を大にして言いたかった。 だから、常識やお決まりからは思い切りかけ離れたサイトを作りたかったのもあります。それは、ウェブのクリエイティビティを失ったエンジニアに対しても。

縦書きプロポーショナル

今回、vpalを有効にしており、縦書きでプロポーショナルメトリクスが有効になっている。

徹底して「文庫本っぽく」仕上げているにも関わらず、書籍ではまず見ない縦書きプロポーショナルは、私のちょっとしたチャレンジだ。 これが見やすいかどうか、ぜひ意見を募りたいと思う。

鳩山元首相の「デマ問題」が問題である所以

あらまし

北海道で震度6の地震があった直後、鳩山元首相が「CCSによる人災」と断定的にTwitterで発言、 北海道警が災害後デマとして注意を呼びかける中にこのツイートを含んだことが話題の発端である。

私は 政治的な話をする気はない ので、別の角度から説明する。

これはあくまで 「インターネットと社会」という観点から一般的にどうであるかということと、それに照らしてどうであるかというお話である。

最大の罪は「無責任な発言→証明の要求」

デマを流す人というのは結構いるのだが、そのほとんどは明確な根拠もなく、そして根拠も示さず、検証に労力を割かない。 つまるところ「放言」である。

そして、その無責任な発言を咎められた時の常套句として、根拠や証明を要求するというのがある。

これは極めて下劣な行為である。 なぜならば、自分は責任を負ってもいなければ、その労力を割いたわけでもないのに、他者にその労力を要求するのである。

このようなデマ拡散に対しての義証明というのは社会的に極めて損失になっている。 無責任な放言などいくらでも言い放題だからコストは非常に低く、能力も必要ない。 そして、そのような気まぐれによって、その証明を担える優秀な人たちが比較にならないほどのコストを負わされるのである。

インターネット時代においてはそのようなデマの拡散がより深刻化し、人類の発展を阻害している。 実害のあるデマの抑止・修正に専門家が大きな時間を取られる。

そして、そのような根拠に基づく指摘をされたところで、無視するか、やはり根拠もなにもなくrejectするかというのが常である。

最大の問題は、このような人類に実害のある愚劣な行為を、仮にも元国家元首が行ったことである。 これはちょっと、呆れるでは済まない。

デマの問題

そもそも流言飛語というのは時として国を滅ぼすほどのもので、全く軽い話ではない。

そして、インターネットでは1デマの拡散というのは 最も重い罪である とされている。 もちろん、当初からデマという問題があった、というのがその所以でもあるが、依然として「インターネット」から見ればデマが最も重い。

理由はその拡散性、というかconnectivityにある。 インターネットは間接的に全体でつながるように設計されている。そして、その空間を流れる情報量というのは有限である。 このインターネット上での情報伝達におけるS/N比というのは、そのまま「インターネットそのものの価値」に直結する。 つまり、ノイズが増えすぎるとインターネットは死ぬのだ。もしあなたが「インターネットに接続すると、有益なものはなにも得られず、ただひたすらゴミ情報ばかりが送りつけられる」という状態になったならば、あなたはインターネットを使うことをやめるだろう。そして、そこまで行かなくてもある程度「有益なものはわずかで、ゴミは大量」という状態になった時点でやめる可能性が高いだろう。つまり、そういうことだ。

スパムメールなどがインターネット上で重罪なのもそれ故だ。 ちなみに、これはこれで経済損失としては非常に大きく、ちょっと近年のデータはないのだがかなり深刻であり、かつ一定以上増加すると社会が麻痺する可能性もあるほどの危険性がある。 そのため、日本では違法でもある。

インターネットにおける罪というのは、倫理とか道徳とか、あるいは国家秩序なんてものとは 全く関係がない 。 インターネットにおける罪はインターネットを殺す行為であり、デマの拡散というのはまさにそれにあたる、ということだ。

タイミングと責任の問題

では社会的な話をしよう。

災害直後というのは非常にデマを呼びやすい状況にある。 人々は不安で、かつ正確な情報の伝達手段を損失しているからだ。

しかも、正確な情報が手に入らないことは人命に関わる。だから、例えデマでなかったとしても「十分に意義のないことは含めないようにしなければならない」というのが前提である。 不正確な情報や憶測によって救助が間に合わなかったり、あるいはどうでもいい内容によって救助が必要な情報が埋もれてしまう、という状況は容易に察しがつくだろう。

だから、災害直後という状況下においては 正しかったとしても、その緊急時に必要とされない情報を挟み込むのは人命に関わる暴挙 なのである。

社会的に見れば、災害直後にこのような発言をしたというのが深刻に問題である。 さらに、「不安を煽るような発言」「根拠を示していない憶測に基づく内容」「断定」とあかんものが揃っている。

まして今回の場合、「災害直後は話が広まりやすく、風説の流布には適したタイミングである」という認識があってわざとやったのであり、すごく悪質である。


  1. これは「インターネットでは」であって、「インターネット上の民意では」という話ではない。

OPPO R17 Pro

まえがき

Zenfone 4 Selfie Proを割ってしまった。 比較的落としたりしても大丈夫な端末だったが、ポケットから落ちて石畳に画面からまっすぐ落ち、広範囲に渡って割れた。

画面が割れた以外の支障がなかったため、全然使っていないという事情もありそのままにしていた。 だが、ビックカメラの格安スマホ安心保証の期間ギリギリであったため、交換と相成った。

内容を見る限りでは「原則修理、修理代が8割を越えたら同一端末と交換」と読めるのだが、実際は交換を前提に運用されているようで、 交換端末について聞かれたし、つまりは同一端末以外へも変更できる、ということだった。

方式としては交換端末から元端末購入時の金額を引く。その上で交換料金を乗せる、という形だった。 元端末より安いものであれば交換料金の5000円だけで済み、そうでない場合は差額を加えることになる。

もちろん、Zenfone 4 Selfie Proは購入時より価格が下がっているし、非常に気に入っていた端末なので交換も候補だったのだが、 その直前に端末を触ってR17 Proに惚れ込んでいたため、R17 Proへの交換とした。 税込価格が8万円近い、ハイエンド帯に入りそうな端末である。プロセッサ的にはSD710となっていて、一応ミドルレンジなのだが、ミドルレンジとしてはかなり高価な端末だ。

ちなみに、基本的な評価としてはSD710は全世代のフラッグシップSoCのSD835と同等、ただしグラフィック性能はだいぶ劣る、ということである。

概要

基本的には使い勝手の悪い最新スタイルの端末だと言っていい。 ディスプレイは6.4インチの有機ELで19:9の2430×1080と、5.88インチからさらに縦長にしたタイプ。 小さなノッチつきだ。

USB Type-Cを持ち、イヤホンジャックはない。 また、DSDSだが、SDカードには対応しない。

このあたりは致命的に使いにくいポイントだ。

一方、SoCこそSD710とミドルレンジに留まるが、カメラはアウトカメラがデュアルで12M+20M、インカメラは25Mという豪勢さ。 レンズもf1.7/2.4/2.0となかなか明るい。

対応周波数帯も多く、バッテリーは1850mAhのものを2機搭載。重めではあるが、全方位に渡って隙がない。

基本的にハイエンドクラスのスマートフォンはゲームユースを想定したものが多いが、 R17 Proの場合カメラを中心として使い勝手や機能部分は惜しみなくハイエンド並のものを投入する一方、処理性能などは過剰なものを入れないようにした 「非ゲーマー向けの最高のスマホを作りました」みたいな感じである。

なお、OPPOといえば「飛び出すカメラ」で一躍有名になったけれど、R17 Proは普通にノッチ。

中国端末では一般的な「AndroidベースのカスタマイズOS」であるColorOSを採用。 なんだか不安を覚えてしまうが、実はこれが「Androidであからさまに欠如している部分」を補うのに非常に有効に働いていて、購入後にOPPOに惚れ込んでしまうポイントになった。

惚れ込んだポイント

驚愕したのがカメラである。

私はYouTubeに動画を上げているが、実はYouTubeの動画撮影はスマホでやっている。 そして、かなり悩まされているのが「ピントが外れる」ことである。 最近のAFは結構賢いと思うのだけど、それでも急に距離が違うものが入ったり、あるいは比較的近いところにあるものが動体だったりするとピントが外れてしまう。 YouTubeの動画は室内撮影なのでより厳しい。埃とかでAFがずれてしまうのだ。

AFが外れたとき、再調整にかかる時間は速いもので2-3秒といったところである。 だが、実際はなかなかピントして欲しいものを掴んでくれないため、延々迷い続けて10秒くらい合ってくれないということも多い。 写真ではフォーカス対象も指定できることからあまり気にならないのだが、動画だと結構痛い。YouTube動画の撮り直しは大変しんどい。

Zenfone 4 Selfie ProもAxon 7も実用的にはなったものの問題を解消するにはほど遠かった。 カメラが良いとされているP20も試したのだが、基本的にはあまり変わらないレベル。フォーカス対象が動いてからもやーっと切り替わる感じで、これはYouTubeでは困るなぁ、という感じだった。

だが、R17 Proは違う。違うというか、もう次元が違う。 ピント合わせに必要な時間は長くて0.3秒といったところ。 遠くを写している状態でカメラの前に手をやると、マクロ撮影になる距離でなければ、もうずっとピントが合っているように感じる。 そこから手を抜くと手を抜いている途中でもう後ろにピントが合っている。 本当に異次元のAFで、これに惚れ込んでほぼこの一点で購入を決めてしまった。

機能別

綺麗だけど埃の激しい画面

画面は非常に綺麗である。貼り付け済み保護フィルムが色々やさしい。

サイズは6.4インチということでなかなか厳しい。 私はポップソケッツを真ん中右よりにつけているけれど、持ち替えないと端っこには微妙に届かない。傘を持ったまま完全に操作できるかというと無理である。 私の手の大きさは男性としては標準的なので、手が大きめの男性ならポップソケッツを使えばいけるだろう。女性にはかなり厳しいと思う。 なお、バンカーリングでは支えるためにスマホのどこかに手を接触させる必要があるから、かなり手の大きい人でも無理だと思う。はしっこにつけて、第一関節がかかるようにするくらいか。 両手持ちの人なら問題はない。一方、スマホをホールドするタイプの人は私の手のサイズだと画面真ん中くらいまでしか届かないということを考慮する必要があるだろう。

注目すべき点として、「オート輝度とブルーライトカットフィルターが実用的」ということが上げられると思う。 オート輝度は自分の顔が影になるなどしてコロコロ輝度が変わってしまってみづらいために、ブルーライトカットは赤みが強くなりすぎるために使い物にならないと感じていた。 だが、R17 Proのオート輝度は適切な値をキープしてくれるし、ブルーライトカットは白は黄色っぽくなるものの他は自然でほとんど気にならない。

ただ、欠点として埃を非常に集めやすい。 物が多く掃除してはいるものの埃が舞っている私の部屋では常にホコリまみれになる。 外ではあまり気にならない。物が少なくて埃を取り切れる家なら問題ないと思う。

Zenfone 4同様にスクリーンオフの状態で時計を表示する機能がある。 デジタルクロックなのでZenfoneよりも実用的。

全画面表示のコントロールとして、ノッチ部分を除外する機能がある。 ノッチを考慮していないアプリでの全画面表示で困らない。

PVCケースはつけたいかも

重量はちょっと重めで、厚みは控えめ。だが、カメラが出っ張っている。 このため、付属のPVCケースが保護に有効で、久しぶりに使っている。

素の状態ではガラスなので滑りにくいが、やっぱり埃を集める。 そして、マット加工されているミストグラデーションは気にならないが、エメラルドグリーンは大変指紋が気になる。

基本的に最大側に振り切れているボリューム

音量も輝度も、最大側が極端に大きい。めちゃくちゃ明るいし、爆音である。

最小値は適切に小さい。だが、値全体としては圧倒的に大きく、「控えめな値」を求めるのであれば下1/4くらいで調整することになる。

認証

指紋認証はスクリーン上にある。 画面OFFでもGを関知し、かつ暗くなければかっこいいアニメーションで指紋認証ポイントを教えてくれる。

指紋認証の精度と速度は普通。Zenfone 4 Selfie Proの認証は絶品だったので、その意味では不満。 また、手が濡れていると全く効かない。

超絶性能のカメラを利用した顔認証は非常に強力らしいのだけど、好みの問題から私は使っていない。

PINは標準で6桁。 わかりにくいが、設定時に「その他の暗号化モード」を選択することで

  • パターンコード
  • 4桁の数字パスワード
  • 4-16桁の数字パスコード
  • 4-16文字の英数字パスコード

から選ぶことができる。

ちなみに、珍しい機能として、メールアドレスを登録しておくとパスコードを紛失した際にレスキューできるらしい。

完璧すぎるカメラ

ちょっとおもしろいポイントとして、センサーが4:3である。 最近のスマホは16:9でしか写真が撮れないのでセンサー自体16:9なんじゃないかと思うのだが、センサーが4:3で4:3の写真が撮れる。 ちなみに、画面比率に合わせたものも選択できるのだが、この場合短辺側がクロップされる。

画角としては4:3なため一般的なスマホと比べて短辺側は広い。一方、長辺側は狭く、現実的な使い勝手としてはちょっとナローな感じがする。 ここはマイナスポイントかもしれない。

前述のようにAFが化け物じみている。 ここまでAFが速いと世界が全く違う。夢のようだ。

写真は文句なしに美しい。 普通の写真で文句つけるのは、カメラにかなり詳しい人でないと難しいと思う。私は、比べればわかるだろうけども、単独で見せられても完璧としかいいようがない。 ちなみに、比べても私がもっているあらゆるカメラより綺麗に映る、としか言えない。

光学手ブレ補正もついていて、シャッターを切るのもとても速い。かなり速く動かしながら撮ってもぶれない。 マニュアル撮影も可能で、ISO感度含めてちゃんと制御できる。シャッタースピードもコントロールできるから流し撮りも可能。 背景ぼかしの可能なポートレートモードもある。

暗いところではシャッターを押した後ホールドするように求められる。 「シャッター音がしてから3秒間」なので、ちょっと間違えやすい。 「夜間」を選択すればウルトラナイトモードとなり、電飾も綺麗に再現できるAI機能つき夜景モードとして撮影できるようだ。

なお、12Mpxのほうが主で20Mpxが補助。切り替えは自動、とのこと。

セルフィに関しては「顔を好みに調整する」というSNOWみたいな機能がある。ただし、あまり極端にはならない。 かなり盛れるけれど、盛り度合いでいえばASUSのほうが上。まぁ、Zenfone 4 Selfie Proはセルフィスペシャルなスマートフォンだし、そこでは負けられないでしょう。

動画はHD/FHD/4kと選択肢が狭く、独立してH.264/H.265を選択できる。 FPSの指定はできない。 スローモーションは90FPSか180FPSだろうか。1/3倍速になる。

動画に関してはちょっと特徴的な部分がある。

まず、光量が十分な環境下では常に超絶AFで無双できる。 だが、暗いととても明るい部分だけが写り、全体的に黒つぶれしてしまっているようにみえる。 しかし、その状態でもAFは常に適切に捉え続け、コントラストとブライトネスを調整すると全く潰れていないのが分かる。 Axon7は全体的に明るいが、コントラストやブライトネスを調整しても見えないものは見えない、全体的に白っぽくなるだけという感じだ。

そのため夜間の動画撮影も調整前提であれば強力なのだが、蛍光灯がとってもちらつく、という問題が発生する。

性能とゲームスペース

基本的にバッテリー持ちはよく、SuperVOOCのチャージの速さもあってバッテリーに関してはかなり強い。 バッテリー持ちの良さの一因として、そもそも性能がかなり抑えめ、ということがあるようだ。

これは、「普通はそんなに性能がいらないはずなので、性能は抑えめにしつつ、ゲームスペースに登録することでフルパワーで動作させることができるようにする」という設計に基づくようだ。 これは非常に合理的かつ実用的。ただ、ウェブレンダリングは重く、プロセッサパワーを非常に必要とする一方、バッテリーへの影響も大きいので、ブラウザをゲームスペースに入れるかは悩ましいところになりそうだ。

RAMは6GBだけど、いつも通りのこととしてRAMが増加しても空き容量はそんなに増えない。実際、初期状態で空きメモリとしては3GBに届かない程度である。

フラッシュメモリは128GBで、ユーザー利用可能なのは108GB。

バッテリー節約機能は「ボタン一発、バックグラウンド通信OFF」とシンプルかつ実用的。 全体的なチューニングとしてもAndroidとはまた違い、より使いやすく、それでいて割と節電も効いている感じだ。 ただ、ベースのAndroid 8.1と同じくDoze下でアプリの通知を落としてしまう。LINEの通知もこない。比較すればやや届きやすい気はする。実際、AndroidではDoze下でDiscordが届かなくなっているけれど、ColorOSは届けてくれる。

執拗なまでのセキュリティ機能

購入してから惚れ込み、「サブもOPPOにしようかな」と思ってしまったのがこの機能だ。

アプリの権限

これ自体は普通なのだけど、Android標準のアプリごとの権限ではなく、「権限からアプリを探す」ということができる。 すごく使いやすい。

フローティングウィンドウのブロック

ポップアップを防げる。思わぬタイミングで広告を挟んでくる鬱陶しいアプリを抑制できる。 これゲームとかによさそう…

個人情報で空を返す

「最高じゃないか!!」と思ったのがこの機能。

「通話履歴」「連絡先」「メッセージ」「イベント情報」について(もしくは私が権限を要求するアプリを入れてないだけのその他について)アプリを指定して保護することができる。 保護されていると、アプリがその情報を要求したときに本当の情報ではなく空の情報を返すという。

つまり、例えばSkypeは連絡先情報を要求するし、これをブロックすることはできない。 かつ、勝手にSkypeと紐づけて使用するし、保存もする (アプリを消しても関連付けられたままになる)。 だが、この機能を使えば、Skypeに対して権限としては許可しつつ、実際の連絡先にはSkypeはアクセスできない状態にすることができる。

紛失端末を探す

捜索機能がGoogleとは別口で使えるようになっている。 ちなみに、デフォルトでオン。

決済アプリの制限

アプリによって勝手に決済されてしまわないようにするもののようだ。 決済するアプリを私は何も入れていないので使っていない。

着信拒否

着信とメッセージをそれぞれ独立して拒否することができ、ブラックリスト/ホワイトリストも利用可能。 拒否した場合は通知にも表示しないという機能もある。

偽基地局のブロック

基地局になりすましたジャックを防ぐものらしい。

アプリの暗号化

「最高じゃないか!!」と思ったの機能その2。

アプリ保護機能だが、OSレベルで動作し、認証しなければアプリは開くこと自体できない。 また、保護されているアプリはアクティビティからも隠される。

さらに、アプリ保護に使うパスコードはロックに使うものとは別に設定できる。すごい。

キッズスペース

アプリの制限、利用時間の制限、課金の制限が可能。 すごい。子供に持たせるならあってもいいかもしれない。

隠しファイル

写真、オーディオ、文書、その他に分類し、通常は見えないようにすることができる。

この機能のメニューからアクセスすることもできるし、標準アプリの「写真」から選択する、ということもできるようだ。 単に見えないだけでなく、認証が必要になる。

その他

  • 安全なパスワード用キーボード
  • セキュリティ機能使用時のスクリーンショットの抑止
  • バックグラウンドで撮影・録音の禁止

の機能がある。ちなみに、LINEのパスワードはパスワードキーボードが出ない。LINEは安全な入力になっていないらしい。

なお、ColorOSの要求する権限(特にホームアプリ関連)がちょっと多い。 この点は結構気になるけれど、OPPOに限ったことではないからあまり選択の余地はない。

プリインストールアプリもがしがし消せるのは嬉しい。

通信関係

アプリごとに「WiFiとモバイルデータ」「WiFiのみ」「ネットワーク禁止」を設定できるのはセキュリティ的にも強い。 また、モバイルデータを細かなポリシーに基づいて抑制する機能もある。

月ごとではなく、1日のデータ使用量に対する警告も可能。

NFCは使えないよ、と公式ページにはあるけど、機能としてはある。

テザリングのパスワードが初期設定は明らかアウトなものになっているので注意が必要。

組み込みでDLNA機能がある。

おやすみモード

手動、またはスケジュールでオンにできる。 Androidにも搭載されている機能だが、ColorOSのものはより細かい。

まず、メッセージあるいは着信を「すべて禁止」「連絡先に登録しているもののみ」「お気に入りの連絡先」のいずれかのものは通すようにできる。 通知の許可/不可ができる。そして同じ番号から3回電話があったら鳴るようにできる。

音関連

外部メモリに対応しておらず、ヘッドフォンもUSBであることから「ない」と考えていたのだが、音質は非常に良くて考え直すほどだ。

付属ヘッドフォンはAppleタイプ。外れやすくて好きではないが、音はかなり良い。

なお、サウンドエンハンス機能としてReal Original Soundが載っているけれども、標準の「音楽」アプリでしか使えないことを含めて微妙。 音楽プレイヤーは普通に使いやすくてよろしい。

ヘッドフォンモニター機能があり、スピーカーとヘッドフォン両方から鳴らすことができる。

収録されている着信音、通知音がAndroidと違う。 Androidよりもセンスがあり、使いやすくてこれもまた良い。

入力関係

入力はGboard。好きなのを入れてもいいと思う。 Gboardを使う場合、英語Qwerty入力ができないため、英語を有効にしておくと言語切り替えで利用できて便利。

プリインストールアプリ

OperaとFacebookとWPS Officeくらいだろうか。目立つのは。あとはAquaMail.

機能としてはコンパスがあるのが珍しい程度。音楽や写真アプリなどはなかなか使いやすい。

ホーム機能

ドロワーのないiPhoneタイプ。 これはさすがにZenfoneに搭載されているZenUIの出来には到底及ばない。

ホーム画面の編集はロングタップではなくピンチイン。

スマートサイドバーという、補助ナビゲーションを表示する機能があるけど、大きい画面で一部分から引き出すものなのでちょっとやりづらい。特にケースに入れてるととてもやりづらい。

通知

ノッチの都合なのか、通知アイコンは出ない。 画面オンにせずにアンロックできる都合から、通知に気付かないことが少なくない。

ColorOS独自な部分として、ネットワーク速度を表示したり、バッテリーアイコンの中にバッテリー残量を表示したりすることができる。

ハードウェアUI

ボタンはオンスクリーンで、ファーウェイやAndroid Oneと違って基本的には表示しっぱなしで、全画面時に消す仕様。

電源ボタンが右、音量ボタンが左で、推し間違えは少なく、固定もしやすいが、片手でスクリーンショットはできない。

指紋認証はオンスクリーン。位置がやや微妙で、普通にポケットに入れようとしたときなどに触ってしまうのが残念な感じ。

スピーカーは下部でモノラル。インターフェイスはUSB-Cのみ。マイクは(多分)上下。

カメラにZenfone 4 Selfie Proのような内側ライトはない。

その他

マルチアプリ機能であるClone Appに対応している。 ただし、LINEで試した限りあまりうまくいかなかった。フローティングウィンドウが延々出たりする。 ただ、ASUSのdual appのように「LINEのトークのバックアップができない」「共有が動作しない」などの不具合があるため、dual appよりは実用的。

ダウンロードの管理ができるのは結構便利。高速ダウンローダがあるとかではなく、ダウンロードしたファイルをマネジメントできる。

「手順」という形でサポートの手引きが見られる。これは超親切で感心した。 AXONにも似たものがあるんだけど、こっちはちょっと使いにくい。

デバイスの電源スケジュールがオン、オフ共に設定できる。 これもなかなか便利。

バリアフリー機能もなかなか魅力的な要素が多い。特に「モノラル出力機能がある」のはとても親切。

テザリングはWi-Fiテザリングのほかにパーソナルホットスポットという機能があるけど、違いがわからない。

アクティビティはロックが可能で、ロックしているものはclean allの対象外になる。 ただし、「最初からロックされるアプリ(LINEなど)がある一方、手動でロックしたアプリは次回起動時にはロックされていない」という仕様でやや微妙。

結び

カメラのAFに惚れ込んで買ったのだけど、使ってみるとColorOSの魅力にやられてしまった感じだった。

特にアプリの暗号化は強力で、重要な情報にアクセスできるのにロックできないアプリに対する保護が実現するのは大変良い。 個人情報を空で返す機能も、「個人情報へのアクセスが嫌」という理由で私は連絡先も使っていないため、この機能があることで実用性は一気に増した。

もちろん、USB-Cしかないこと、SDカードに対応していないことなど不満はあるが、それでも「買ってよかった」と思える逸品だった。 ミドルクラスでもかなり高めの製品だけれど、その価値はあると思う。

また、従来Zenfone 4 Selfie ProとAxon 7で棲み分けが難しかった(カメラ, ディスプレイ, 音楽機能がいずれも甲乙つけがたかった)のだが、今回大きくキャラクターが変わったため棲み分けが簡単になった。 2台持ちする人であれば、AQUOS R2 Compactあたり1と組み合わせると欠点が補えて良いと思う。 1台持ちの人であればちょっと癖が強くて苦労するかもしれない。R17 Proに合わせた運用をすればいいだけだが、2台持ちすればR17 Proの不得手な部分を補えるので運用が楽になる、というのは覚えておくといいだろう。


  1. コンパクトで軽量、ゲームに適したSDM845、SDXC対応、防水防塵、広角レンズ、3.5mm端子とR17 Proにはない機能が揃っている。

Linuxデスクトップ環境の比較

Linuxデスクトップ(Unix系デスクトップ環境)の使い心地というのは使いこんでみないとコメントもできないものなのだが、なかなかその特性を理解するまでそれぞれを使い込むのも難しい。 特にまだLinux歴の浅い方はどれを選んで良いのかわからないこともあるだろう。

そこで現行のデスクトップ環境からメジャーなものについて、私が感じる良い点、悪い点をまとめてみた。 あくまで私の視点なので、異なる意見もあるだろうが、そこはあくまで1ユーザーの意見とご了承願いたい。

また、MATE, Deepin’, Pntheon, Budgie, Lumina, LXDE, LXQtなどの他のデスクトップ環境、あるいはEnlihgtenment, fvwm, i3, awesomeなどの他のウィンドウマネージャがあることは承知しているが、私が普段使っていないのでコメントするレベルにはないことも、併せてご了承願いたい。

GNOME

良い点

  • Waylandに最も良好なフィーリングを見せる
  • スクリーンショットツールがとても使いやすい (ただし設定はgsettingsコマンド)
  • ウィンドウボーダーのデザインが豊富で、良いものが多い
  • ランチャーがコマンド実行になっており、検索前提のアクティビティ機能と相性がいい
  • Gnome Keyringは様々なキーをいい感じに管理してくれて使いやすい

悪い点

  • 設定の大部分が隠されており、テーマ設定などの基本的な設定もできない。また、壁紙もコマンドを打たない限り$XDG_PICTURES_DIR直下の画像ファイルに固定されている
  • ウィンドウタイリングが左右にしかできない
  • ウィンドウフィッティングが弱く、表には設定もない
  • Nautilusで右クリックにおけるアクションメニューが簡単に設定できるようになっていない
  • Alt+マウスドラッグによるウィンドウ操作ができない
  • メニューが非常にわかりづらく、メニューが少なすぎて必要な機能を満たさない
  • 「1画面しかなくて、1画面に1アプリしか表示しない」が基本なので、ウィンドウはクローズボタンしかない
  • アクティビティ機能はプログラムをカテゴリ分けしてくれないので、探すのが非常に辛い
  • ウィンドウスイッチャがなく、常にアクティビティから切り替えるかタスクスイッチャから切り替えることを求められる。カレントウィンドウのメニューは表示されるが、マルチディスプレイの場合はプライマリディスプレイ以外無視される 
  • 設定がホームディレクトリ以下になく、バックアップしづらい

捕捉

私はGNOMEが好きではないので、すごく否定的な意見であると考えてもらっていい。 「Linuxなら出来て当たり前だったことをわざわざできなくしている」ことに私は好感を持てない。

Gnomeアプリケーションにはいくらか魅力的なものもあるけれど、デスクトップコンピュータ、とくにマルチヘッドディスプレイや、大画面で使うのに適したものだとはとても思えない。

Gnomeはパソコンよりもタッチデバイスを優先しているのだと感じるし、パソコンもせいぜいが今風なラップトップのみを想定しているといったところだろう。 そして、様々な機能を要求に応じて使いこなす努力するユーザーではなく、機能を使う気がなく、機能を与えてほしくないルーザーのみに親切、という印象である。

ただ、それは解消不能な一部の問題(例えばウィンドウタイリングやAltマウスイベント)を除けばgconfなどによって解消することができ、 およそ「Windowsでレジストリをいじる」のと同じレベルで操作することにより、ユーザーによっては満足できるものに仕上げることもできるだろう。

Cinnamon

良い点

  • 非常に使いやすいウィンドウタイリング。 Super+カーソルで「現在の状態を基準にカーソル方向へタイルする」という挙動。また、タイルした状態でリサイズもできる
  • ウィンドウタイリングしたあとウィンドウを移動すると元のサイズに戻すようになっている。これは、タイル状態でリサイズした場合も同様で、タイルにウィンドウサイズのステートが影響されない
  • 軽い。 ハードウェアアクセラレーションが効くためXFceと比べても格段に軽い
  • ウィンドウフィッティングが設定可能で、かなり使いやすい。タイルしたウィンドウに対してもフィットするため大量のウィンドウを並べるのも楽
  • Alt+左ドラッグ(move), Alt+中クリック(windows menu), Alt+右ドラッグ(resize)全てに対応している
  • 設定項目はやや少ないが、必要なポイントは抑えていて「ほどよい曖昧さ」になっている。設定が大変ではなく、かつ必要な設定はできる傾向がかなり強い
  • Gnomeのメリットだったスクリーンショットと鍵管理はGnomeと同じものを使用しており、同じメリットが得られる
  • Nemoアクションがiniファイルになっていて、結構書きやすい (ただ、現在ちょっとバグってもいる)
  • ウィンドウラベルのマウススクロールに対して細かな設定が効く。アルファ設定も可能
  • Nemoが単独で動作し、軽いファイルマネージャでありながら、gvfsによるマウントにも対応していて使いやすい
  • Alt+F1でワークスペース選択になるのが便利。数字キーで選択できる
  • マルチヘッドディスプレイでフルスクリーンにしているとき、パネルは「パネルがある画面上でフォーカスされているのが他のウィンドウであるときのみ表示する」という理想的な振舞い。フォーカスウィンドウはフルスクリーンウィンドウより前にくる
  • 選べるデスクトップアニメーション
  • 純粋なコマンドラインのランチャと、検索可能なメニューの組み合わせ
  • 左右へのパネル配置に比較的強い
  • 合理的な「フォントはDPIではなく倍率で設定させる」
  • DPのプラグアンドプレイ問題で「復帰できない変更をされる問題」が比較的少ない
  • ボリュームアプレットがマイクのミュートコントロール、デバイス選択、プレイヤーコントロールまでできる便利設計
  • フォント設定機能がフォント数が増えても軽く、使いやすい
  • ファイルダイアログが未選択状態でキータイプを始めると直接パス入力できる仕様
  • Conkyの表示が一番安定している
  • ウィンドウスイッチャからQで直接ウィンドウクローズが可能

悪い点

  • 通知を1件ずつ表示するため、大量の通知がある場合いつまでクリックしても終わらなくなる
  • 通知の有効期限をスクリーン上ではなく通知エリア上の時間として扱う。これは、恐らく正しくない
  • 壁紙がウィンドウごとではなく共通である。設定が楽、ディスプレイ認識でおかしなことにならないというメリットはあるが、残念には感じられる
  • ウィンドウデコレータがMetacityベースでデザインがあまりよくない
  • アプレット機能があるものの、動作しないものが多く、ほとんど役に立たない
  • 起動がやや遅い

捕捉

基本的に「すごくいいバランスで、うまい具合に作られている」のがCinnamon。 機能豊富というわけではないのだが、GNOMEやKDE Plasmaのように主張をぶつけてくる感じではなく、「どうあるのが自然か」「どうなっていれば使いやすいか」ということに向き合って作られている感じがする。 (ただ、Cinnamonはissue reportに対して割と対応は冷たいのだが)

ほとんどの場合要求を満たすことができ、完全ではないが不満というほどではないという状態を作るのがうまい。 至らないところもあるが、使い勝手なら最高だと思う。私は何に移ってもCinnamonに戻ってきてしまう。

ややいまいちだったウィンドウスイッチャは、Windows7以降と同様のアイコンスタイルのものが導入されて使いやすくなった。 グループに対してはホバー時だけでなくクリック時にウィンドウリストを表示する機能もあるが、これはまだbuggyである。 垂直表示を有効にしていると、ウィンドウグループを縦に表示し、さらにそのウィンドウから派生したウィンドウは水平に表示するという器用さを見せる。 懸案だった「.desktopファイルに書かれている情報を使ってくれない」という問題も解消してくれている。

ClutterとNemoの出来の良さが圧倒的で、総じて非常に使いやすい。派手な機能はないが極めて実用的だ。 Cinnamonの欠点を探してみたのだが、これといってあまり見つからなかった。以前はいくつかあったのだが。それが戻ってきてしまう理由かもしれない。

KDE Plasma

良い点

  • 非常に充実したアプリケーション群でクオリティも高い
  • 非常に充実した設定項目。特に電源管理が優れている
  • KIM Panelが格段に使いやすく、Fcitxのウィンドウも統合されていて入力が快適
  • Alt+マウスドラッグによる操作をカスタマイズできる
  • デザインが良い
  • KDEパネルは機能が多彩で、ウィジットも強力
  • 0.1倍単位のUIスケーリング。Gtkアプリケーションにも対応する
  • 検索のみではあるもののランチャもメニューも強力な検索で使いやすい
  • KDE Walletはウェブブラウザのパスワードを一括して管理してくれるので安心感がある
  • 設定ファイルが素直にホームディレクトリ以下にあるためバックアップしやすい
  • Qtの利点を活かした非常にスムーズなスクロール
  • ディスプレイ接続時のアクションが良好で、プレゼンなどでプロジェクターを使うときにも使いやすい
  • ディスプレイを「重ねて配置」できる
  • ウィンドウフィッティングが非常に素晴らしく、ピタッとウィンドウを並べることができる
  • フォントレンダリングに手が入っているのか、ちょっと綺麗
  • 通知の扱い方が適切で使いやすい

悪い点

  • やや不安定
  • サイズの異なるディスプレイを並べると、ディスプレイ位置がおかしくなったり、パネルを失ったり、壁紙を失ったりする
  • ディスプレイの再接続時に本来のディスプレイ設定に復帰しない
  • よくアイコン位置がおかしくなる
  • プラズマにログインしてからログアウトし、再度プラズマにログインするとスケーリングがおかしくなる
  • Balooを有効にしているとキャッシュファイルなども画像に含められてしまい困る上に、inotifyの上限に到達してもさらにファイルを追加するためシステムが終わる
  • AkonadiやKDE PIMは便利ではあるけど、「いらないことをする」感じも強い
  • KDE WalletがGnome Keyringのように暗黙にSSHエージェントのように振る舞わない
  • 設定が独特で、XDG標準を遵守しないし、XDGディレクトリもあまり尊重しない
  • Dolphinはアクションを追加するのも面倒で、XDGディレクトリを無視し、ブックマーク機能はない
  • ウィンドウタイリング後にウィンドウを移動すると、ステートはタイルされていないことになるが、元のサイズには戻らない
  • 壁紙の設定が面倒。フォルダの追加は知識が必要で、全部まとめられるので

捕捉

理想は高く、理想に届かないKDE Plasma。 KDE Applicationsに満足するか否かが分かれ目になる。

ウィンドウフィッティングはCinnamon以上に良好で、ウィンドウを並べるのは得意。 ただし8方向タイリングはショートカットキーの設定が必要になる。 一応、マウスでエッジに持っていくとタイリングしてくれるのだが、位置が割と狭くてやりづらい。

大きな欠点だった「等幅フォントにデュアルスペースフォントが設定できない」は、spacing >= 90にするのではなく、spacingを無視するオプションを加えて対応している。

うまく噛み合っていれば使いやすいのだが、噛み合わないことが多いKDE Plasma。 状況がハマれば使いやすいため、私はラップトップではKDE Plasmaを使用している。

なお、KWalletでブラウザの鍵を管理すると、ブラウザはこれまで管理していた鍵を捨ててしまう。 逆にブラウザに管理させるとKWalletで使えなくなる。だから他のデスクトップと行ったりきたりするのには最大の障壁になる。

systray問題として深刻だったsniについても、現在はおよそ問題のない状態になっているようだ。

特にスケーリングの自由度は大きなメリットと言っていいだろう。 電源管理の柔軟さと併せて最新のラップトップには適しているように感じる。

KDE4時代の癖のあった特徴的な機能は下げられている。そのため、積極的にKDE Plasma workspaceを使う理由を損ねたという印象もある。

相変わらずbuggyな部分も残念だ。Balooは非常に振る舞いに問題があり、オフにしておくのが無難だろう。

XFce4

良い点

  • Alt+左ドラッグとAlt+右ドラッグに対応
  • パネルウィジットのアプリケーションメニューが独自メニューを設定できるため、引き出しとして使用できる
  • 「ランチャー」ウィジットは副項目を設定でき、やっぱり引き出しとして使用できる
  • XFce4 Terminalの使い勝手が良い
  • やたら積極的で便利な「透明度」設定。透明ウィンドウ好きにはたまらない
  • ThunarがSFTPに対応している
  • ディスプレイの「ブランクスクリーン化」と「電源off」が分けられていて、DPプラグアンドプレイに悩まされている場合は便利
  • 自動起動にそれとわかるように他のデスクトップ環境のものが選択できるようになっており、Gnome Keyring SSH Agentを使うということもできる
  • 8方向タイル可能。ただしタイルのショートカットキーは全く設定されていない
  • デスクトップ右クリックでデスクトップコンテキスト(アプリケーションメニューつき)、中クリックでウィンドウリストと結構便利
  • アプリケーションファインダーがコマンド実行で候補検索を含み、展開すると(Alt+F3でこの状態でスタート)メニュー検索もできるようになった
  • Whiskerは簡単にリサイズできる
  • Mugshotが実は結構便利
  • デスクトップにウィンドウリストを表示することもできる
  • ウィンドウスイッチャがグリッド状に表示されるため選びやすい
  • パネルの設定が器用で、高さを含めるかどうか、ホバー時で透明度を変えるか、隠すかなど設定可能。「Dock風」と「タスクバー風」を使い分けられる仕様
  • 壁紙の設定がモニターごとである上、「設定ダイアログをモニター上に動かせばそのモニターが設定できる」親切設計

悪い点

  • アイコンラベルのサイズは固定で、アイコンの間隔も固定。ちょっと長い名前のフォルダは簡単に隠されてしまうし、隠されないように設定すると
  • Bluemanが初回起動時だけXDGディレクトリを拾うため、XDGディレクトリを変更すると毎回エラーを出す
  • ウィンドウフィッティングは一応存在し、リサイズ時にも効くのだが、非常に弱い。設定もできない
  • 通知がいくつでも出してしまう上に、閉じても表示した位置に表示しっぱなしで大量に出されるととても困る
  • ウィンドウタイリング後にウィンドウを移動すると、ステートはタイルされていないことになるが、元のサイズには戻らない
  • パネルがデスクトップの大きさとして除外されない(xfwm4は除外できる)ので、デスクトップアイコンやConkyがかぶる
  • ファイル選択ダイアログがGnomeと同じものになったため、ファイルをパスで一気に入力することができなくなった
  • アプリケーションファインダーがフォーカスロックしないため、複数起動してしまうこともでき、さらにフォーカスを失うことがあるため「あれっ」となって複数起動してゴミが残ることが多々ある
  • フルスクリーンにしているとき、フォーカスしているアプリ以外はパネルがウィンドウより前にきてしまう (マルチヘッドディスプレイでのみ発生する)
  • 標準のボリュームアプレットがない (外部プログラムとしてはPulseAudioアプレットがある)

補足

XFce4になったときからずっと「ちょっとずれてる」「いい感じなのに、対応したにもかかわらず痒いところに手が届かない」を続けているXFce。

だが、Gtk3化の過程で大胆にチェンジした。 アイコンラベルとか、アプリケーションファインダーのフォーカスとか、微妙に「XFceだなぁ」と思うところは残っているものの、機能的には遜色ないどころか、他の環境を凌駕するところまで到達している。

Manjaroでは18.2からついにXFce4 Gtk3がメインになった。 使い物にならなかった時期が長かっただけに、ようやくという感じだ。 だが、

  • thunar-archive-plugin
  • thunar-volman

についてはGtk2を引き続き標準としている。 thunar-volman-gtk3はextraとcommunityそれぞれにバージョン違いがあるちょっと困った状態だ。

ウィンドウデコレータがMetacity相当になり、Cinnamonと同じものを使えるようになった。 今までちょっと偏りがあって使いにくいものが多かったので、非常によくなったし、デフォルトのものが結構スタイリッシュにもなった。

基本的な方向性はCinnamonやMATEに近い進化だと思う。 使い勝手が劇的に向上し、他のデスクトップと比べ見劣りするという印象を払拭した。 Gtk3になったため「軽い」という特徴は損なわれたが、最近はアプリケーションのほうが重く、Gtk2を採用するアプリケーションも少ないため、正直デスクトップの重さというのはそもそも感じにくい。 むしろ処理が速くなって快適になったくらいだ。

中学生のための英語 all, any, each, every の違い

感覚的にわからない?

コンピュータ系のドキュメントでは頻出し、しかも決定的キーワードとして登場するall, any, some, each, everyの5語。

実際の動作と照合すれば意味は明らかなのだけど、英文を読む機会が少ない人が多いのか、これに関して「否定ではany」とかよくわからない解説がされているものを見かけることがある。

そこで、これらの意味合いの違いと使い分けについてサクッと解説しよう

allとany

allはすべて。anyはいずれかひとつ。

通常は全く異なる意味なのだけど、否定になると意味はかなり近くなる。

否定であればallは「全て ない」であり、anyは「ひとつも ない」である。

ただ、実際のところ否定のallという言い方はちょっと曖昧。 意味としては “no all instruments”といったら楽器はひとつもないのだけど、noがallを否定していて「全てはない」と言っているかのようにも思える。

だから、「ひとつとしてない」場合はanyを使うほうが普通で、もしくはnoなんちゃらか、nothingなんちゃらになる。

あんまり見かけないけれど、someの否定だとanyと一緒なんだけれど、ちょっと弱い。 探せばあるのかもしれない。とりあえず見当たらない程度のニュアンス。

anyとsome

否定でないのであれば(肯定形という言い方は変なのであまりしたくない)anyは「いずれか」、someは「いくらか」。

anyの場合、ひとつでもあればOKで、いくつあるかは全く気にしない。 I want any girlfriend. といったら「誰でもいい」。

someの場合、少なくともひとつ、あるいはそれ以上。 I want some girlfriend. といったら最低限ひとりは欲しくて、できればハーレムにしたいということになる。

また、anyoneの場合本当に誰でもいいのだけど、someoneと言った場合該当するoneは限定されている可能性が高い。 anyoneの場合不特定多数の中の誰かであり、someoneといったら特定の集合の中の誰かと考えていいだろう。 もちろん、anyone自体に前提として条件がかけらる場合もあるのだけど。

allとeveryもしくはeach

allは全体、everyとeachは個々。

だから、allが導く文は集合名詞(冠詞なし)か複数形なのだけど、everyやeachは集合あるいは複数のeveryやeachが導く文は個々になる。

現実的には人に対してはallを使うことはあんまりない。 それは主語が大きい人になってしまう。 ただ、物に対しては言う。

All pieces are painted with black ink. みたいに。

eachやeveryだと続く文は単一なので

Each pieces has different figure. みたいな感じで三人称単数形が登場する。

eachとevery

everyのほうは全てに共通する意味合いが強く、eachはより個々。

everyのほうは個々がどうであれそうであるという感じだから、母数が変わっても事情は変わらない。 例えば「まいにちまいにちぼくらは鉄板の…」であれば、例えそれが10年20年と続いたって変わらないのだという意味が強いので、“evryday, everyday”になる。

じゃあ、「合宿中は毎日カレーだ」だとどうだろう? まぁ、実際はこれもeverydayになるんだけども、これが月曜日はポークカレー、火曜日はシーフードカレー、水曜日はキーマカレーで「毎日カレーのくせに内容変えてきやがる」みたいな話だと「それぞれの日がそれぞれにカレー」なのでeach dayという言い方でわざわざ強調もできる。

everyの場合、そうなる必然性がある。個々の意思ではなく、なんらかの共通要素によってそうであるということであり、個々がどうであるかということを考慮する必要はないのだ。 一方eachはそれぞれがどうしたか、どうであるかの話であり、その内容は個別になる。

先の例である Each pieces has different figure. だと個々違う形を持っている、つまりそれぞれに形状があるという話なのでeveryにはならない。どのピースもそれぞれが違う形状を持ったという話だからだ。 これが、同じ型を使っているとかで個々の意思とは関係なくそうなるべくして同じ形を持っているとしたら Every pieces has same figure. なる。

「静止画ダウンロード違法化、スクリーンショットも違法」の解説

かなり話題になっているのがこの法律だ。

おおよそ表題の通りだが、コンテンツは画像に限らず、文章、そして論文も対象であり、そのコピーやダウンロード、あるいはスクリーンショットによる部分的模写も禁止であり、懲役二年以下の罰則つきである。

俎上に載っているのではなく、事実上の決定事項である。

概要

名目上は「海賊版対策」だが、 実際のところそのような色合いはない。

まず全面的に禁止されているかというとそれはちょっと違って、「違法にアップロードされた」とあるので、正規のところからダウンロードするのは良いですよ、ということである。

それがあるかないかでは大違いなのだが、これはなかなか厄介な話で、例えば版権モノ同人誌なんかは「著作権を侵害した著作物」であるとみなすことができるため、そのダウンロード販売は購入も違法、ということになる。 例えばとらのあななりメロンブックスなりの通販て購入した購入者と購入アイテムのリストを警察が請求し、ここから狙い撃ちで逮捕ということもありうるわけだ。

Twitterで見かけた話では、この法律の何が問題かわからない、と自身のFacebookで発言した議員は、当該記事中で新聞記事の写真をアップロードしたという。 この投稿を保存したりすると懲役刑、というわけである。

「著作権侵害物」を一般の人が判断するのは不可能

そもそも「著作権を侵害しているか否か」をチェックするのは現在至難の業になっている。 私は基本的にソースを確認するようにしているのだが、画像や文章に関しては検索しても「誰がオリジナルで誰が著作権侵害しているのか」というのは 判断不可能 である。 Googleの場合基本的に最もアクセス数の多い、ダウンロードされているものをトップに持ってくるし、そうなるとますますそれがアクセスされ、上位に固まるようになる。画像の場合は微妙な差異が生じるためにそれをコピーして再アップロードしたものが上位にきやすい。 だが、その上位にきているものがオリジナルとは限らず、誰がオリジナルで誰が偽物という確認可能な情報が載っていることは非常に稀なので、判断できない。

これでも、私はなにかに使用する場合(例えばブログに掲載する場合もそうだし、LINEアイコンですらそうだ)はオリジナルの確認と裏取りというのはするのだけど、それには1点あたり3時間はかける。多分そんなことしている人は他にいないと思う。テレビや新聞などの大手メディアですら10分も確認すればチェックできる情報をしょっちゅう落としているのでまともにやっていないようだ。 だが、3時間かけても わからない のだ。

そして、今スマホを使っている人は、多分ほぼ常時広告が表示されていると思うのだが、その広告の画像が著作権侵害していないかどうかというのはどうやって判断するのだろうか。

つまり結局のところ、ほとんどの場面でスクリーンショットを撮れば潜在的に違法である可能性が拭えないし、画像のダウンロードは「違法かもしれず、逮捕されても文句はいえない」という状態を回避することができない。

「文章を違法にしたい」そのわけ

これは私の推測であり、もしかしたら邪推かもしれない (もちろん、ある程度の確度を持って話すのだが)。

以前より政治家の発言についてそれを取り上げることを違法であるかのように言いたがる政治家というのは結構多くて、そうは言わなくてもその流れからこれは違法にすべきである、あるいは名誉毀損であると騒ぐ者は跡を絶たなかった。

基本的にネット上での発信はその文章に著作権が生じる、というのが日本の司法の捉え方だ。 ということは、魚拓のような発言を記録するものは著作物を違法にアップロードした、とみなすことができるし、「発言が形になることを避けるため、そのようなことをすると違法であるということにした」と言えると思う。

そもそもここ数年で、「記録を残さない」「記録はすぐに捨てる」ということをやってきているし、実際にそれを期待してデータの改竄などを行っていることが明らかになってもいる。 そして、それが問題であるという認識を口にすることはなく、正当化だけを並べている。

つまるところ、「官はなにをやっても許される」状態を作り出そうとしているわけである。

これは、独裁というとわかりやすいのだが、独裁という正確な意味とは乖離している。 どちらかといえば、政治家や司法関係者を特権階級化し、法も規律も無視して好き放題できるようにしようという考え方に近い。北朝鮮とか、ルワンダとか、そんな感じ。 実際は独裁かどうかよりも特権階級による腐敗のほうが問題だから、ブラジルとか、そっちのほうに地下いかもしれないけれど。

スクリーンショットが全面違法かどうか、というのはあまり関係ない

スクリーンショットは違法じゃないんだね、じゃあ大丈夫、なんてわけのわからないことを言っている人もいるけれど、そういう問題ではない。 多分、そういうことを言っている人は自分の著作物のスクリーンショットをとるわけではないだろうし、画面中になにか著作権的問題をはらんだものが写り込んでいたらアウトという話なのだから、そんなことを言う人に「なにがセーフなのか」を判断することは不可能だろう。

常に違法状態にしたがる

この法律に限らず、近年の法律というのは、前提として全国民的に違法状態になるという法律を好んでさだめている。 そして、その問題が取り沙汰されるたびに繰り返すのが「慎重に運用するので大丈夫」「濫用しないので大丈夫」といった言葉だ。

私はこれは、「なにもしないから!大丈夫、大丈夫だから!」と繰り返しながら連れ込もうとするチャラ男に見える。

また、これは「その気になればいつでも難癖つけてしょっぴけるようにしたい」ということであり、そのようになった者は日本では発信することもできず、外との交流すらできないのが日本の司法なので、要は「気に入らない相手をいつでも社会的に消せるようにする」ということを強くのぞみ、遂行しているのだと理解できる。

これは、安全装置も外した状態で銃口をつきつけ、「悪質なことしない限り引き金ひかないから大丈夫だよ」と言うようなものである。

あなたにはこれが正しい権力のあり方に見えるだろうか。

(OSS系) フリーフォントの昨今 2019 商用フォントの話もあるよ

収録文字数のおはなし

「グリフを揃えることが大変」であり、そもそも「アウトラインフォントを使うことで使用可能な文字が減る可能性がある」という状況は当たり前だった。

ちょっと収録文字数の話をしよう。 なお、ここでのカウントはttfdumpの出力に基づいている。

まず、JIS X0208の文字数が6355+524で6879文字。 JIS X0201の可視文字は191文字であり、Shift JIS的には7070文字があれば表現できる。

MSCP932だと7864文字まで増える。 これでも、割と使える文字は限定的だったので、あまり問題になることはなかった。

ただ、Windows的なフリーフォントだと文字が出ないことは普通にあった。

ちなみに、デザイン系のフォントは商用でも今でも普通に7000字に届いておらず、人気のあるフロップデザインのフォント (私も持っている) は4112文字にすぎないため、日常的な文章でも普通に出ない。 そもそも、JIS X0208には「割と日常的に使うのにない文字」というのが存在していて、これは「よく使うのに教育漢字じゃない」「よく使うのに第一水準漢字じゃない」というのと同じような構図になっている。 MSCP932だとそのようなことはあまりないのだけど、それでも思わぬところで使えない文字があったりする。

これを踏まえてのJIS X0213に関しては11233文字に拡張されていて、フルサポートするハードルが大変上がった。

フォント 収録文字数
IPAゴシック 003.03 12,728
源ノ角ゴシック 2.000 17,933
さざなみゴシック 13,584
VLゴシック 17,317
M+ 8,892
Migu 13,866
梅ゴシック 15,563
梅明朝 15,563
さわらびゴシック 6,973
さわらび明朝 4,295
花園明朝 A 52,008
Cica 18,189
モトヤLシーダ 等幅3 7,574
DF談楷書 8,815
UDヒラギノ丸ゴ Pr6N W4 23,058
MSゴシック 5.1 16,104 (公式資料)
メイリオ 20,684 (外部資料)
游ゴシック 約23,000 (Wikipedia)
小夏 15,572
みかちゃん 15,572

ちなみに、ttfdumpを使うと、「実際にはグリフがない (空白や〓になっている) 文字もグリフが登録されている以上カウントするため、4,114文字しかないフロップデザインのフォントも15,444なんてカウントされてしまう。 ただ、これはデザイナ的な文化で、FontConfig的にはグリフが存在しない文字にグリフを登録するのは明確な悪なので、オープン系フォントでそれはないと思う。

歴史の転換点

収録文字数を必要とする場合、有力な選択肢であったのが花園フォントである。これは現在は収録文字数が5万字を越えており、「だいたいの文字は出る」レベルである。 そうでなくても、広く利用されていた東風ゴシックは13584文字を収録している。 (さざなみゴシックでカウントしたので、少し違うかもしれないが)

だが、問題はそう簡単ではなかった。 さざなみフォントはグリフが決して綺麗ではなかったし、あまり思い出したくないほど、東風フォント、和田研フォントなどは利用に際して様々な問題を抱えていた。

この問題は主にはベクターフォントは贅沢品であるという認識、 さらにフォントは印刷系との結びつきが強く、そもそも素人が手を出せるようなソフトウェアではなかったということなどがある。 そもそもフォントは写植時代のものが長く引き継がれてきたし、写植なんて一般人には縁遠かったから印刷屋と一部研究者のものだった。 スクリーン上でリッチな文字表示をすること自体が難しかったこともあるし、一般ユーザー的には「年賀状ソフトを買えばフォントは手に入る」みたいな感じだったから、フリーフォントは貧しいままの文化だった。

という説明は多分、肌感覚との乖離から文句が出ると思う。

Unix系ではもともと和田研フォントが使われていたけれども、自動生成フォントであることもあり品質的な問題もあったし、ライセンス的な曖昧さもあった。 Linux的にはビットマップの東雲フォントが標準の時代(2000年まで。和田研フォントも使われていた)から東風フォントが標準となり(2003年まで)渡邊フォントのデザイン剽窃問題によって東風代替フォントからのさざなみフォントという時代があり(2003年から2004年)、この頃M+ OUTLINE, VLゴシック, 梅フォントが登場しフリーフォントに選択肢が出てきた、というのが実際のところだろう。 実はもうちょっと選択肢は存在していた (戸越フォントとか、Kandataとか、和田研細丸ゴシックとか) のだけど、あまり広く使われることはなかった。これは、ライセンス的都合も大きかったと思う。

そんな中IPAフォントが公開された。 これに関しては実は色々あった。大きいのはライセンス的理由で、当初は「単独再配布不可、成果物同梱のみ可」なんてライセンスだった。 ライセンス問題は延々と続き、2009年に一応オープンなライセンスになったものの、SIL Open Font Licenseより余計なものがくっついているようなもので、依然として問題が残っている。

だが、少なくともこのような高品位なフォントというのは今までLinux界隈にはなかったものだったし、衝撃も大きかった。 しかしその割に肯定的に受け入れられなかったのは、そのライセンス問題に加えて、それより先にM+ OUTLINE及びVLゴシックが登場したことが大きいだろう。

「スクリーン向けの可読性の高いアウトラインフォント」というのは従来のフォントにはない新しい概念だった。これは、メイリオにまで影響を及ぼしたように思う。 対してIPAフォントは(横組を前提としてデザインされている)TB明朝/TBゴシックをベースとしており、本明朝ベース、及び本明朝ベースの明朝をベースにしているMSフォントと比べればモダンだが、それでも新時代の丸ゴシックを体験した後ではちょっと古くさく思えてしまったのだ。 だが、これは好みだったから、意見はすっかり二分されることとなった。実際、ディストリビューションの採用フォントもIPAフォント派とVLゴシック派に割れた。

ただ、大きかったのは「高品位で文字数が揃っているフォント」が登場したことである。 これによって「グリフを揃えるのが大変な漢字部分をIPAフォントで補う」という手法が生まれた。その代表格はM+ OUTLINE FONTとIPAゴシックを組み合わせたM+IPAGフォントである。 このフォントは現在はMiguと呼ばれている。

しかし、そこまで流行らなかった、とも言える。 VLゴシックは漢字部分はM+のもの、自作のもの、さざなみ由来のものを組み合わせているし、ライセンス的な不自由さもあり、そのような手法がより一般化したのは2009年以降だ。

インパクト面では源ノ角ゴシックのほうが大きかった。 こちらは2014年に登場。Adobeによる圧倒的高品位なフォントである。 さらに2017年には明朝も登場している。ライセンスはSIL OFLであり、IPAフォントより扱いやすい。

最近は「不足グリフを補う」というスタイル(Mgen+, みずき明朝, Meguriなど)よりも、そもそもIPAフォントやSource Hanフォントを改変していくスタイルのほうが流行しているようだし、 ベースがグリフ数が揃っている高品位フォントということもあって、刮目すべき素晴らしいフォントが次々に誕生している。

実際、積極的にIPAフォントを採用する話はLinux界隈以外ではあまり聞かないのだが、1 Source Hanフォントはかなり人気があって、WindowserもMaccerも積極的選択がよく見られる。

逆に嫌われているのがWindows, Macともに標準採用となった游ゴシックである。 高品位フォントの代名詞のように扱われているヒラギノフォントと同じく字游工房が作ったフォントなのだけど、モダンなヒラギノに対してどちらかといえばレトロにデザインされているせいなのか、嫌う人が大変多い。 いや、私も好きではないのだけど。

次の話の前置き

私は結構商用フォントも買う方で、

  • ダイナフォント
  • モリサワ
  • モトヤ
  • フロップデザイン
  • フォントアライアンス

を持っていたりする。

やはりフォントの品質的にはモリサワが一番いいのだけど、モリサワはデザイン性が高すぎて本文やスクリーンフォントとしてはちょっと使いにくい。 一番使いやすいのはモトヤフォントで、UDアポロが非常に使いやすいので単独フォントでUDアポロ買おうかなと思っているし、逆にモリサワパスポートの更新はあまり考えていない。

源暎フォントのすゝめ

おたもんさんが源ノ角ゴシックベースに作っているのが源暎フォントである。

このフォントは今すごく熱い。全体で見ればよりレトロな方向性に思える。

  • 源暎こぶり明朝 ―― 本文向け明朝。 小がな化、オーソドックスなグリフ化(特に欧文)、縦書きに最適化、濁点つきかな/カナの専用グリフ (NKS)
  • 源暎ちくご明朝 ―― 本文向け築五系の明朝。オールドスタイル化、角立て、濁点つきかな/カナの専用グリフ (OKL)
  • 源暎アンチック ―― アンチック体(漫画で一般的な形状)かな+ゴシック体漢字のアンチゴチフォント。 漫画でオーソドックスな形式で漫画向け。実際最近は漫画でも使われる
  • 源暎Nuゴシック / 源暎ゴシックKL ―― 漫画の強調セリフ向け特太ゴシック。 かなも大きく調整。
  • 源暎ラテゴ / 源暎ラテミン ―― アポロやフォークのような方向性のアンチック体のかなに源暎ゴシックの組み合わせ。ラテミンは機械的に漢字を横太に調整
  • 源暎ロマンのーと ―― リガチャ対応のfantasy系欧文フォント
  • 源暎ゴシック ―― テロップ向けに源ノ角ゴシックの癖のあるスペーシングを調整

縦組み長文で読みやすいモダンな「源暎こぶり明朝」、格調高い小説に使える「源暎ちくご明朝」、漫画で実用的な「源暎アンチック/源暎Nuゴシック/源暎ラテゴ」と創作物に非常に使いやすい。 実際に創作物(同人を中心に)に使われることも増えているのだけど、元が商用フォントを差し置いて使われることも増えている源ノ角ゴシックだけに、とにかく品質が高い。

源暎ラテミンはおまけ、とのことなのだけど、うちでは本文用フォントとしての人気が大変高く、さすがにUDアポロのほうが評判は良いものの、 「アンチ明朝」である元陽逆アンチックと人気を二分しており、手持ちライセンス的にはフォークも使えるにもかかわらず、私はPDF文書は主に源暎ラテミンで出している。2


  1. なんて言いながら、私が最近開発したシステムはIPAフォントを使用していたりする。理由はSource Hanフォントより無難だったし、ライセンスコストも抑えられるからだ。

  2. 全くの余談だが、評判と好みを元に考えると、「見出し: UD新ゴ, 本文: UDアポロ」が最も良いようで、私としては明朝体はリョービイマジクス(モリサワ販売)の「本明朝 新小がな」を推したい。 丸ゴシックはマルベリが一番好き。

決意表明

波乱万丈という意味なら、誰にも負けないと思う。

誰がどこまで知っているかわからないけれど、すごく色々なことがあった。 どの分野においてもだ。 ドラマチックだの嘘くさいだの言う人もいるけれど、その中で生きる側にとっては本当に苦しいものだ。

およそ過去をふりかえれば、ひとつひとつは置いておくとして、大局的にはただひとつを除けばおよそ選択にも判断にも後悔はない。 その一点を除外すれば、およそ私は正しく私を積み上げたと言っていいと思う。

もっとも、それは理論上の最善ではないのだけれども、現実的に可能な範囲という意味では。

もちろん、昔は随分と私は甘かった、という気持ちは強い。 これはいくつかの要因が重なっている。第一に自分の能力を過小評価したこと。第二に未来の進行を楽観したこと。 そして、そのために成すべきことを過小に見積もったことだ。

私は生きるためにとった選択は、随分細い糸だという認識があった。 中学校三年生、作曲コンクールの優秀賞。それだけにすがってサウンドクリエイターになりたいと門を叩いたときに、可能性は極めて少なくて、あまりに細く心もとないと思いつつも、これを逃せば生きてはいけまいと認識していた。

本当にひたすらに勉強して、練習して、仕事をしていた。まさに休みなくという感じだった。 だから、手抜かりしたという事実はないのだが、私としては当時から「逃げていた」という認識があった。

どうしても評価のほうが高くて実力が追いつかなかった。 その中で「音楽の、少なくとも作曲家としての能力を評価に追いつかせる」という努力と、「クライアントを失望させない。中学生でも、プロなんだと認めさせる」という努力は、 一方で演奏家としての評価に追いつかないことや、コンピュータの能力が置き去りにされていくこと、そして社会性を身に着けられないことから逃げるために没頭していた面もあった。

もともと天才型、つまりは感性派だった私は分析が結構苦手で、「どう努力すればいいか」ということが分からず、努力の効率が本当に悪かった。 根気がないということもあって、私自身は努力は苦手だと認識していた。 だが、直感と天性のものだけで乗り切ろうという考え方もやっぱり逃げだった。それで乗り切れるほどの才能がなかったからだ。

だが、これではダメだと認めることがなかなかできず、随分苦労した。

「だから、この頃までは間違っていた」というのは簡単なのだけど、実際はそんなことはない。 この「苦労した時期」がなく、着実に積み上げていたら、今私が立っているところより低いところで「無難な生き方」を選択できるようになってしまうので、ここまで到達できていない。

「苦労した時期」というのは、何もしていなかったわけではなく、既に私としては実証できているものに対しても含め、とにかく体当たりで「何をしたときにどうなるか」を試していた時期でもあった。 まぁ、「この仮定は正しくない」とわかっていることを正しくないことを確定することを優先して取り掛かったのはまた逃げだったりするのだけど。

転機は、まぁ何度か言っているように2008年の、皆既日食の日だけども、実際のところ今のベースになっているものは2012年と相当時間をかけて醸成されている。 この話は初出だ。

大きいのは、「努力が苦ではなく、向上に非常に強い執着がある。だから諦めないことと努力しつづけることは他者を隔てる武器になりうる」ということを発見したことだ。 「努力は苦手、根気がない」という自身に対する思い込みはなかなか解けない。多分、知らず知らず「努力が嫌いという自分のイメージと、もっと努力したいという衝動に折り合いがつけられない」という苦しみも抱えていたように思う。 「向上心」なんて言葉で自分を飾るのは好きじゃなかったし、なによりその言葉が自分の気持ちにしっくりこなかった。 だから、「これは非常に強い欲求であり、欲望なんだ」ということ、そしてそれを追い求めることは業とも言うべきものなんだと認識することは私にとって一歩踏み出すのに必要なことだった。

そして、やり続けることは私の中であまりにも当たり前過ぎてそこに特別な意味があるだなんて思っていなかった。 もちろん、非常に苦境にあって、あるいは弾圧されても信念を曲げないことは特別な意味があると思っていたけれど、その諦めないことと、普通にしていることはさすがに受け取り方に大きな差があったのだ。

でも、30を前に、「若くない」ところまで来ると続けているという事実が意味を持ち始める。 思えば、苦しいと思ったことや、嫌になったことは数え切れないほどある――なにせ才能に乏しく、伸びが悪いから敗北も、追い越されることも日常的にある――けれど、私はそれを「やめてしまうこと」につなげたことがなかった。 さすがに意味がないと思えばやめるけれど、それはあくまで意味がないからやめるのであって、「負けたから」「追い越されたから」「勝てないから」「一番じゃないから」やめるわけではない。「勝てないけど続ける」「才能はないけど続ける」「少しでも上達したいと願って行動する」ということに全く苦痛を感じない。そのことが特別だと知ったのはこのときだ。

そもそも感性派で、とにかく突っ込んでいってあったとは流れで乗りこなす、というタイプだった私は、自分が晩成型だと考えることは全くなかった。 スタート地点が高くスタートダッシュに優れるという点を考えればどう考えても早熟型だと思うし、伸びが悪いのだから、スタートダッシュで勝負にならないものは絶望的だと思っていた。 だが、現実には「他者が脱落するまで続ける」ことで成り立つ晩成型だった。才能に乏しい私のスタートダッシュなど、たかが知れていた。

論理的であることや、分析することはこれを期に大きく意味を持ち始めた。 実際のところ、私にとっては満を持してという感じだったけど、2年に満たない準備は自分を大きく変えるにはあまりに急ごしらえだったとも映るだろう。

すんなりうまくいくとは思っていなかったし、実際うまくいかなかった。 その過程で失ったもの、私の罪は肯定的に捉えようがない。条件の中で結果を出せるだけの能力と強さが私にはなかった。それだけだ。

それでも、蓄積を信じた。努力を信じた。 ありとあらゆる面で不断の努力を。たどり着けると信じて前進を続ける。 実際、何もかもがうまくいかなかったし、嫌になることも多かった。それでも正しいとわかっている努力を続けるということだけはやめなかった。


2018年11月。見積もりは56人月。 納期は、私ひとりで12ヶ月。 「実際は8ヶ月以内に片付けるつもりです」「私の心の中で言えば、2ヶ月ほどで片付けたいと思っています」

その言葉を信じられる人がどれだけいるだろう。 そもそも作ろうとしているプログラムの規模から言えば56人月で収まるという見積もりも「甘い」と嘲笑されてもおかしくない程度のものだ。 それを12ヶ月で、ひとりでやるなどと言えば妄語と断じられてもなにもおかしくはない。

私は、できると確信していた。

12月3日、大幅な仕様変更を伴い、見積もりの再作成、請求書作成。 この時点で作業量は当初の倍以上に増えていた。素直に見積もるのであれば112人月。 12月4日、着手。

12月14日、当初の目標物、完成。 12月22日、会計処理のため開発を一時凍結。 12月24日、クリスマスパーティ後の作業でパフォーマンスを約60倍まで向上することに成功。

12月30日、決算を完了し、帳簿作成を完了。 プロジェクトへ復帰。

1月7日、テストリリース。1月11日、本番リリース可能な仕様として凍結。

112人月相当を、ひとりで、実質30日で片付けた。 しかも、通常の業務(授業や、教材作成や、サポート業務)をしながら(年末なのでそれも登場よりも忙しかった)だし、さらにいえばテストリリース後はさらに難易度の高いプロジェクトに従事してもいた。 セールストークを抜いた予告どおり、私の理想値通りの結果だ。

やりきったこと、無事遂行できたことにとても安堵した。 私にとっては、ついに巡ってきた結実のときだった。


今、この区切りに、はっきりとこの意思と決意を述べたい。

私はWILLを信仰している。だから、ここに明確な意思を抱いて成し遂げよう。

今、私を遥かに凌駕する「人外」クラスのハッカーは、私より若い人も少なくない。 未だたどり着く方法も、実際にどれほどの差があるのかさえ、私には分からない。雲に隠れた霊峰の稜線だ。

だが、私は諦めない。 私を除いて人類が誰もたどり着けない境地へ、必ずたどり着く。

このWILLにかけて。

私がすべきことはいつだって変わらない。

全力を尽くす。

気になる「変換時の拗音/濁音補正」

気になる

最近、入力時にすごく気になっていることがある。

それは、「変換候補が拗音、濁音、半濁音を無視する」ということである。

依然は予測変換だけだったのだが、現在は少なくともATOK for Android, Google日本語入力(Android), MS-IMEはそのように動作する。

間違っている

だが、それは「日本語についてまじめに向き合ったことがあるか?」と思う。

まず、濁音についてだ。 言うまでもなく、フリック入力、かな入力に関しては濁音は「追加の操作をすることで濁音にする」のである。 ATOK for Androidのフラワータッチも同様である。 ローマ字入力においては濁音は全く違う入力になる。

だから、濁音を清音に修正するのは「ユーザー操作を無視している」わけで、明らかに間違っている。

拗音に関してはもう少し複雑だ。 フリック入力、フラワータッチに関しては追加の操作が必要、かな入力はShiftの併用が必要で、やはり補正するべきではない。 ところが、ローマ字入力に関してはtypoによって拗音が発生するケースがある。 例えば「siyo」は「しよ」だが、iを打ちそこねて「syo」になると「しょ」である。

だが、ローマ字入力以外ではそのような補正は抑制すべきだし、少なくとも等価に扱うべきではない。 ところが、実際には「拗音や濁音のある、打ったままの内容をずっと後に回し、清音のものを先頭に並べる」ということをしてしまう。

おかげで、最近変換がとても辛い。 ちょっと前はMS-IMEの変換効率が最も良い、なんて時期もあったのだが、現在はWidnowsでの変換は極めて苦痛だ。

なぜそんなことが起きるのか

戦犯はGoogleとMicrosoftである。

どっちが先かはわからないのだが、検索エンジンにおいて拗音や濁音を「typoの一種」とみなすようになったのだ。 以前は収集時だけだったが、現在は検索ワードでも無視して検索する。

GoogleとBingどちらが先にはじめたのかはわからないが、とにかくそれ以降は右へならえで当たり前にDWIMの一種としてdowncasingと同レベルに清音統一化をしてしまっている。

言語を大事にしない者はタンスの角に小指をぶつける呪いにかかってしまえ!